From kjell.ahlstedt@bredband.net Wed Nov 5 08:11:59 2014 Return-Path: X-Original-To: gtkmm-list@gnome.org Delivered-To: gtkmm-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 8BC8B76990 for ; Wed, 5 Nov 2014 08:11:59 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axaDLPWXCYWl for ; Wed, 5 Nov 2014 08:11:57 +0000 (UTC) Received: from smtprelay-b22.telenor.se (smtprelay-b22.telenor.se [195.54.99.213]) by restaurant.gnome.org (Postfix) with ESMTP id 207937684D for ; Wed, 5 Nov 2014 08:11:46 +0000 (UTC) Received: from ipb4.telenor.se (ipb4.telenor.se [195.54.127.167]) by smtprelay-b22.telenor.se (Postfix) with ESMTP id 6D3AF15E2C for ; Wed, 5 Nov 2014 09:11:24 +0100 (CET) X-SMTPAUTH-B2: [kjell.ahlstedt@bredband.net] X-SENDER-IP: [85.229.156.35] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsBACXbWVRV5ZwjPGdsb2JhbAANToNizy0PiHkBAQEBAQEFAQEBATiENIEIHwEdFhgDAgECATEnCAEBiEIIsUeWGgwcBJEthDUFky6DRKFnawGCSgEBAQ X-IPAS-Result: ArsBACXbWVRV5ZwjPGdsb2JhbAANToNizy0PiHkBAQEBAQEFAQEBATiENIEIHwEdFhgDAgECATEnCAEBiEIIsUeWGgwcBJEthDUFky6DRKFnawGCSgEBAQ X-IronPort-AV: E=Sophos;i="5.07,318,1413237600"; d="scan'208,217";a="677198550" Received: from c-239ce555.06-203-73746f44.cust.bredbandsbolaget.se (HELO [192.168.1.64]) ([85.229.156.35]) by ipb4.telenor.se with ESMTP; 05 Nov 2014 09:11:24 +0100 Message-ID: <5459DBAB.6060208@bredband.net> Date: Wed, 05 Nov 2014 09:11:23 +0100 From: Kjell Ahlstedt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: gtkmm-list@gnome.org Subject: Request for comments on new glibmm classes Content-Type: multipart/alternative; boundary="------------000400040205070905050806" X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 08:11:59 -0000 This is a multi-part message in MIME format. --------------000400040205070905050806 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Two glibmm bugs contain suggestions for new classes in glibmm. I would appreciate comments on the attached patches before they are pushed to the git repository. https://bugzilla.gnome.org/show_bug.cgi?id=738663 contains class Glib::Binding, wrapping glib class GBinding. https://bugzilla.gnome.org/show_bug.cgi?id=739206 contains class Gio::Resource, wrapping glib class GResource. --------------000400040205070905050806 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Two glibmm bugs contain suggestions for new classes in glibmm. I would appreciate comments on the attached patches before they are pushed to the git repository.

https://bugzilla.gnome.org/show_bug.cgi?id=738663 contains class Glib::Binding, wrapping glib class GBinding.
https://bugzilla.gnome.org/show_bug.cgi?id=739206 contains class Gio::Resource, wrapping glib class GResource.

--------------000400040205070905050806-- From jonatan.palsson@pelagicore.com Thu Nov 6 08:36:13 2014 Return-Path: X-Original-To: gtkmm-list@gnome.org Delivered-To: gtkmm-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 6974076A61 for ; Thu, 6 Nov 2014 08:36:13 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKwYB67k8eGb for ; Thu, 6 Nov 2014 08:36:11 +0000 (UTC) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by restaurant.gnome.org (Postfix) with ESMTP id 7CE90769CB for ; Thu, 6 Nov 2014 08:36:00 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id y10so600260wgg.2 for ; Thu, 06 Nov 2014 00:35:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=vUpumzk3vxKDCSkURqSu+pHPVOnTTYrCNYUJtWWCiJs=; b=VxMD8sYCYfvLeE1TUOKvoeJr95CG/TXbW+Q+hEnmu9MX6NhN6aIzpzAlR8ssIiD2rJ bF83KdZsdYHcsApipuimNEqeDXRpbSiXNtfCds+L6TRyvntmnQHMk1MipVbm3YgToq3T D6gzWBrrVPCPLbMa/BuO1LMlthZK2r8mfUaiAqZ+oR/wEh0/Rs6gMET2meEYAhEGPLlq 4zAidB1sYqnTeKe/XxaLplF1qXZ0E5b0QD/tS5qZ3ocDBbX/UarlQik6Pe0mgbjg6Uc/ zuN/lcDjIDuH0orbnPk1w7m56BAFKRUUhEBMIF4lVCw5+ZBahJ1O/MVkluMTvcZVXRBp xnpA== X-Gm-Message-State: ALoCoQlQQb0ZKxDu3ifekFqAKi1Y4O3Qups5qIYzfKiTjjvcG+l28QMoPVSl9dsbUN7w3OYzgOUP MIME-Version: 1.0 X-Received: by 10.194.186.207 with SMTP id fm15mr3413821wjc.1.1415262958700; Thu, 06 Nov 2014 00:35:58 -0800 (PST) Received: by 10.180.221.234 with HTTP; Thu, 6 Nov 2014 00:35:58 -0800 (PST) Date: Thu, 6 Nov 2014 09:35:58 +0100 Message-ID: Subject: gdbus-codegen --generate-c-code equivalent for glibmm? From: =?UTF-8?Q?Jonatan_P=C3=A5lsson?= To: gtkmm-list@gnome.org Content-Type: multipart/alternative; boundary=047d7beb9102ebb78b05072c9507 X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 08:36:13 -0000 --047d7beb9102ebb78b05072c9507 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi list, I'd like to generate D-Bus proxies and stubs for use with glibmm. gdbus-codegen seems to do most of what I want, but it generates C code, and not C++. Is there any similar way to generate glibmm D-bus proxies and stubs? If not, what is the general workflow when creating new D-Bus services based on glibmm, and what is the workflow for interfacing with D-Bus services? Thanks, --=20 Jonatan P=C3=A5lsson --047d7beb9102ebb78b05072c9507 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi list,

I'd like to generate D-Bus= proxies and stubs for use with glibmm. gdbus-codegen seems to do most of w= hat I want, but it generates C code, and not C++. Is there any similar way = to generate glibmm D-bus proxies and stubs?

If not= , what is the general workflow when creating new D-Bus services based on gl= ibmm, and what is the workflow for interfacing with D-Bus services?

Thanks,

Jonatan P=C3=A5lsson

--047d7beb9102ebb78b05072c9507-- From fr33domlover@riseup.net Tue Nov 11 17:40:11 2014 Return-Path: X-Original-To: gtkmm-list@gnome.org Delivered-To: gtkmm-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 75C20769CD for ; Tue, 11 Nov 2014 17:40:11 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, MISSING_MID=0.497, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smEO2fNKwOO8 for ; Tue, 11 Nov 2014 17:40:10 +0000 (UTC) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) by restaurant.gnome.org (Postfix) with ESMTP id A19B2769CB for ; Tue, 11 Nov 2014 17:40:00 +0000 (UTC) Received: from plantcutter.riseup.net (plantcutter-pn.riseup.net [10.0.1.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id C094B40B83 for ; Tue, 11 Nov 2014 17:39:58 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: fr33domlover) with ESMTPSA id 2DF22227DF Date: Tue, 11 Nov 2014 19:39:49 +0200 From: fr33domlover To: gtkmm-list@gnome.org Subject: make distcheck Organization: Earth MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/ek_1+mRtgK/Dqy5_i2j_gQr"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.4 at mx1 X-Virus-Status: Clean Message-Id: <20141111174011.75C20769CD@restaurant.gnome.org> X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 17:40:11 -0000 --Sig_/ek_1+mRtgK/Dqy5_i2j_gQr Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello, I've been working on a C++ project and recently I started adding doxygen support based on mm-common. It's a bit different so I didn't just paste the code as-is: - It uses only POSIX features (e.g. no GNU make functions like patsubst and= no wildcards) so it doesn't need the -Wno-portability flag (I use the 'find' instead, some Automake features and a bit of trivial targets copied from generated Makefile)=20 - It builds 2 separate sets of docs (1 for API, 1 is full code reference for hackers) - Installation uses regular rules and not a Perl script - although I haven't yet implemented using tag files so maybe those will require Perl (I don't know yet why Perl is needed there, haven't checked) Today I finished writing the first version of this setup and it failed at `= make distcheck` because the HTML files are in MAINTAINERCLEANFILES and not DISTCLEANFILES. That makes sense - delete the docs only on `make maintainer-clean`. But how to make `make distcheck` not complain due = to these files not deleted on `make distclean`? I read about how to do it, but I didn't see that mm-common does anything li= ke that. So I had an idea - maybe glibmm, gtkmm, etc. simply don't pass `make distcheck`. I decided to check. I failed to build them, and I couldn't find info about it, so I decided to = ask here - how do these modules pass `make distcheck`? It expects disted files = to be distributed at distclean time, but it doesn't happen. What I did was to install mm-common from git, and then try building glibmm = and gtkmm. They gave errors about ENABLE_DOCUMENTATION not defined with a AM_CONDITIONAL. Was there another step, e.g. manually copying mm-common fil= es into glibmm tree, which I missed? Thanks in advance! fr33domlover PGP key ID: 63E5E57D --Sig_/ek_1+mRtgK/Dqy5_i2j_gQr Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJUYknlAAoJEFJSxchj5eV9O/oP/36Zc9kYrgsEdL5w/aIrzPQH erhFsdlvs61ZCIggjVHJ4rHnIC5IHb5qSDxVkBRn7NmJI0zyLemSiok5Rcxg+ll3 Z+cbgl4+bChiteQhWLk4LZEHYYqPUqSnxiN4Gb742BugpNRPPbJnktBV62xUOAyN qcOzD2vePgwB0T4gWQKolJYIMuDzHGsjHQDN2XhSmwiHuOA87gGEp2E17hOS7/kF pgQCagWFJYOSPwe80L8+vgNEYqbw4pVlI3/0fCnwRk7gxOWfONcqyvVOVFlBiM4a dGUmDQjJYLQE2c8+9rn248qU725D2jZlh0rerxWIXdeMHsU2NVnhHadxkckzI87+ 4wDJi7O1J7aph4Yc6NtsfZiT4P2xRH5aGCuQVSfyD6wRYMkEBp1M7rx7lPWGsUtm MXLA/ndgTtBnEaq3MKh10yK2/Qniv0004FPOxrxRtTsTxW2PGnmLFXENlz7AHMFr maJNLEbj2nlcZNHRr2XBzl4/OHTAgvosWvknGxjf9CGmNoEEI/BRGeigKEPD4D00 8F3wKpqKKGG6LKXEmQK5azYDBKxIEt4jGyhg7/Zba/k5KmaKXcjOwqcAhhExI7nc xEmZFTLwUj6YOW2bUQFX3KhWWstWDHwNp57LD7oqCVbYI3+9ewc693z/6bDp8Ji2 GPxVAEf0pnms0j5rZE+o =vahW -----END PGP SIGNATURE----- --Sig_/ek_1+mRtgK/Dqy5_i2j_gQr-- From kjell.ahlstedt@bredband.net Wed Nov 12 15:31:07 2014 Return-Path: X-Original-To: gtkmm-list@gnome.org Delivered-To: gtkmm-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 7501676984 for ; Wed, 12 Nov 2014 15:31:07 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UC_GIBBERISH_OBFU=1] autolearn=no Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhR3-3suvaT5 for ; Wed, 12 Nov 2014 15:31:05 +0000 (UTC) Received: from smtprelay-h21.telenor.se (smtprelay-h21.telenor.se [195.54.99.196]) by restaurant.gnome.org (Postfix) with ESMTP id E23FE76936 for ; Wed, 12 Nov 2014 15:30:54 +0000 (UTC) Received: from ipb3.telenor.se (ipb3.telenor.se [195.54.127.166]) by smtprelay-h21.telenor.se (Postfix) with ESMTP id A3203C50E for ; Wed, 12 Nov 2014 16:30:52 +0100 (CET) X-SMTPAUTH-B2: [kjell.ahlstedt@bredband.net] X-SENDER-IP: [85.229.156.35] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQDAFJ8Y1RV5ZwjPGdsb2JhbAANT4NiWYhhwQ2CSIdNAoEvAQEBAQEBBQEBAQE4hD4BAQR4ARALBB0WDwkDAgECATEUBg0BBwEBiEIIt0yXSwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEkRQHhEsFk0iDRYhYhwSSLGwBgkoBAQE X-IPAS-Result: ApQDAFJ8Y1RV5ZwjPGdsb2JhbAANT4NiWYhhwQ2CSIdNAoEvAQEBAQEBBQEBAQE4hD4BAQR4ARALBB0WDwkDAgECATEUBg0BBwEBiEIIt0yXSwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEkRQHhEsFk0iDRYhYhwSSLGwBgkoBAQE X-IronPort-AV: E=Sophos;i="5.07,369,1413237600"; d="scan'208,217";a="761940764" Received: from c-239ce555.06-203-73746f44.cust.bredbandsbolaget.se (HELO [192.168.1.64]) ([85.229.156.35]) by ipb3.telenor.se with ESMTP; 12 Nov 2014 16:30:52 +0100 Message-ID: <54637D2A.5000802@bredband.net> Date: Wed, 12 Nov 2014 16:30:50 +0100 From: Kjell Ahlstedt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: fr33domlover Subject: Re: make distcheck References: <20141111174011.75C20769CD@restaurant.gnome.org> In-Reply-To: <20141111174011.75C20769CD@restaurant.gnome.org> Content-Type: multipart/alternative; boundary="------------000300030607080905020304" Cc: gtkmm-list@gnome.org X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 15:31:07 -0000 This is a multi-part message in MIME format. --------------000300030607080905020304 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Glibmm and gtkmm do pass 'make distcheck'. If you want to build them from source code in git, use jhbuild. https://wiki.gnome.org/Projects/Jhbuild https://developer.gnome.org/gtkmm-tutorial/stable/chapter-working-with-source.html.en It can take a while to set everything up and build it the first time. Kjell Den 2014-11-11 18:39, fr33domlover skrev: > Hello, > > > I've been working on a C++ project and recently I started adding doxygen > support based on mm-common. It's a bit different so I didn't just paste the > code as-is: > > - It uses only POSIX features (e.g. no GNU make functions like patsubst and no > wildcards) so it doesn't need the -Wno-portability flag (I use the 'find' > instead, some Automake features and a bit of trivial targets copied > from generated Makefile) > - It builds 2 separate sets of docs (1 for API, 1 is full code reference for > hackers) > - Installation uses regular rules and not a Perl script - although I haven't > yet implemented using tag files so maybe those will require Perl (I don't > know yet why Perl is needed there, haven't checked) > > Today I finished writing the first version of this setup and it failed at `make > distcheck` because the HTML files are in MAINTAINERCLEANFILES and not > DISTCLEANFILES. That makes sense - delete the docs only on > `make maintainer-clean`. But how to make `make distcheck` not complain due to > these files not deleted on `make distclean`? > > I read about how to do it, but I didn't see that mm-common does anything like > that. So I had an idea - maybe glibmm, gtkmm, etc. simply don't pass `make > distcheck`. I decided to check. > > I failed to build them, and I couldn't find info about it, so I decided to ask > here - how do these modules pass `make distcheck`? It expects disted files to > be distributed at distclean time, but it doesn't happen. > > What I did was to install mm-common from git, and then try building glibmm and > gtkmm. They gave errors about ENABLE_DOCUMENTATION not defined with a > AM_CONDITIONAL. Was there another step, e.g. manually copying mm-common files > into glibmm tree, which I missed? > > > > Thanks in advance! > > fr33domlover > PGP key ID: 63E5E57D > --------------000300030607080905020304 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Glibmm and gtkmm do pass 'make distcheck'.

If you want to build them from source code in git, use jhbuild.
https://wiki.gnome.org/Projects/Jhbuild
https://developer.gnome.org/gtkmm-tutorial/stable/chapter-working-with-source.html.en
It can take a while to set everything up and build it the first time.

Kjell

Den 2014-11-11 18:39, fr33domlover skrev:

Hello,


I've been working on a C++ project and recently I started adding doxygen
support based on mm-common. It's a bit different so I didn't just paste the
code as-is:

- It uses only POSIX features (e.g. no GNU make functions like patsubst and no
  wildcards) so it doesn't need the -Wno-portability flag (I use the 'find'
  instead, some Automake features and a bit of trivial targets copied
  from generated Makefile) 
- It builds 2 separate sets of docs (1 for API, 1 is full code reference for
  hackers)
- Installation uses regular rules and not a Perl script - although I haven't
  yet implemented using tag files so maybe those will require Perl (I don't
  know yet why Perl is needed there, haven't checked)

Today I finished writing the first version of this setup and it failed at `make
distcheck` because the HTML files are in MAINTAINERCLEANFILES and not
DISTCLEANFILES. That makes sense - delete the docs only on
`make maintainer-clean`. But how to make `make distcheck` not complain due to
these files not deleted on `make distclean`?

I read about how to do it, but I didn't see that mm-common does anything like
that. So I had an idea - maybe glibmm, gtkmm, etc. simply don't pass `make
distcheck`. I decided to check.

I failed to build them, and I couldn't find info about it, so I decided to ask
here - how do these modules pass `make distcheck`? It expects disted files to
be distributed at distclean time, but it doesn't happen.

What I did was to install mm-common from git, and then try building glibmm and
gtkmm. They gave errors about ENABLE_DOCUMENTATION not defined with a
AM_CONDITIONAL. Was there another step, e.g. manually copying mm-common files
into glibmm tree, which I missed?



Thanks in advance!

fr33domlover
PGP key ID: 63E5E57D

--------------000300030607080905020304-- From fr33domlover@riseup.net Wed Nov 12 19:51:10 2014 Return-Path: X-Original-To: gtkmm-list@gnome.org Delivered-To: gtkmm-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 6DFD376984 for ; Wed, 12 Nov 2014 19:51:10 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, MISSING_MID=0.497, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.555, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QhfJ6s1bA47 for ; Wed, 12 Nov 2014 19:51:09 +0000 (UTC) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) by restaurant.gnome.org (Postfix) with ESMTP id 29C157684A for ; Wed, 12 Nov 2014 19:50:58 +0000 (UTC) Received: from berryeater.riseup.net (berryeater-pn.riseup.net [10.0.1.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 131B541D24; Wed, 12 Nov 2014 19:50:57 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: fr33domlover) with ESMTPSA id D5594428D2 Date: Wed, 12 Nov 2014 21:50:44 +0200 From: fr33domlover To: Kjell Ahlstedt Subject: Re: make distcheck In-Reply-To: <54637D2A.5000802@bredband.net> References: <20141111174011.75C20769CD@restaurant.gnome.org> <54637D2A.5000802@bredband.net> Organization: Earth MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/s18PrkkAlepEytE.r5ESkSH"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.4 at mx1 X-Virus-Status: Clean Message-Id: <20141112195110.6DFD376984@restaurant.gnome.org> Cc: gtkmm-list@gnome.org X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 19:51:10 -0000 --Sig_/s18PrkkAlepEytE.r5ESkSH Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On 2014-11-12 Kjell Ahlstedt wrote: > Glibmm and gtkmm do pass 'make distcheck'. >=20 > If you want to build them from source code in git, use jhbuild. > https://wiki.gnome.org/Projects/Jhbuild > https://developer.gnome.org/gtkmm-tutorial/stable/chapter-working-with-so= urce.html.en > It can take a while to set everything up and build it the first time. >=20 > Kjell Thanks. Maybe the issue was simply version numbers, which jhbuild solves. I would still like to know - how do they solve the issue of HTML files, whi= ch are distributed, specified in MAINTAINERCLEANFILES and not in DISTCLEANFILE= S? Normally this causes `make distcheck` to fail, because `distclean` doesn't clean the HTML files. I'd like to do the same for my code. --Sig_/s18PrkkAlepEytE.r5ESkSH Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJUY7oUAAoJEFJSxchj5eV9fgMP/2hFnz1XM7m/PONj5z6xq6Ir Lr7+ZA3aPie9+9HUMUR4q5PdsDdF0uzAQ/KtwrAbD7epgwpCkQuLDXbV2egrCH1Y Wieag14yChjJzO1wjN91LeW03E7/KD7lZ6yLZ3h5VpyQL4/4GoRKH3kw+WX2tM1g ETVEHul1V7nMuENLMZR/aSnjjXc/M60yuO+8rRcLERFIx6EIA/HBYy7HyozsqC4i XufxdCjTvEAmDKRcK4j9gajjLt3+rNsn8IpS8/tsk6aeWotR5t4oAGr4lnKblVC9 8HlNnHBR2WcPz+Qcpv2PrAYFoypchc10bVJFJ5r6mPrp1MndGYLCRJtyXCBvEaQF PCpiawjDAOC73hbkTNhEpq9cMd3wXYbYRYX9Laevt9lgC9BeANJ7BlUtz0B8Lmg6 HPjokK3T6y4/YwxZWhGTLPuPKYv0d2SWrbyMS7Kt76tuiHbsJbC+i2fGHFC/PAU4 FHquT5kax+Q1KW4vQCjLlZOpwO9tMfYZnhs1vfyOLpxUnfS1PSTvBU7wetn9OFmZ mHOqyQzVEbxezduIlKJ+Tw5h+XKxWrD91EOTIjSnpI7xKXdp1I5obxmwdl0fBgzg bKp1+jdoUErXPRe2hJvFfnNyBmccw9XPD3ykr9vV4Hpu2hM1/LqO+9FYcQYFRgoC xRRVgDFkS9KGicRc1mxF =JIKx -----END PGP SIGNATURE----- --Sig_/s18PrkkAlepEytE.r5ESkSH-- From fr33domlover@riseup.net Wed Nov 12 22:50:30 2014 Return-Path: X-Original-To: gtkmm-list@gnome.org Delivered-To: gtkmm-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 9AD4F76A24 for ; Wed, 12 Nov 2014 22:50:30 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, MISSING_MID=0.497, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.555, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZ-O73EiWAu1 for ; Wed, 12 Nov 2014 22:50:29 +0000 (UTC) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) by restaurant.gnome.org (Postfix) with ESMTP id DC89676234 for ; Wed, 12 Nov 2014 22:50:19 +0000 (UTC) Received: from plantcutter.riseup.net (plantcutter-pn.riseup.net [10.0.1.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 8FF4841EE4 for ; Wed, 12 Nov 2014 22:50:17 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: fr33domlover) with ESMTPSA id 8F88923081 Date: Thu, 13 Nov 2014 00:50:02 +0200 From: fr33domlover To: gtkmm-list@gnome.org Subject: Re: make distcheck In-Reply-To: <20141112195110.6DFD376984@restaurant.gnome.org> References: <20141111174011.75C20769CD@restaurant.gnome.org> <54637D2A.5000802@bredband.net> <20141112195110.6DFD376984@restaurant.gnome.org> Organization: Earth MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/RzDEjnN0hSZ1qrG=pZaE1rH"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.4 at mx1 X-Virus-Status: Clean Message-Id: <20141112225030.9AD4F76A24@restaurant.gnome.org> X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 22:50:30 -0000 --Sig_/RzDEjnN0hSZ1qrG=pZaE1rH Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On 2014-11-12 fr33domlover wrote: > Thanks. Maybe the issue was simply version numbers, which jhbuild solves. >=20 > I would still like to know - how do they solve the issue of HTML files, w= hich > are distributed, specified in MAINTAINERCLEANFILES and not in DISTCLEANFI= LES? > Normally this causes `make distcheck` to fail, because `distclean` doesn't > clean the HTML files. >=20 > I'd like to do the same for my code. I think I found the answer: make distcheck simply doesn't build the docs at all, so no errors related to them are generated... --Sig_/RzDEjnN0hSZ1qrG=pZaE1rH Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJUY+QaAAoJEFJSxchj5eV91s8QAKt3Gg7jMJv7AEFxbJcu8Fg4 v/d+jN3U8htdbXTkjW+H+Szv7dmcYW8GduWPm2kimB4U1n9jZLg9WjyXVefQMzZc ZcmVGtXp6+M6Bq0QeCmmnjF13wfMIYgWqEwCKEgjwqeHaTNhi1xyi332flT8MMJx iC+pjHfuYKj3cipY0IosqytZbgde0z8WE+/mWtHurOyOdhThKR/SJNpYKk2D/PrV Vw35PvCcfsR4msToz+5PdgOA6WEPIcY4v5YXlxhAMl9FyrRlOg6V4bTYkpc1+6ss YtvMOUUXKSIQq7Seeyza7DkPtirtVvfx8NkiwAtheMDmcnefbPEBjFGY+ec9BxPo q3vZaKLIp26yWtsV7ovqx+kBBGnQTP5NmqhrEgcZ/wXguDLKyDQWRbbotKeHPoHt h4xQSgwBPAxDlAaU7QSUJpEUnNrMwyNk+wB2ki0p63C/xLYRYL/QLp5ZHvkfCp8w wJoYbCH924kLKnCXJ36J804yH3d09bAVuzEa6OCp+gqdSPxw0PFwVbvghUrkZsZY 5IwgQfU/ig9vC5Gfz/DCYqq39gE6BnLTvRcnPRqOVG36/ubmUKf6YkAqRYKovWQb mArTlsnyqx3EFBCPnwPMiYkHlVxo94hXWUXb4ldxujYKIyWDoteJDbzx/PwXMuDE c1c7m0lfI5S4I7NY+9JP =kWV+ -----END PGP SIGNATURE----- --Sig_/RzDEjnN0hSZ1qrG=pZaE1rH-- From jkleber2701@t-online.de Thu Nov 13 17:48:46 2014 Return-Path: X-Original-To: gtkmm-list@gnome.org Delivered-To: gtkmm-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 2BB65769AD for ; Thu, 13 Nov 2014 17:48:46 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1hw-KrkDbLt for ; Thu, 13 Nov 2014 17:48:43 +0000 (UTC) Received: from mailout09.t-online.de (mailout09.t-online.de [194.25.134.84]) by restaurant.gnome.org (Postfix) with ESMTP id 1983E769C9 for ; Thu, 13 Nov 2014 17:48:31 +0000 (UTC) Received: from fwd32.aul.t-online.de (fwd32.aul.t-online.de [172.20.26.144]) by mailout09.t-online.de (Postfix) with SMTP id A8A4E405DDE for ; Thu, 13 Nov 2014 18:48:29 +0100 (CET) Received: from [192.168.0.6] (VmAS7ZZGghq9nmmWk9QDvwxoQf0W6mEEsyqHvqzzetR6nraJzcCJXmmZ3El+h7XZw0@[79.250.191.176]) by fwd32.t-online.de with (TLSv1.2:DHE-RSA-AES256-SHA256 encrypted) esmtp id 1XoyVP-4SGNOK0; Thu, 13 Nov 2014 18:48:27 +0100 Message-ID: <1415900906.10101.2.camel@localhost.localdomain> Subject: Upgrade menu-example-main to Gtk::Application/Gtk::ApplicationWindow? From: =?ISO-8859-1?Q?J=FCrgen?= Kleber To: gtkmm-list@gnome.org Date: Thu, 13 Nov 2014 18:48:26 +0100 Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-H5Hws0/C2FZZw+IyHQ6A" X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) Mime-Version: 1.0 X-ID: VmAS7ZZGghq9nmmWk9QDvwxoQf0W6mEEsyqHvqzzetR6nraJzcCJXmmZ3El+h7XZw0 X-TOI-MSGID: 25312fd0-635f-4fd6-b5b0-aac1346a926e X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 17:48:46 -0000 --=-H5Hws0/C2FZZw+IyHQ6A Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, quite a lot of Gnome applications have an application menu allowing for menu items covering the application as a whole to place into the top bar of Gnome-shell. I should appreciate this feature being reflected in the menu-example of the gtkmm-tutorial. This could easily be done by deriving ExampleWindow from Gtk::ApplicationWindow instead from Gtk::Window and adding a new class ExampleApplication derived from Gtk::Application using this example https://git.gnome.org/browse/gtkmm-documentation/tree/examples/book/applica= tion/app_and_win_menus as a guideline. Best regards, J=C3=BCrgen --=-H5Hws0/C2FZZw+IyHQ6A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABAgAGBQJUZO7qAAoJEAgufJFiXY/ErAYP/jnSW0ss7V/E65dcvyiil4wM Ycgj47DLUqGsvMMpRFhGnSjfIXw7VYnuGmerqWrVrl9vAUDYMVeohp1osfXNSKd7 FxSHLZI3lnakpEx3ezl+YMCoHlc4o8Qxq1OClQ2tqOreUiON/iViZh8n7mjlERLf 0gHtHqBtVPBzZd5gLNGIWHyqiOoPz45vT0gyoNq0M7FXgjpAFvC7CEMcmOPGSQv7 wSL0idHFW5R9oqEo4z/FZNv6BluXVWaWqw+5kGdlyN9qSAxcRwpq8nrPzwfEKBTC qBW4fXAwb7geTUYaKyF0GYlSfP/FSO+l93hYbCeDMWxZnhAltSwWXdPvTZUYtzq0 Rn6DiCBOlfOOHQfD207lAXpGtuCQ5cAjFlRFI7Zte9IQAdueBsi2h7hNgTGVbC0N ihEQmExZ19+izsMeoCLHfoigzfMTR/1z9qUyCjYnUx80UVhCC3KDrhTE+i4ZpGzd L2uOBMhxruN4OhzjegigXWF/ZVpuQfe33BoGPABZmi9b4l/WDID2p85UjA85eGV9 /be2b2KOhqcVyGS9XeojQI24JsiCKEdw1CWPMF/bXEpAnTNdoecRo6drOuIDItwJ +4iIIWBZUxH0hRzgq0yOnJf0tGmwQGVmTsUGh1vOIfop0z2fKW3S0K9T1WoOCAPY 8Dh+HDWD0OypHh7YKCTE =pG7S -----END PGP SIGNATURE----- --=-H5Hws0/C2FZZw+IyHQ6A-- From ziegler@atlatec.de Fri Nov 14 14:14:51 2014 Return-Path: X-Original-To: gtkmm-list@gnome.org Delivered-To: gtkmm-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 1B1987695E for ; Fri, 14 Nov 2014 14:14:51 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tj6mLjTEmYti for ; Fri, 14 Nov 2014 14:14:49 +0000 (UTC) X-Greylist: delayed 368 seconds by postgrey-1.34 at restaurant.gnome.org; Fri, 14 Nov 2014 14:14:49 UTC Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.216]) by restaurant.gnome.org (Postfix) with ESMTP id 6421776952 for ; Fri, 14 Nov 2014 14:14:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1415974476; l=1257; s=domk; d=atlatec.de; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From: Date; bh=B1+i9SHcKEKH94MjQ8ruKx5EQK8=; b=vFcYdfQ2FjEDJknsKAibbQ27vuzhzZRLUCVzKwbSX9bifBM3c5kCE4w+QewWY0YwnjE nSf3heHMlC5bPSSQO8hQR/mnu93jh3lkMHt1Wr0s4P6o+A/p0bOATcN84Anl6n8DdmAJx dYvIknwJZcPvT4aSF+x32ahFzt92y9CU7Wc= X-RZG-AUTH: :NmUBckytad9iXVW5x0MugHWJK+/jfIT46pHiAiH0R3rWXvba3dBOUxUbqQNuMEJX X-RZG-CLASS-ID: mo00 Received: from [192.168.178.20] (p57B676E3.dip0.t-ipconnect.de [87.182.118.227]) by smtp.strato.de (RZmta 35.11 DYNA|AUTH) with ESMTPSA id K03397qAEE8S1gA (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) for ; Fri, 14 Nov 2014 15:08:28 +0100 (CET) Message-ID: <54660C77.8030104@atlatec.de> Date: Fri, 14 Nov 2014 15:06:47 +0100 From: Julius Ziegler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: gtkmm-list@gnome.org Subject: Pre-set selected elements of Gtk::ListViewText Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 14:14:51 -0000 Dear list, I have created a dialog where I prompt the user with a ListViewText, from which he can choose multiple strings. This works fine. I would now like to remember his selection in a configuration file, and use this to pre-select these elements on a later run of the program. Lets assume that I already now the row index of the elements that I want to set selected. Unfortunately, I could not find out how to set a specific row of the ListViewText as selected. The interface of ListViewText is quite clear, and I think what I am looking for is not in there. I am quite sure that I have to use the interface of Gtk::TreeSelection for this. The select(...) functions in there look promising: select(const TreeModel::Path& path) select(const TreeModel::iterator& iter) select(const TreeModel::Row& row) Unfortunately, the documentation of the Path, iterator and Row classes did not really help me. Path is practically undocumented. I can create it from an integer of from a string, but what is the semantics of this? Row and iterator both turn out to be TreeIter's, but how do I use them to iterate my TreeSelection (I do not see a "begin()" function there). Is there a "right" way of achieving this? Thanks! Julius From john@creativepost.co.uk Mon Nov 17 11:46:26 2014 Return-Path: X-Original-To: gtkmm-list@gnome.org Delivered-To: gtkmm-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id E067F15C028 for ; Mon, 17 Nov 2014 11:46:26 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, FROM_12LTRDOM=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qX3x5PBoO4ig for ; Mon, 17 Nov 2014 11:46:26 +0000 (UTC) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) by restaurant.gnome.org (Postfix) with ESMTP id 7EA9B15C01C for ; Mon, 17 Nov 2014 11:46:14 +0000 (UTC) Received: from [192.168.1.2] (88-104-15-37.dynamic.dsl.as9105.com [88.104.15.37]) by mrelayeu.kundenserver.de (node=mreue003) with ESMTP (Nemesis) id 0M1kWE-1Y65Wa0rOc-00tkmU; Mon, 17 Nov 2014 12:46:10 +0100 Message-ID: <5469E001.1060907@creativepost.co.uk> Date: Mon, 17 Nov 2014 11:46:09 +0000 From: John Emmas User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: gtkmm Subject: TreeViewColumn::get_first_cell_renderer() Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:E40iCeXt0H5Ra+vEBF2jLuIARfaTbq3brtW1JwRQL6G NXGR/qVOoqzat7uBvJN1FwTNA5Oeazqr/Mmxx6n7lCWmA+IM7C p6Kz6nUJI4Gmq9H9MBe+Hr45bC06hemhmrQeRqPCoyucqwZVDc zWmMssy24po/qFbYwT8skXeHcfEZsYiI1jQ3FuO+nVVXQ6AX2X IeIWRH7mKtcdP6eQXjx83OqwizuH3VSpkzGdtbXnWIrrAMNYiS RRB+1PQ4g7BIBNe1dXz0dLJXqJ192FOOLzt0wzZUO0ri8EQHil kv4CNx4mMxrToy+bkWOqqu6QBk9mybJU4WgtWpLFml1xd6XaPk 7o9wT9M7vt6EKumjRC9oBLvmVE5Hm586/roSIsRqQ X-UI-Out-Filterresults: notjunk:1; X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 11:46:27 -0000 I'm not sure if this is something new or if I just never noticed it before but round about line 119 of 'gtkmm/treeviewcolumn.cc' I seem to have these functions:- CellRenderer* TreeViewColumn::get_first_cell_renderer() { return get_first_cell(); } const CellRenderer* TreeViewColumn::get_first_cell_renderer() const { return get_first_cell_renderer(); } I assume the intention was that the 2nd function would call the 1st one but MSVC warns me that the 2nd function will just call itself recursively until the stack overflows. Any thoughts anyone? John From john@creativepost.co.uk Mon Nov 17 14:21:40 2014 Return-Path: X-Original-To: gtkmm-list@gnome.org Delivered-To: gtkmm-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 2A9BB762D0 for ; Mon, 17 Nov 2014 14:21:40 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gf3NJ0yavubQ for ; Mon, 17 Nov 2014 14:21:39 +0000 (UTC) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) by restaurant.gnome.org (Postfix) with ESMTP id EC60E762AA for ; Mon, 17 Nov 2014 14:21:28 +0000 (UTC) Received: from [192.168.1.2] (88-104-4-198.dynamic.dsl.as9105.com [88.104.4.198]) by mrelayeu.kundenserver.de (node=mreue104) with ESMTP (Nemesis) id 0MdLIx-1XYZRl0Gvr-00IUUX; Mon, 17 Nov 2014 15:21:26 +0100 Message-ID: <546A0464.3060208@creativepost.co.uk> Date: Mon, 17 Nov 2014 14:21:24 +0000 From: John Emmas User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: gtkmm Subject: Re: TreeViewColumn::get_first_cell_renderer() References: <5469E001.1060907@creativepost.co.uk> In-Reply-To: <5469E001.1060907@creativepost.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:GX7ApSQmPocT214ajbmSz5x4tWjw0a2IdybTg0hVx/o E4ZkGVYmsuLyS2dSvaIwJl659n7+Zqob1ucYsjikfUEmtl15m6 g8jaOeLCKa4NqhMZc8cnEL6ECxSgqU3zDejhg7bnubCEW+nSyV h5esEAGczUvdkcjQbolwgHuKKzYC0qd3R/R5ipzZSKzDh/UiE6 TbEmWBaVAN7mPWGTLaljLZ2us3WOFqJCi+vE3rzAdeDM4dn5pr GA9JyDKOGPSL2u7NRoS5hb0pHxYPVGVHOEjqNky1iMQ9smk2Zp sL3RKxYFzx2rePbG1Hrl5K4lVIExx+zkgb4KS5cmplRHw2yyJx LPFDRl/fcSI0WuFf2xqFe12+ADCO8kVs+f2+MhTiC X-UI-Out-Filterresults: notjunk:1; X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 14:21:40 -0000 On 17/11/2014 11:46, John Emmas wrote: > I'm not sure if this is something new or if I just never noticed it > before but round about line 119 of 'gtkmm/treeviewcolumn.cc' I seem to > have these functions:- > > CellRenderer* TreeViewColumn::get_first_cell_renderer() > { > return get_first_cell(); > } > > const CellRenderer* TreeViewColumn::get_first_cell_renderer() const > { > return get_first_cell_renderer(); > } > > I assume the intention was that the 2nd function would call the 1st > one but MSVC warns me that the 2nd function will just call itself > recursively until the stack overflows. Any thoughts anyone? > Apologies - I should have added that this is in git (branch 'gtkmm-2-24'). 'master' (and presumably gtkmm-3-xx?) don't seem to have the above code. John From murrayc@murrayc.com Tue Nov 18 09:57:18 2014 Return-Path: X-Original-To: gtkmm-list@gnome.org Delivered-To: gtkmm-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 4AFE776A00 for ; Tue, 18 Nov 2014 09:57:18 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGqhM2-Bq7Km for ; Tue, 18 Nov 2014 09:57:17 +0000 (UTC) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by restaurant.gnome.org (Postfix) with ESMTP id 46790769D3 for ; Tue, 18 Nov 2014 09:57:06 +0000 (UTC) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 1D13A20A0B; Tue, 18 Nov 2014 04:57:05 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Tue, 18 Nov 2014 04:57:05 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:subject:from:to:cc :date:in-reply-to:references:content-type:mime-version :content-transfer-encoding; s=smtpout; bh=9ti3xUmb9mvM/6OraMI+xM bZowU=; b=CsP8Hip6806UN+glmeSLsUbJS1NdKCj5hz9/rbSTxsKZ7OsZVqGyQ/ 8jzNIYgeOcbuebL/jPIIYOPWAv/1GnmEwz94kZWxXhEwodXQgcYsbOIeJPFpLMzC UVAyIoDB+hRikXZnr2S+ge7KUhNmoOI6FN9bq0Ldhooms6dmz+fbQ= X-Sasl-enc: 0kKSxaKLplnpmZtRph9Pqv2G8vMlz0jwIBOc1nOvgUuH 1416304624 Received: from murrayc-ThinkPad-X220 (unknown [88.217.180.81]) by mail.messagingengine.com (Postfix) with ESMTPA id 232D5680195; Tue, 18 Nov 2014 04:57:03 -0500 (EST) Message-ID: <1416304622.22581.1.camel@murrayc.com> Subject: Re: TreeViewColumn::get_first_cell_renderer() From: Murray Cumming To: John Emmas Date: Tue, 18 Nov 2014 10:57:02 +0100 In-Reply-To: <546A0464.3060208@creativepost.co.uk> References: <5469E001.1060907@creativepost.co.uk> <546A0464.3060208@creativepost.co.uk> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.7-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: gtkmm X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 09:57:18 -0000 On Mon, 2014-11-17 at 14:21 +0000, John Emmas wrote: > Apologies - I should have added that this is in git (branch > 'gtkmm-2-24'). 'master' (and presumably gtkmm-3-xx?) don't seem to have > the above code. We aren't likely to do much work on gtkmm 2, but if you submit a patch in bugzilla then we'll push it. I seem to remember that it's hard to make releases of gtkmm 2, however. -- Murray Cumming murrayc@murrayc.com www.murrayc.com From kjell.ahlstedt@bredband.net Wed Nov 19 15:35:42 2014 Return-Path: X-Original-To: gtkmm-list@gnome.org Delivered-To: gtkmm-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id C80F07693C for ; Wed, 19 Nov 2014 15:35:42 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GW7xw6pJftGB for ; Wed, 19 Nov 2014 15:35:41 +0000 (UTC) Received: from smtprelay-b32.telenor.se (smtprelay-b32.telenor.se [213.150.131.21]) by restaurant.gnome.org (Postfix) with ESMTP id 9B4F3769A0 for ; Wed, 19 Nov 2014 15:35:29 +0000 (UTC) Received: from ipb4.telenor.se (ipb4.telenor.se [195.54.127.167]) by smtprelay-b32.telenor.se (Postfix) with ESMTP id ACC1F879E3 for ; Wed, 19 Nov 2014 16:35:27 +0100 (CET) X-SMTPAUTH-B2: [kjell.ahlstedt@bredband.net] X-SENDER-IP: [85.229.156.35] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AscBAPi3bFRV5ZwjPGdsb2JhbAANTYNjyiiCSIdHAoEdAQEBAQEBBQEBAQE4hD4BAQR4ARALBB0WDwkDAgECATEUBg0BBwEBiEIIvAuXagEBAQEBAQEBAgEBAQEBAQEBARUEkQgHhEsFlzWiI4M3AQEB X-IPAS-Result: AscBAPi3bFRV5ZwjPGdsb2JhbAANTYNjyiiCSIdHAoEdAQEBAQEBBQEBAQE4hD4BAQR4ARALBB0WDwkDAgECATEUBg0BBwEBiEIIvAuXagEBAQEBAQEBAgEBAQEBAQEBARUEkQgHhEsFlzWiI4M3AQEB X-IronPort-AV: E=Sophos;i="5.07,417,1413237600"; d="scan'208,217";a="685068212" Received: from c-239ce555.06-203-73746f44.cust.bredbandsbolaget.se (HELO [192.168.1.64]) ([85.229.156.35]) by ipb4.telenor.se with ESMTP; 19 Nov 2014 16:35:27 +0100 Message-ID: <546CB8BE.6020202@bredband.net> Date: Wed, 19 Nov 2014 16:35:26 +0100 From: Kjell Ahlstedt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: =?windows-1252?Q?J=FCrgen_Kleber?= Subject: Re: Upgrade menu-example-main to Gtk::Application/Gtk::ApplicationWindow? References: <1415900906.10101.2.camel@localhost.localdomain> In-Reply-To: <1415900906.10101.2.camel@localhost.localdomain> Content-Type: multipart/alternative; boundary="------------000807080404080004070103" Cc: gtkmm-list@gnome.org X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 15:35:42 -0000 This is a multi-part message in MIME format. --------------000807080404080004070103 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit If you file a bug in Bugzilla and attach a patch, I can push it to the git repository. If you haven't installed git, and don't want to do it, you can attach the new and the modified files. I can make a patch out of them. Third alternative: File a bug without attachments, and hope for the best. Someone will probably fix it some day, but it will be fixed quicker if you do most of the job yourself. Kjell Den 2014-11-13 18:48, Jürgen Kleber skrev: > Hi, > > quite a lot of Gnome applications have an application menu allowing for > menu items covering the application as a whole to place into the top bar > of Gnome-shell. I should appreciate this feature being reflected in the > menu-example of the gtkmm-tutorial. This could easily be done by > deriving ExampleWindow from Gtk::ApplicationWindow instead from > Gtk::Window and adding a new class ExampleApplication derived from > Gtk::Application using this example > https://git.gnome.org/browse/gtkmm-documentation/tree/examples/book/application/app_and_win_menus > as a guideline. > > Best regards, > Jürgen > > --------------000807080404080004070103 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit If you file a bug in Bugzilla and attach a patch, I can push it to the git repository.
If you haven't installed git, and don't want to do it, you can attach the new and the modified files. I can make a patch out of them.
Third alternative: File a bug without attachments, and hope for the best. Someone will probably fix it some day, but it will be fixed quicker if you do most of the job yourself.

Kjell

Den 2014-11-13 18:48, Jürgen Kleber skrev:

Hi,

quite a lot of Gnome applications have an application menu allowing for
menu items covering the application as a whole to place into the top bar
of Gnome-shell. I should appreciate this feature being reflected in the
menu-example of the gtkmm-tutorial. This could easily be done by
deriving ExampleWindow from Gtk::ApplicationWindow instead from
Gtk::Window and adding a new class ExampleApplication derived from
Gtk::Application using this example
https://git.gnome.org/browse/gtkmm-documentation/tree/examples/book/application/app_and_win_menus
as a guideline.

Best regards,
Jürgen

--------------000807080404080004070103-- From jkleber2701@t-online.de Wed Nov 19 18:55:50 2014 Return-Path: X-Original-To: gtkmm-list@gnome.org Delivered-To: gtkmm-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 8A0E2769E7 for ; Wed, 19 Nov 2014 18:55:50 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILkGk4IVJSJB for ; Wed, 19 Nov 2014 18:55:48 +0000 (UTC) Received: from mailout11.t-online.de (mailout11.t-online.de [194.25.134.85]) by restaurant.gnome.org (Postfix) with ESMTP id 4AA277693C for ; Wed, 19 Nov 2014 18:55:31 +0000 (UTC) Received: from fwd02.aul.t-online.de (fwd02.aul.t-online.de [172.20.26.148]) by mailout11.t-online.de (Postfix) with SMTP id A687C3D12F1; Wed, 19 Nov 2014 19:55:29 +0100 (CET) Received: from cohg (XRfNqkZUYhITqSiLCetAmbmwJP1WOvApxqjbPVcaOb5KXucde9WWhuW3j37lB-zgVs@[79.250.176.251]) by fwd02.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1XrAPZ-1DvyLI0; Wed, 19 Nov 2014 19:55:29 +0100 Message-ID: <1416423328.4534.1.camel@t-online.de> Subject: Re: Upgrade menu-example-main to Gtk::Application/Gtk::ApplicationWindow? From: =?ISO-8859-1?Q?J=FCrgen?= Kleber To: Kjell Ahlstedt Date: Wed, 19 Nov 2014 19:55:28 +0100 In-Reply-To: <546CB8BE.6020202@bredband.net> References: <1415900906.10101.2.camel@localhost.localdomain> <546CB8BE.6020202@bredband.net> Content-Type: multipart/mixed; boundary="=-wrFBfPyEU4HOKuWbZVUE" X-Mailer: Evolution 3.12.7-1 Mime-Version: 1.0 X-ID: XRfNqkZUYhITqSiLCetAmbmwJP1WOvApxqjbPVcaOb5KXucde9WWhuW3j37lB-zgVs X-TOI-MSGID: c1d34f08-582a-409f-ae73-fdfe07a9b0b8 Cc: gtkmm-list@gnome.org X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 18:55:50 -0000 --=-wrFBfPyEU4HOKuWbZVUE Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit I'm following your second proposal and attached the source files, hoping you can make a patch out of them. You can also see the files in http://jkleber.homepage.t-online.de/c ++/menu_appwin_builder_app/index.html . JÃ¼rgen Am Mittwoch, den 19.11.2014, 16:35 +0100 schrieb Kjell Ahlstedt: > If you file a bug in Bugzilla and attach a patch, I can push it to the > git repository. > If you haven't installed git, and don't want to do it, you can attach > the new and the modified files. I can make a patch out of them. > Third alternative: File a bug without attachments, and hope for the > best. Someone will probably fix it some day, but it will be fixed > quicker if you do most of the job yourself. > > Kjell > > Den 2014-11-13 18:48, JÃ¼rgen Kleber skrev: > > > Hi, > > > > quite a lot of Gnome applications have an application menu allowing for > > menu items covering the application as a whole to place into the top bar > > of Gnome-shell. I should appreciate this feature being reflected in the > > menu-example of the gtkmm-tutorial. This could easily be done by > > deriving ExampleWindow from Gtk::ApplicationWindow instead from > > Gtk::Window and adding a new class ExampleApplication derived from > > Gtk::Application using this example > > https://git.gnome.org/browse/gtkmm-documentation/tree/examples/book/application/app_and_win_menus > > as a guideline. > > > > Best regards, > > JÃ¼rgen > > > > > --=-wrFBfPyEU4HOKuWbZVUE Content-Disposition: attachment; filename="exampleapplication.cc" Content-Transfer-Encoding: base64 Content-Type: text/x-c++src; name="exampleapplication.cc"; charset="UTF-8" LyoKICogRW5oYW5jaW5nIHRoZSBtYWluIG1lbnUgZXhhbXBsZSBvZiBndGttbS10dXRvcmlhbC91 bnN0YWJsZSBwcmVzZW50ZWQgaW4KICogaHR0cHM6Ly9kZXZlbG9wZXIuZ25vbWUub3JnL2d0a21t LXR1dG9yaWFsL3Vuc3RhYmxlL1wKICogICAgICAgc2VjLW1lbnVzLWV4YW1wbGVzLmh0bWwuZGUj bWVudS1leGFtcGxlLW1haW4KICogdG8gc2hvdyBhbiBhcHBsaWNhdGlvbiBtZW51IGFzIHN1Z2dl c3RlZCBpbgogKiBodHRwczovL3dpa2kuZ25vbWUub3JnL1RocmVlUG9pbnRUaHJlZS9GZWF0dXJl cy9BcHBsaWNhdGlvbk1lbnUsCiAqIGRlc2NyaWJlZCBpbgogKiBodHRwczovL3dpa2kuZ25vbWUu b3JnL0hvd0RvSS9BcHBsaWNhdGlvbk1lbnUKICogYW5kIHJlYWxpc2VkIHVzaW5nIGd0a21tIGlu CiAqIGh0dHBzOi8vZ2l0Lmdub21lLm9yZy9icm93c2UvZ3RrbW0tZG9jdW1lbnRhdGlvbi90cmVl L2V4YW1wbGVzL2Jvb2svXAogKiAgICAgICBhcHBsaWNhdGlvbi9hcHBfYW5kX3dpbl9tZW51cwog KgogKiBTdGFydGVkIG9uIDIwMTQtMTEtMTAKICogQ3VycmVudCB2ZXJzaW9uOiAyMDE0LTExLTEw CiAqIFBlcmZvcm1lZCBieTogSsO8cmdlbiBLbGViZXIgKGprbGViZXIyNzAxQHQtb25saW5lLmRl KQogKgogKiBPcmlnaW5hbCBmaWxlIGRvd25sb2FkZWQgb24gU3VuZGF5LCA5dGggb2YgTm92ZW1i ZXIsIDIwMTQgZnJvbQogKiBodHRwczovL2dpdC5nbm9tZS5vcmcvYnJvd3NlL2d0a21tLWRvY3Vt ZW50YXRpb24vdHJlZS9leGFtcGxlcy9ib29rL1wKICogICAgICAgYXBwbGljYXRpb24vYXBwX2Fu ZF93aW5fbWVudXMvZXhhbXBsZWFwcGxpY2F0aW9uLmNjCiAqLwoKI2luY2x1ZGUgImV4YW1wbGVh cHBsaWNhdGlvbi5oIgojaW5jbHVkZSAiZXhhbXBsZXdpbmRvdy5oIgojaW5jbHVkZSA8aW9zdHJl YW0+CgpFeGFtcGxlQXBwbGljYXRpb246OkV4YW1wbGVBcHBsaWNhdGlvbigpIDoKICAgICAgR3Rr OjpBcHBsaWNhdGlvbigib3JnLmd0a21tLmV4YW1wbGVzLmFwcGxpY2F0aW9uIikgewogICBHbGli OjpzZXRfYXBwbGljYXRpb25fbmFtZSgiR3RrOjpBcHBsaWNhdGlvbiBFeGFtcGxlIik7CiAgIHdp biA9IDA7Cn0KCkdsaWI6OlJlZlB0cjxFeGFtcGxlQXBwbGljYXRpb24+IEV4YW1wbGVBcHBsaWNh dGlvbjo6Y3JlYXRlKCkgewogICByZXR1cm4gR2xpYjo6UmVmUHRyPEV4YW1wbGVBcHBsaWNhdGlv bj4obmV3IEV4YW1wbGVBcHBsaWNhdGlvbigpKTsKfQoKdm9pZCBFeGFtcGxlQXBwbGljYXRpb246 Om9uX3N0YXJ0dXAoKSB7CiAgIC8vQ2FsbCB0aGUgYmFzZSBjbGFzcydzIGltcGxlbWVudGF0aW9u OgogICBHdGs6OkFwcGxpY2F0aW9uOjpvbl9zdGFydHVwKCk7CgogICAvL0ZpbGV8TmV3IHN1YiBt ZW51OgogICBuZXdzdGFuZGFyZF9hY3Rpb24gPSBhZGRfYWN0aW9uKCJuZXdzdGFuZGFyZCIsCiAg ICAgICAgIHNpZ2M6Om1lbV9mdW4oKnRoaXMsICZFeGFtcGxlQXBwbGljYXRpb246Om9uX21lbnVf ZmlsZV9uZXdfZ2VuZXJpYykpOwoKICAgbmV3Zm9vX2FjdGlvbiA9IGFkZF9hY3Rpb24oIm5ld2Zv byIsCiAgICAgICAgIHNpZ2M6Om1lbV9mdW4oKnRoaXMsICZFeGFtcGxlQXBwbGljYXRpb246Om9u X21lbnVfZmlsZV9uZXdfZ2VuZXJpYykpOwoKICAgbmV3Z29vX2FjdGlvbiA9IGFkZF9hY3Rpb24o Im5ld2dvbyIsCiAgICAgICAgIHNpZ2M6Om1lbV9mdW4oKnRoaXMsICZFeGFtcGxlQXBwbGljYXRp b246Om9uX21lbnVfZmlsZV9uZXdfZ2VuZXJpYykpOwoKICAgLy9GaWxlIG1lbnU6CiAgIHF1aXRf YWN0aW9uID0gYWRkX2FjdGlvbigicXVpdCIsCiAgICAgICAgIHNpZ2M6Om1lbV9mdW4oKnRoaXMs ICZFeGFtcGxlQXBwbGljYXRpb246Om9uX21lbnVfZmlsZV9xdWl0KSk7CgogICAvL0hlbHAgbWVu dToKICAgYWJvdXRfYWN0aW9uID0gYWRkX2FjdGlvbigiYWJvdXQiLAogICAgICAgICBzaWdjOjpt ZW1fZnVuKCp0aGlzLCAmRXhhbXBsZUFwcGxpY2F0aW9uOjpvbl9tZW51X290aGVycykpOwoKICAg bV9yZWZCdWlsZGVyID0gR3RrOjpCdWlsZGVyOjpjcmVhdGUoKTsKCiAgIC8vTGF5b3V0IHRoZSBh Y3Rpb25zIGluIGEgbWVudWJhciBhbmQgdG9vbGJhcjoKICAgR2xpYjo6dXN0cmluZyB1aV9pbmZv ID0KICAgICAgIjxpbnRlcmZhY2U+IgogICAgICAiICA8bWVudSBpZD0nbWVudS1leGFtcGxlJz4i CiAgICAgICIgICAgPHN1Ym1lbnU+IgogICAgICAiICAgICAgPGF0dHJpYnV0ZSBuYW1lPSdsYWJl bCcgdHJhbnNsYXRhYmxlPSd5ZXMnPl9GaWxlPC9hdHRyaWJ1dGU+IgogICAgICAiICAgICAgPHNl Y3Rpb24+IgogICAgICAiICAgICAgICA8aXRlbT4iCiAgICAgICIgICAgICAgICAgPGF0dHJpYnV0 ZSBuYW1lPSdsYWJlbCcgdHJhbnNsYXRhYmxlPSd5ZXMnPk5ldyBfU3RhbmRhcmQ8L2F0dHJpYnV0 ZT4iCiAgICAgICIgICAgICAgICAgPGF0dHJpYnV0ZSBuYW1lPSdhY3Rpb24nPmFwcC5uZXdzdGFu ZGFyZDwvYXR0cmlidXRlPiIKICAgICAgIiAgICAgICAgICA8YXR0cmlidXRlIG5hbWU9J2FjY2Vs Jz4mbHQ7UHJpbWFyeSZndDtuPC9hdHRyaWJ1dGU+IgogICAgICAiICAgICAgICA8L2l0ZW0+Igog ICAgICAiICAgICAgICA8aXRlbT4iCiAgICAgICIgICAgICAgICAgPGF0dHJpYnV0ZSBuYW1lPSds YWJlbCcgdHJhbnNsYXRhYmxlPSd5ZXMnPk5ldyBfRm9vPC9hdHRyaWJ1dGU+IgogICAgICAiICAg ICAgICAgIDxhdHRyaWJ1dGUgbmFtZT0nYWN0aW9uJz5hcHAubmV3Zm9vPC9hdHRyaWJ1dGU+Igog ICAgICAiICAgICAgICA8L2l0ZW0+IgogICAgICAiICAgICAgICA8aXRlbT4iCiAgICAgICIgICAg ICAgICAgPGF0dHJpYnV0ZSBuYW1lPSdsYWJlbCcgdHJhbnNsYXRhYmxlPSd5ZXMnPk5ldyBfR29v PC9hdHRyaWJ1dGU+IgogICAgICAiICAgICAgICAgIDxhdHRyaWJ1dGUgbmFtZT0nYWN0aW9uJz5h cHAubmV3Z29vPC9hdHRyaWJ1dGU+IgogICAgICAiICAgICAgICA8L2l0ZW0+IgogICAgICAiICAg ICAgPC9zZWN0aW9uPiIKICAgICAgIiAgICAgIDxzZWN0aW9uPiIKICAgICAgIiAgICAgICAgPGl0 ZW0+IgogICAgICAiICAgICAgICAgIDxhdHRyaWJ1dGUgbmFtZT0nbGFiZWwnIHRyYW5zbGF0YWJs ZT0neWVzJz5fUXVpdDwvYXR0cmlidXRlPiIKICAgICAgIiAgICAgICAgICA8YXR0cmlidXRlIG5h bWU9J2FjdGlvbic+YXBwLnF1aXQ8L2F0dHJpYnV0ZT4iCiAgICAgICIgICAgICAgICAgPGF0dHJp YnV0ZSBuYW1lPSdhY2NlbCc+Jmx0O1ByaW1hcnkmZ3Q7cTwvYXR0cmlidXRlPiIKICAgICAgIiAg ICAgICAgPC9pdGVtPiIKICAgICAgIiAgICAgIDwvc2VjdGlvbj4iCiAgICAgICIgICAgPC9zdWJt ZW51PiIKICAgICAgIiAgICA8c3VibWVudT4iCiAgICAgICIgICAgICA8YXR0cmlidXRlIG5hbWU9 J2xhYmVsJyB0cmFuc2xhdGFibGU9J3llcyc+X0VkaXQ8L2F0dHJpYnV0ZT4iCiAgICAgICIgICAg ICA8c2VjdGlvbj4iCiAgICAgICIgICAgICAgIDxpdGVtPiIKICAgICAgIiAgICAgICAgICA8YXR0 cmlidXRlIG5hbWU9J2xhYmVsJyB0cmFuc2xhdGFibGU9J3llcyc+X0NvcHk8L2F0dHJpYnV0ZT4i CiAgICAgICIgICAgICAgICAgPGF0dHJpYnV0ZSBuYW1lPSdhY3Rpb24nPndpbi5jb3B5PC9hdHRy aWJ1dGU+IgogICAgICAiICAgICAgICAgIDxhdHRyaWJ1dGUgbmFtZT0nYWNjZWwnPiZsdDtQcmlt YXJ5Jmd0O2M8L2F0dHJpYnV0ZT4iCiAgICAgICIgICAgICAgIDwvaXRlbT4iCiAgICAgICIgICAg ICAgIDxpdGVtPiIKICAgICAgIiAgICAgICAgICA8YXR0cmlidXRlIG5hbWU9J2xhYmVsJyB0cmFu c2xhdGFibGU9J3llcyc+X1Bhc3RlPC9hdHRyaWJ1dGU+IgogICAgICAiICAgICAgICAgIDxhdHRy aWJ1dGUgbmFtZT0nYWN0aW9uJz53aW4ucGFzdGU8L2F0dHJpYnV0ZT4iCiAgICAgICIgICAgICAg ICAgPGF0dHJpYnV0ZSBuYW1lPSdhY2NlbCc+Jmx0O1ByaW1hcnkmZ3Q7djwvYXR0cmlidXRlPiIK ICAgICAgIiAgICAgICAgPC9pdGVtPiIKICAgICAgIiAgICAgICAgPGl0ZW0+IgogICAgICAiICAg ICAgICAgIDxhdHRyaWJ1dGUgbmFtZT0nbGFiZWwnIHRyYW5zbGF0YWJsZT0neWVzJz5fU29tZXRo aW5nPC9hdHRyaWJ1dGU+IgogICAgICAiICAgICAgICAgIDxhdHRyaWJ1dGUgbmFtZT0nYWN0aW9u Jz53aW4uc29tZXRoaW5nPC9hdHRyaWJ1dGU+IgogICAgICAiICAgICAgICA8L2l0ZW0+IgogICAg ICAiICAgICAgPC9zZWN0aW9uPiIKICAgICAgIiAgICA8L3N1Ym1lbnU+IgogICAgICAiICAgIDxz dWJtZW51PiIKICAgICAgIiAgICAgIDxhdHRyaWJ1dGUgbmFtZT0nbGFiZWwnIHRyYW5zbGF0YWJs ZT0neWVzJz5fQ2hvaWNlczwvYXR0cmlidXRlPiIKICAgICAgIiAgICAgIDxzZWN0aW9uPiIKICAg ICAgIiAgICAgICAgPGl0ZW0+IgogICAgICAiICAgICAgICAgIDxhdHRyaWJ1dGUgbmFtZT0nbGFi ZWwnIHRyYW5zbGF0YWJsZT0neWVzJz5DaG9pY2UgX0E8L2F0dHJpYnV0ZT4iCiAgICAgICIgICAg ICAgICAgPGF0dHJpYnV0ZSBuYW1lPSdhY3Rpb24nPndpbi5jaG9pY2U8L2F0dHJpYnV0ZT4iCiAg ICAgICIgICAgICAgICAgPGF0dHJpYnV0ZSBuYW1lPSd0YXJnZXQnPmE8L2F0dHJpYnV0ZT4iCiAg ICAgICIgICAgICAgIDwvaXRlbT4iCiAgICAgICIgICAgICAgIDxpdGVtPiIKICAgICAgIiAgICAg ICAgICA8YXR0cmlidXRlIG5hbWU9J2xhYmVsJyB0cmFuc2xhdGFibGU9J3llcyc+Q2hvaWNlIF9C PC9hdHRyaWJ1dGU+IgogICAgICAiICAgICAgICAgIDxhdHRyaWJ1dGUgbmFtZT0nYWN0aW9uJz53 aW4uY2hvaWNlPC9hdHRyaWJ1dGU+IgogICAgICAiICAgICAgICAgIDxhdHRyaWJ1dGUgbmFtZT0n dGFyZ2V0Jz5iPC9hdHRyaWJ1dGU+IgogICAgICAiICAgICAgICA8L2l0ZW0+IgogICAgICAiICAg ICAgPC9zZWN0aW9uPiIKICAgICAgIiAgICA8L3N1Ym1lbnU+IgogICAgICAiICAgIDxzdWJtZW51 PiIKICAgICAgIiAgICAgIDxhdHRyaWJ1dGUgbmFtZT0nbGFiZWwnIHRyYW5zbGF0YWJsZT0neWVz Jz5fT3RoZXIgQ2hvaWNlczwvYXR0cmlidXRlPiIKICAgICAgIiAgICAgIDxzZWN0aW9uPiIKICAg ICAgIiAgICAgICAgPGl0ZW0+IgogICAgICAiICAgICAgICAgIDxhdHRyaWJ1dGUgbmFtZT0nbGFi ZWwnIHRyYW5zbGF0YWJsZT0neWVzJz5DaG9pY2UgMTwvYXR0cmlidXRlPiIKICAgICAgIiAgICAg ICAgICA8YXR0cmlidXRlIG5hbWU9J2FjdGlvbic+d2luLmNob2ljZW90aGVyPC9hdHRyaWJ1dGU+ IgogICAgICAiICAgICAgICAgIDxhdHRyaWJ1dGUgbmFtZT0ndGFyZ2V0JyB0eXBlPSdpJz4xPC9h dHRyaWJ1dGU+IgogICAgICAiICAgICAgICA8L2l0ZW0+IgogICAgICAiICAgICAgICA8aXRlbT4i CiAgICAgICIgICAgICAgICAgPGF0dHJpYnV0ZSBuYW1lPSdsYWJlbCcgdHJhbnNsYXRhYmxlPSd5 ZXMnPkNob2ljZSAyPC9hdHRyaWJ1dGU+IgogICAgICAiICAgICAgICAgIDxhdHRyaWJ1dGUgbmFt ZT0nYWN0aW9uJz53aW4uY2hvaWNlb3RoZXI8L2F0dHJpYnV0ZT4iCiAgICAgICIgICAgICAgICAg PGF0dHJpYnV0ZSBuYW1lPSd0YXJnZXQnIHR5cGU9J2knPjI8L2F0dHJpYnV0ZT4iCiAgICAgICIg ICAgICAgIDwvaXRlbT4iCiAgICAgICIgICAgICA8L3NlY3Rpb24+IgogICAgICAiICAgICAgPHNl Y3Rpb24+IgogICAgICAiICAgICAgICA8aXRlbT4iCiAgICAgICIgICAgICAgICAgPGF0dHJpYnV0 ZSBuYW1lPSdsYWJlbCcgdHJhbnNsYXRhYmxlPSd5ZXMnPlNvbWUgVG9nZ2xlPC9hdHRyaWJ1dGU+ IgogICAgICAiICAgICAgICAgIDxhdHRyaWJ1dGUgbmFtZT0nYWN0aW9uJz53aW4uc29tZXRvZ2ds ZTwvYXR0cmlidXRlPiIKICAgICAgIiAgICAgICAgPC9pdGVtPiIKICAgICAgIiAgICAgIDwvc2Vj dGlvbj4iCiAgICAgICIgICAgPC9zdWJtZW51PiIKICAgICAgIiAgICA8c3VibWVudT4iCiAgICAg ICIgICAgICA8YXR0cmlidXRlIG5hbWU9J2xhYmVsJyB0cmFuc2xhdGFibGU9J3llcyc+X0hlbHA8 L2F0dHJpYnV0ZT4iCiAgICAgICIgICAgICA8c2VjdGlvbj4iCiAgICAgICIgICAgICAgIDxpdGVt PiIKICAgICAgIiAgICAgICAgICA8YXR0cmlidXRlIG5hbWU9J2xhYmVsJyB0cmFuc2xhdGFibGU9 J3llcyc+X0Fib3V0PC9hdHRyaWJ1dGU+IgogICAgICAiICAgICAgICAgIDxhdHRyaWJ1dGUgbmFt ZT0nYWN0aW9uJz5hcHAuYWJvdXQ8L2F0dHJpYnV0ZT4iCiAgICAgICIgICAgICAgIDwvaXRlbT4i CiAgICAgICIgICAgICA8L3NlY3Rpb24+IgogICAgICAiICAgIDwvc3VibWVudT4iCiAgICAgICIg IDwvbWVudT4iCiAgICAgICIgIDxtZW51IGlkPSdhcHBtZW51Jz4iCiAgICAgICIgICAgPHN1Ym1l bnU+IgogICAgICAiICAgICAgPGF0dHJpYnV0ZSBuYW1lPSdsYWJlbCcgdHJhbnNsYXRhYmxlPSd5 ZXMnPl9GaWxlPC9hdHRyaWJ1dGU+IgogICAgICAiICAgICAgPHNlY3Rpb24+IgogICAgICAiICAg ICAgICA8aXRlbT4iCiAgICAgICIgICAgICAgICAgPGF0dHJpYnV0ZSBuYW1lPSdsYWJlbCcgdHJh bnNsYXRhYmxlPSd5ZXMnPk5ldyBfU3RhbmRhcmQ8L2F0dHJpYnV0ZT4iCiAgICAgICIgICAgICAg ICAgPGF0dHJpYnV0ZSBuYW1lPSdhY3Rpb24nPmFwcC5uZXdzdGFuZGFyZDwvYXR0cmlidXRlPiIK ICAgICAgIiAgICAgICAgICA8YXR0cmlidXRlIG5hbWU9J2FjY2VsJz4mbHQ7UHJpbWFyeSZndDtu PC9hdHRyaWJ1dGU+IgogICAgICAiICAgICAgICA8L2l0ZW0+IgogICAgICAiICAgICAgICA8aXRl bT4iCiAgICAgICIgICAgICAgICAgPGF0dHJpYnV0ZSBuYW1lPSdsYWJlbCcgdHJhbnNsYXRhYmxl PSd5ZXMnPk5ldyBfRm9vPC9hdHRyaWJ1dGU+IgogICAgICAiICAgICAgICAgIDxhdHRyaWJ1dGUg bmFtZT0nYWN0aW9uJz5hcHAubmV3Zm9vPC9hdHRyaWJ1dGU+IgogICAgICAiICAgICAgICA8L2l0 ZW0+IgogICAgICAiICAgICAgICA8aXRlbT4iCiAgICAgICIgICAgICAgICAgPGF0dHJpYnV0ZSBu YW1lPSdsYWJlbCcgdHJhbnNsYXRhYmxlPSd5ZXMnPk5ldyBfR29vPC9hdHRyaWJ1dGU+IgogICAg ICAiICAgICAgICAgIDxhdHRyaWJ1dGUgbmFtZT0nYWN0aW9uJz5hcHAubmV3Z29vPC9hdHRyaWJ1 dGU+IgogICAgICAiICAgICAgICA8L2l0ZW0+IgogICAgICAiICAgICAgPC9zZWN0aW9uPiIKICAg ICAgIiAgICAgIDxzZWN0aW9uPiIKICAgICAgIiAgICAgICAgPGl0ZW0+IgogICAgICAiICAgICAg ICAgIDxhdHRyaWJ1dGUgbmFtZT0nbGFiZWwnIHRyYW5zbGF0YWJsZT0neWVzJz5fUXVpdDwvYXR0 cmlidXRlPiIKICAgICAgIiAgICAgICAgICA8YXR0cmlidXRlIG5hbWU9J2FjdGlvbic+YXBwLnF1 aXQ8L2F0dHJpYnV0ZT4iCiAgICAgICIgICAgICAgICAgPGF0dHJpYnV0ZSBuYW1lPSdhY2NlbCc+ Jmx0O1ByaW1hcnkmZ3Q7cTwvYXR0cmlidXRlPiIKICAgICAgIiAgICAgICAgPC9pdGVtPiIKICAg ICAgIiAgICAgIDwvc2VjdGlvbj4iCiAgICAgICIgICAgPC9zdWJtZW51PiIKICAgICAgIiAgICA8 c3VibWVudT4iCiAgICAgICIgICAgICA8YXR0cmlidXRlIG5hbWU9J2xhYmVsJyB0cmFuc2xhdGFi bGU9J3llcyc+X0hlbHA8L2F0dHJpYnV0ZT4iCiAgICAgICIgICAgICA8c2VjdGlvbj4iCiAgICAg ICIgICAgICAgIDxpdGVtPiIKICAgICAgIiAgICAgICAgICA8YXR0cmlidXRlIG5hbWU9J2xhYmVs JyB0cmFuc2xhdGFibGU9J3llcyc+X0Fib3V0PC9hdHRyaWJ1dGU+IgogICAgICAiICAgICAgICAg IDxhdHRyaWJ1dGUgbmFtZT0nYWN0aW9uJz5hcHAuYWJvdXQ8L2F0dHJpYnV0ZT4iCiAgICAgICIg ICAgICAgIDwvaXRlbT4iCiAgICAgICIgICAgICA8L3NlY3Rpb24+IgogICAgICAiICAgIDwvc3Vi bWVudT4iCiAgICAgICIgIDwvbWVudT4iCiAgICAgICI8L2ludGVyZmFjZT4iOwoKICAgdHJ5IHsK ICAgICAgbV9yZWZCdWlsZGVyLT5hZGRfZnJvbV9zdHJpbmcodWlfaW5mbyk7CiAgIH0gY2F0Y2gg KGNvbnN0IEdsaWI6OkVycm9yJiBleCkgewogICAgICBzdGQ6OmNlcnIgPDwgImJ1aWxkaW5nIG1l bnVzIGZhaWxlZDogIiA8PCBleC53aGF0KCk7CiAgIH0KCiAgIC8vR2V0IHRoZSBtZW51YmFyIGFu ZCBhZGQgaXQgdG8gYSBjb250YWluZXIgd2lkZ2V0OgogICBHbGliOjpSZWZQdHI8R2xpYjo6T2Jq ZWN0PiBvYmplY3QgPSBtX3JlZkJ1aWxkZXItPmdldF9vYmplY3QoIm1lbnUtZXhhbXBsZSIpOwog ICBHbGliOjpSZWZQdHI8R2lvOjpNZW51PiBnbWVudSA9IEdsaWI6OlJlZlB0cjxHaW86Ok1lbnU+ OjpjYXN0X2R5bmFtaWMoCiAgICAgICAgIG9iamVjdCk7CiAgIG9iamVjdCA9IG1fcmVmQnVpbGRl ci0+Z2V0X29iamVjdCgiYXBwbWVudSIpOwogICBHbGliOjpSZWZQdHI8R2lvOjpNZW51PiBhcHBN ZW51ID0gR2xpYjo6UmVmUHRyPEdpbzo6TWVudT46OmNhc3RfZHluYW1pYygKICAgICAgICAgb2Jq ZWN0KTsKICAgaWYgKCEoZ21lbnUgJiYgYXBwTWVudSkpIHsKICAgICAgZ193YXJuaW5nKCJHTWVu dSBvciBBcHBNZW51IG5vdCBmb3VuZCIpOwogICB9IGVsc2UgewogICAgICBzZXRfYXBwX21lbnUo YXBwTWVudSk7CiAgICAgIHNldF9tZW51YmFyKGdtZW51KTsKICAgfQp9Cgp2b2lkIEV4YW1wbGVB cHBsaWNhdGlvbjo6Y3JlYXRlX3dpbmRvdygpIHsKICAgd2luID0gbmV3IEV4YW1wbGVXaW5kb3co KTsKCiAgIC8vTWFrZSBzdXJlIHRoYXQgdGhlIGFwcGxpY2F0aW9uIHJ1bnMgZm9yIGFzIGxvbmcg dGhpcyB3aW5kb3cgaXMgc3RpbGwgb3BlbjoKICAgYWRkX3dpbmRvdygqd2luKTsKCiAgIC8vRGVs ZXRlIHRoZSB3aW5kb3cgd2hlbiBpdCBpcyBoaWRkZW4uCiAgIC8vVGhhdCdzIGVub3VnaCBmb3Ig dGhpcyBzaW1wbGUgZXhhbXBsZS4KICAgd2luLT5zaWduYWxfaGlkZSgpLmNvbm5lY3QoCiAgICAg ICAgIHNpZ2M6OmJpbmQ8R3RrOjpXaW5kb3cqPigKICAgICAgICAgICAgICAgc2lnYzo6bWVtX2Z1 bigqdGhpcywgJkV4YW1wbGVBcHBsaWNhdGlvbjo6b25fd2luZG93X2hpZGUpLCB3aW4pKTsKCiAg IHdpbi0+c2hvd19hbGwoKTsKfQoKdm9pZCBFeGFtcGxlQXBwbGljYXRpb246Om9uX3dpbmRvd19o aWRlKEd0azo6V2luZG93KiB3aW5kb3cpIHsKICAgZGVsZXRlIHdpbmRvdzsKfQoKdm9pZCBFeGFt cGxlQXBwbGljYXRpb246Om9uX2FjdGl2YXRlKCkgewogICAvL3N0ZDo6Y291dCA8PCAiZGVidWcx OiAiIDw8IEdfU1RSRlVOQyA8PCBzdGQ6OmVuZGw7CiAgIC8vIFRoZSBhcHBsaWNhdGlvbiBoYXMg YmVlbiBzdGFydGVkLCBzbyBsZXQncyBzaG93IGEgd2luZG93LgogICAvLyBBIHJlYWwgYXBwbGlj YXRpb24gbWlnaHQgd2FudCB0byByZXVzZSB0aGlzICJlbXB0eSIgd2luZG93IGluIG9uX29wZW4o KSwKICAgLy8gd2hlbiBhc2tlZCB0byBvcGVuIGEgZmlsZSwgaWYgbm8gY2hhbmdlcyBoYXZlIGJl ZW4gbWFkZSB5ZXQuCiAgIGNyZWF0ZV93aW5kb3coKTsKfQoKdm9pZCBFeGFtcGxlQXBwbGljYXRp b246Om9uX21lbnVfZmlsZV9uZXdfZ2VuZXJpYygpIHsKICAgc3RkOjpjb3V0IDw8ICJBIEZpbGV8 TmV3IG1lbnUgaXRlbSB3YXMgc2VsZWN0ZWQuIiA8PCBzdGQ6OmVuZGw7Cn0KCnZvaWQgRXhhbXBs ZUFwcGxpY2F0aW9uOjpvbl9tZW51X2ZpbGVfcXVpdCgpIHsKICAgc3RkOjpjb3V0IDw8IEdfU1RS RlVOQyA8PCBzdGQ6OmVuZGw7CiAgIHF1aXQoKTsgLy8gTm90IHJlYWxseSBuZWNlc3NhcnksIHdo ZW4gR3RrOjpXaWRnZXQ6OmhpZGUoKSBpcyBjYWxsZWQuCgogICAvLyBHaW86OkFwcGxpY2F0aW9u OjpxdWl0KCkgd2lsbCBtYWtlIEdpbzo6QXBwbGljYXRpb246OnJ1bigpIHJldHVybiwKICAgLy8g YnV0IGl0J3MgYSBjcnVkZSB3YXkgb2YgZW5kaW5nIHRoZSBwcm9ncmFtLiBUaGUgd2luZG93IGlz IG5vdCByZW1vdmVkCiAgIC8vIGZyb20gdGhlIGFwcGxpY2F0aW9uLiBOZWl0aGVyIHRoZSB3aW5k b3cncyBub3IgdGhlIGFwcGxpY2F0aW9uJ3MKICAgLy8gZGVzdHJ1Y3RvcnMgd2lsbCBiZSBjYWxs ZWQsIGJlY2F1c2UgdGhlcmUgd2lsbCBiZSByZW1haW5pbmcgcmVmZXJlbmNlCiAgIC8vIGNvdW50 cyBpbiBib3RoIG9mIHRoZW0uIElmIHdlIHdhbnQgdGhlIGRlc3RydWN0b3JzIHRvIGJlIGNhbGxl ZCwgd2UKICAgLy8gbXVzdCByZW1vdmUgdGhlIHdpbmRvdyBmcm9tIHRoZSBhcHBsaWNhdGlvbi4g T25lIHdheSBvZiBkb2luZyB0aGlzCiAgIC8vIGlzIHRvIGhpZGUgdGhlIHdpbmRvdy4KICAgc3Rk Ojp2ZWN0b3I8R3RrOjpXaW5kb3cqPiB3aW5kb3dzID0gZ2V0X3dpbmRvd3MoKTsKICAgaWYgKHdp bmRvd3Muc2l6ZSgpID4gMCkKICAgICAgd2luZG93c1swXS0+aGlkZSgpOyAvLyBJbiB0aGlzIHNp bXBsZSBjYXNlLCB3ZSBrbm93IHRoZXJlIGlzIG9ubHkgb25lIHdpbmRvdy4KfQoKdm9pZCBFeGFt cGxlQXBwbGljYXRpb246Om9uX21lbnVfb3RoZXJzKCkgewogICBzdGQ6OmNvdXQgPDwgIkEgbWVu dSBpdGVtIHdhcyBzZWxlY3RlZC4iIDw8IHN0ZDo6ZW5kbDsKfQoK --=-wrFBfPyEU4HOKuWbZVUE Content-Disposition: attachment; filename="exampleapplication.h" Content-Transfer-Encoding: base64 Content-Type: text/x-chdr; name="exampleapplication.h"; charset="UTF-8" LyoKICogRW5oYW5jaW5nIHRoZSBtYWluIG1lbnUgZXhhbXBsZSBvZiBndGttbS10dXRvcmlhbC91 bnN0YWJsZSBwcmVzZW50ZWQgaW4KICogaHR0cHM6Ly9kZXZlbG9wZXIuZ25vbWUub3JnL2d0a21t LXR1dG9yaWFsL3Vuc3RhYmxlL1wKICogICAgICAgc2VjLW1lbnVzLWV4YW1wbGVzLmh0bWwuZGUj bWVudS1leGFtcGxlLW1haW4KICogdG8gc2hvdyBhbiBhcHBsaWNhdGlvbiBtZW51IGFzIHN1Z2dl c3RlZCBpbgogKiBodHRwczovL3dpa2kuZ25vbWUub3JnL1RocmVlUG9pbnRUaHJlZS9GZWF0dXJl cy9BcHBsaWNhdGlvbk1lbnUsCiAqIGRlc2NyaWJlZCBpbgogKiBodHRwczovL3dpa2kuZ25vbWUu b3JnL0hvd0RvSS9BcHBsaWNhdGlvbk1lbnUKICogYW5kIHJlYWxpc2VkIHVzaW5nIGd0a21tIGlu CiAqIGh0dHBzOi8vZ2l0Lmdub21lLm9yZy9icm93c2UvZ3RrbW0tZG9jdW1lbnRhdGlvbi90cmVl L2V4YW1wbGVzL2Jvb2svXAogKiAgICAgICBhcHBsaWNhdGlvbi9hcHBfYW5kX3dpbl9tZW51cwog KgogKiBTdGFydGVkIG9uIDIwMTQtMTEtMTAKICogQ3VycmVudCB2ZXJzaW9uOiAyMDE0LTExLTEw CiAqIFBlcmZvcm1lZCBieTogSsO8cmdlbiBLbGViZXIgKGprbGViZXIyNzAxQHQtb25saW5lLmRl KQogKgogKiBPcmlnaW5hbCBmaWxlIGRvd25sb2FkZWQgb24gU3VuZGF5LCA5dGggb2YgTm92ZW1i ZXIsIDIwMTQgZnJvbQogKiBodHRwczovL2dpdC5nbm9tZS5vcmcvYnJvd3NlL2d0a21tLWRvY3Vt ZW50YXRpb24vdHJlZS9leGFtcGxlcy9ib29rL1wKICogICAgICAgYXBwbGljYXRpb24vYXBwX2Fu ZF93aW5fbWVudXMvZXhhbXBsZWFwcGxpY2F0aW9uLmgKICovCgojaWZuZGVmIEdUS01NX0VYQU1Q TEVBUFBMSUNBVElPTl9ICiNkZWZpbmUgR1RLTU1fRVhBTVBMRUFQUExJQ0FUSU9OX0gKCiNpbmNs dWRlIDxndGttbS9hcHBsaWNhdGlvbi5oPgojaW5jbHVkZSA8Z3RrbW0vYnVpbGRlci5oPgojaW5j bHVkZSA8Z3RrbW0vd2luZG93Lmg+CgojaW5jbHVkZSAiZXhhbXBsZXdpbmRvdy5oIgoKY2xhc3Mg RXhhbXBsZUFwcGxpY2F0aW9uOiBwdWJsaWMgR3RrOjpBcHBsaWNhdGlvbgp7CnByb3RlY3RlZDoK ICBFeGFtcGxlQXBwbGljYXRpb24oKTsKCnB1YmxpYzoKICBzdGF0aWMgR2xpYjo6UmVmUHRyPEV4 YW1wbGVBcHBsaWNhdGlvbj4gY3JlYXRlKCk7Cgpwcm90ZWN0ZWQ6CiAgLy9PdmVycmlkZXMgb2Yg ZGVmYXVsdCBzaWduYWwgaGFuZGxlcnM6CiAgdmlydHVhbCB2b2lkIG9uX2FjdGl2YXRlKCk7CiAg dmlydHVhbCB2b2lkIG9uX3N0YXJ0dXAoKTsKCnByaXZhdGU6CiAgR2xpYjo6UmVmUHRyPEdpbzo6 U2ltcGxlQWN0aW9uPiBuZXdzdGFuZGFyZF9hY3Rpb247CiAgR2xpYjo6UmVmUHRyPEdpbzo6U2lt cGxlQWN0aW9uPiBuZXdmb29fYWN0aW9uOwogIEdsaWI6OlJlZlB0cjxHaW86OlNpbXBsZUFjdGlv bj4gbmV3Z29vX2FjdGlvbjsKICBHbGliOjpSZWZQdHI8R2lvOjpTaW1wbGVBY3Rpb24+IHF1aXRf YWN0aW9uOwogIEdsaWI6OlJlZlB0cjxHaW86OlNpbXBsZUFjdGlvbj4gYWJvdXRfYWN0aW9uOwog IEdsaWI6OlJlZlB0cjxHdGs6OkJ1aWxkZXI+IG1fcmVmQnVpbGRlcjsKCiAgRXhhbXBsZVdpbmRv dyogd2luOwoKICB2b2lkIG9uX21lbnVfZmlsZV9uZXdfZ2VuZXJpYygpOwogIHZvaWQgb25fbWVu dV9maWxlX3F1aXQoKTsKICB2b2lkIG9uX21lbnVfb3RoZXJzKCk7CiAgdm9pZCBjcmVhdGVfd2lu ZG93KCk7CgogIHZvaWQgb25fd2luZG93X2hpZGUoR3RrOjpXaW5kb3cqIHdpbmRvdyk7Cn07Cgoj ZW5kaWYgLyogR1RLTU1fRVhBTVBMRUFQUExJQ0FUSU9OX0ggKi8KCg== --=-wrFBfPyEU4HOKuWbZVUE Content-Disposition: attachment; filename="examplewindow.cc" Content-Transfer-Encoding: base64 Content-Type: text/x-c++src; name="examplewindow.cc"; charset="UTF-8" LyoKICogRW5oYW5jaW5nIHRoZSBtYWluIG1lbnUgZXhhbXBsZSBvZiBndGttbS10dXRvcmlhbC91 bnN0YWJsZSBwcmVzZW50ZWQgaW4KICogaHR0cHM6Ly9kZXZlbG9wZXIuZ25vbWUub3JnL2d0a21t LXR1dG9yaWFsL3Vuc3RhYmxlL1wKICogICAgICAgc2VjLW1lbnVzLWV4YW1wbGVzLmh0bWwuZGUj bWVudS1leGFtcGxlLW1haW4KICogdG8gc2hvdyBhbiBhcHBsaWNhdGlvbiBtZW51IGFzIHN1Z2dl c3RlZCBpbgogKiBodHRwczovL3dpa2kuZ25vbWUub3JnL1RocmVlUG9pbnRUaHJlZS9GZWF0dXJl cy9BcHBsaWNhdGlvbk1lbnUsCiAqIGRlc2NyaWJlZCBpbgogKiBodHRwczovL3dpa2kuZ25vbWUu b3JnL0hvd0RvSS9BcHBsaWNhdGlvbk1lbnUKICogYW5kIHJlYWxpc2VkIHVzaW5nIGd0a21tIGlu CiAqIGh0dHBzOi8vZ2l0Lmdub21lLm9yZy9icm93c2UvZ3RrbW0tZG9jdW1lbnRhdGlvbi90cmVl L2V4YW1wbGVzL2Jvb2svXAogKiAgICAgICBhcHBsaWNhdGlvbi9hcHBfYW5kX3dpbl9tZW51cwog KgogKiBTdGFydGVkIG9uIDIwMTQtMTEtMTAKICogQ3VycmVudCB2ZXJzaW9uOiAyMDE0LTExLTEw CiAqIFBlcmZvcm1lZCBieTogSsO8cmdlbiBLbGViZXIgKGprbGViZXIyNzAxQHQtb25saW5lLmRl KQogKgogKiBPcmlnaW5hbCBmaWxlIGRvd25sb2FkZWQgb24gU3VuZGF5LCA5dGggb2YgTm92ZW1i ZXIsIDIwMTQgZnJvbQogKiBodHRwczovL2dpdC5nbm9tZS5vcmcvYnJvd3NlL2d0a21tLWRvY3Vt ZW50YXRpb24vdHJlZS9leGFtcGxlcy9ib29rL21lbnVzL1wKICogICAgICAgbWFpbl9tZW51L2V4 YW1wbGV3aW5kb3cuY2MKICovCgojaW5jbHVkZSAiZXhhbXBsZXdpbmRvdy5oIgojaW5jbHVkZSA8 aW9zdHJlYW0+CgpFeGFtcGxlV2luZG93OjpFeGFtcGxlV2luZG93KCkgOiBHdGs6OkFwcGxpY2F0 aW9uV2luZG93KCksCiAgICAgIG1fQm94KEd0azo6T1JJRU5UQVRJT05fVkVSVElDQUwpIHsKICAg c2V0X3RpdGxlKCJtYWluIG1lbnUgZXhhbXBsZSIpOwogICBzZXRfZGVmYXVsdF9zaXplKDMwMCwg MTAwKTsKCiAgIGFkZChtX0JveCk7IC8vIHB1dCBhIE1lbnVCYXIgYXQgdGhlIHRvcCBvZiB0aGUg Ym94IGFuZCBvdGhlciBzdHVmZiBiZWxvdyBpdC4KCiAgIC8vQ3JlYXRlIGFjdGlvbnMgZm9yIG1l bnVzIGFuZCB0b29sYmFyczoKICAgR2xpYjo6UmVmUHRyPEdpbzo6U2ltcGxlQWN0aW9uR3JvdXA+ IHJlZkFjdGlvbkdyb3VwID0KICAgICAgICAgR2lvOjpTaW1wbGVBY3Rpb25Hcm91cDo6Y3JlYXRl KCk7CiAgIC8vRWRpdCBtZW51OgogICByZWZBY3Rpb25Hcm91cC0+YWRkX2FjdGlvbigiY29weSIs CiAgICAgICAgIHNpZ2M6Om1lbV9mdW4oKnRoaXMsICZFeGFtcGxlV2luZG93Ojpvbl9tZW51X290 aGVycykpOwogICByZWZBY3Rpb25Hcm91cC0+YWRkX2FjdGlvbigicGFzdGUiLAogICAgICAgICBz aWdjOjptZW1fZnVuKCp0aGlzLCAmRXhhbXBsZVdpbmRvdzo6b25fbWVudV9vdGhlcnMpKTsKICAg cmVmQWN0aW9uR3JvdXAtPmFkZF9hY3Rpb24oInNvbWV0aGluZyIsCiAgICAgICAgIHNpZ2M6Om1l bV9mdW4oKnRoaXMsICZFeGFtcGxlV2luZG93Ojpvbl9tZW51X290aGVycykpOwoKICAgLy9DaG9p Y2VzIG1lbnVzLCB0byBkZW1vbnN0cmF0ZSBSYWRpbyBpdGVtcywKICAgLy91c2luZyBvdXIgY29u dmVuaWVuY2UgbWV0aG9kcyBmb3Igc3RyaW5nIGFuZCBpbnQgcmFkaW8gdmFsdWVzOgogICBtX3Jl ZkNob2ljZSA9IHJlZkFjdGlvbkdyb3VwLT5hZGRfYWN0aW9uX3JhZGlvX3N0cmluZygiY2hvaWNl IiwKICAgICAgICAgc2lnYzo6bWVtX2Z1bigqdGhpcywgJkV4YW1wbGVXaW5kb3c6Om9uX21lbnVf Y2hvaWNlcyksICJhIik7CgogICBtX3JlZkNob2ljZU90aGVyID0gcmVmQWN0aW9uR3JvdXAtPmFk ZF9hY3Rpb25fcmFkaW9faW50ZWdlcigiY2hvaWNlb3RoZXIiLAogICAgICAgICBzaWdjOjptZW1f ZnVuKCp0aGlzLCAmRXhhbXBsZVdpbmRvdzo6b25fbWVudV9jaG9pY2VzX290aGVyKSwgMSk7Cgog ICBtX3JlZlRvZ2dsZSA9IHJlZkFjdGlvbkdyb3VwLT5hZGRfYWN0aW9uX2Jvb2woInNvbWV0b2dn bGUiLAogICAgICAgICBzaWdjOjptZW1fZnVuKCp0aGlzLCAmRXhhbXBsZVdpbmRvdzo6b25fbWVu dV90b2dnbGUpLCBmYWxzZSk7CgogICAvL0hlbHAgbWVudToKICAgcmVmQWN0aW9uR3JvdXAtPmFk ZF9hY3Rpb24oImFib3V0IiwKICAgICAgICAgc2lnYzo6bWVtX2Z1bigqdGhpcywgJkV4YW1wbGVX aW5kb3c6Om9uX21lbnVfb3RoZXJzKSk7CgogICAvLyBBZGQgYSBwcmVmaXggdG8gdGhlIGFjdGlv bnMgZGVjbGFyZWQgaW4gdGhlIC54bWwgZmlsZQogICBpbnNlcnRfYWN0aW9uX2dyb3VwKCJ3aW4i LCByZWZBY3Rpb25Hcm91cCk7CgogICAvL0NyZWF0ZSB0aGUgdG9vbGJhciBhbmQgYWRkIGl0IHRv IGEgY29udGFpbmVyIHdpZGdldDoKICAgR3RrOjpUb29sYmFyKiB0b29sYmFyID0gR3RrOjptYW5h Z2UobmV3IEd0azo6VG9vbGJhcigpKTsKICAgR3RrOjpUb29sQnV0dG9uKiBidXR0b24gPSBHdGs6 Om1hbmFnZShuZXcgR3RrOjpUb29sQnV0dG9uKCkpOwogICBidXR0b24tPnNldF9pY29uX25hbWUo ImRvY3VtZW50LW5ldyIpOwogICAvLyBXZSBjYW4ndCBkbyB0aGlzIHVudGlsIHdlIGNhbiBicmVh ayB0aGUgVG9vbEJ1dHRvbiBBQkk6CiAgIC8vICAgIGJ1dHRvbi0+c2V0X2RldGFpbGVkX2FjdGlv bl9uYW1lKCJleGFtcGxlLm5ldyIpOwogICBndGtfYWN0aW9uYWJsZV9zZXRfZGV0YWlsZWRfYWN0 aW9uX25hbWUoR1RLX0FDVElPTkFCTEUoYnV0dG9uLT5nb2JqKCkpLAogICAgICAgICAiYXBwLm5l d3N0YW5kYXJkIik7CiAgIHRvb2xiYXItPmFkZCgqYnV0dG9uKTsKCiAgIGJ1dHRvbiA9IEd0azo6 bWFuYWdlKG5ldyBHdGs6OlRvb2xCdXR0b24oKSk7CiAgIGJ1dHRvbi0+c2V0X2ljb25fbmFtZSgi YXBwbGljYXRpb24tZXhpdCIpOwogICAvLyBXZSBjYW4ndCBkbyB0aGlzIHVudGlsIHdlIGNhbiBi cmVhayB0aGUgVG9vbEJ1dHRvbiBBQkk6CiAgIC8vICAgIGJ1dHRvbi0+c2V0X2RldGFpbGVkX2Fj dGlvbl9uYW1lKCJleGFtcGxlLnF1aXQiKTsKICAgZ3RrX2FjdGlvbmFibGVfc2V0X2RldGFpbGVk X2FjdGlvbl9uYW1lKEdUS19BQ1RJT05BQkxFKGJ1dHRvbi0+Z29iaigpKSwKICAgICAgICAgImFw cC5xdWl0Iik7CiAgIHRvb2xiYXItPmFkZCgqYnV0dG9uKTsKCiAgIG1fQm94LnBhY2tfc3RhcnQo KnRvb2xiYXIsIEd0azo6UEFDS19TSFJJTkspOwoKfQoKRXhhbXBsZVdpbmRvdzo6fkV4YW1wbGVX aW5kb3coKSB7Cn0KCnZvaWQgRXhhbXBsZVdpbmRvdzo6b25fbWVudV9vdGhlcnMoKSB7CiAgIHN0 ZDo6Y291dCA8PCAiQSBtZW51IGl0ZW0gd2FzIHNlbGVjdGVkLiIgPDwgc3RkOjplbmRsOwp9Cgp2 b2lkIEV4YW1wbGVXaW5kb3c6Om9uX21lbnVfY2hvaWNlcyhjb25zdCBHbGliOjp1c3RyaW5nJiBw YXJhbWV0ZXIpIHsKICAgLy9UaGUgcmFkaW8gYWN0aW9uJ3Mgc3RhdGUgZG9lcyBub3QgY2hhbmdl IGF1dG9tYXRpY2FsbHk6CiAgIG1fcmVmQ2hvaWNlLT5jaGFuZ2Vfc3RhdGUocGFyYW1ldGVyKTsK CiAgIEdsaWI6OnVzdHJpbmcgbWVzc2FnZTsKICAgaWYgKHBhcmFtZXRlciA9PSAiYSIpCiAgICAg IG1lc3NhZ2UgPSAiQ2hvaWNlIGEgd2FzIHNlbGVjdGVkLiI7CiAgIGVsc2UKICAgICAgbWVzc2Fn ZSA9ICJDaG9pY2UgYiB3YXMgc2VsZWN0ZWQiOwoKICAgc3RkOjpjb3V0IDw8IG1lc3NhZ2UgPDwg c3RkOjplbmRsOwp9Cgp2b2lkIEV4YW1wbGVXaW5kb3c6Om9uX21lbnVfY2hvaWNlc19vdGhlcihp bnQgcGFyYW1ldGVyKSB7CiAgIC8vVGhlIHJhZGlvIGFjdGlvbidzIHN0YXRlIGRvZXMgbm90IGNo YW5nZSBhdXRvbWF0aWNhbGx5OgogICBtX3JlZkNob2ljZU90aGVyLT5jaGFuZ2Vfc3RhdGUocGFy YW1ldGVyKTsKCiAgIEdsaWI6OnVzdHJpbmcgbWVzc2FnZTsKICAgaWYgKHBhcmFtZXRlciA9PSAx KQogICAgICBtZXNzYWdlID0gIkNob2ljZSAxIHdhcyBzZWxlY3RlZC4iOwogICBlbHNlCiAgICAg IG1lc3NhZ2UgPSAiQ2hvaWNlIDIgd2FzIHNlbGVjdGVkIjsKCiAgIHN0ZDo6Y291dCA8PCBtZXNz YWdlIDw8IHN0ZDo6ZW5kbDsKfQoKdm9pZCBFeGFtcGxlV2luZG93Ojpvbl9tZW51X3RvZ2dsZSgp IHsKICAgYm9vbCBhY3RpdmUgPSBmYWxzZTsKICAgbV9yZWZUb2dnbGUtPmdldF9zdGF0ZShhY3Rp dmUpOwoKICAgLy9UaGUgdG9nZ2xlIGFjdGlvbidzIHN0YXRlIGRvZXMgbm90IGNoYW5nZSBhdXRv bWF0aWNhbGx5OgogICBtX3JlZlRvZ2dsZS0+Y2hhbmdlX3N0YXRlKCFhY3RpdmUpOwogICBhY3Rp dmUgPSAhYWN0aXZlOwoKICAgR2xpYjo6dXN0cmluZyBtZXNzYWdlOwogICBpZiAoYWN0aXZlKQog ICAgICBtZXNzYWdlID0gIlRvZ2dsZSBpcyBhY3RpdmUuIjsKICAgZWxzZQogICAgICBtZXNzYWdl ID0gIlRvZ2dsZSBpcyBub3QgYWN0aXZlIjsKCiAgIHN0ZDo6Y291dCA8PCBtZXNzYWdlIDw8IHN0 ZDo6ZW5kbDsKfQoK --=-wrFBfPyEU4HOKuWbZVUE Content-Disposition: attachment; filename="examplewindow.h" Content-Transfer-Encoding: base64 Content-Type: text/x-chdr; name="examplewindow.h"; charset="UTF-8" LyoKICogRW5oYW5jaW5nIHRoZSBtYWluIG1lbnUgZXhhbXBsZSBvZiBndGttbS10dXRvcmlhbC91 bnN0YWJsZSBwcmVzZW50ZWQgaW4KICogaHR0cHM6Ly9kZXZlbG9wZXIuZ25vbWUub3JnL2d0a21t LXR1dG9yaWFsL3Vuc3RhYmxlL1wKICogICAgICAgc2VjLW1lbnVzLWV4YW1wbGVzLmh0bWwuZGUj bWVudS1leGFtcGxlLW1haW4KICogdG8gc2hvdyBhbiBhcHBsaWNhdGlvbiBtZW51IGFzIHN1Z2dl c3RlZCBpbgogKiBodHRwczovL3dpa2kuZ25vbWUub3JnL1RocmVlUG9pbnRUaHJlZS9GZWF0dXJl cy9BcHBsaWNhdGlvbk1lbnUsCiAqIGRlc2NyaWJlZCBpbgogKiBodHRwczovL3dpa2kuZ25vbWUu b3JnL0hvd0RvSS9BcHBsaWNhdGlvbk1lbnUKICogYW5kIHJlYWxpc2VkIHVzaW5nIGd0a21tIGlu CiAqIGh0dHBzOi8vZ2l0Lmdub21lLm9yZy9icm93c2UvZ3RrbW0tZG9jdW1lbnRhdGlvbi90cmVl L2V4YW1wbGVzL2Jvb2svXAogKiAgICAgICBhcHBsaWNhdGlvbi9hcHBfYW5kX3dpbl9tZW51cwog KgogKiBTdGFydGVkIG9uIDIwMTQtMTEtMTAKICogQ3VycmVudCB2ZXJzaW9uOiAyMDE0LTExLTEw CiAqIFBlcmZvcm1lZCBieTogSsO8cmdlbiBLbGViZXIgKGprbGViZXIyNzAxQHQtb25saW5lLmRl KQogKgogKiBPcmlnaW5hbCBmaWxlIGRvd25sb2FkZWQgb24gU3VuZGF5LCA5dGggb2YgTm92ZW1i ZXIsIDIwMTQgZnJvbQogKiBodHRwczovL2dpdC5nbm9tZS5vcmcvYnJvd3NlL2d0a21tLWRvY3Vt ZW50YXRpb24vdHJlZS9leGFtcGxlcy9ib29rL21lbnVzL1wKICogICAgICAgbWFpbl9tZW51L2V4 YW1wbGV3aW5kb3cuaAogKi8KCiNpZm5kZWYgR1RLTU1fRVhBTVBMRVdJTkRPV19ICiNkZWZpbmUg R1RLTU1fRVhBTVBMRVdJTkRPV19ICgojaW5jbHVkZSA8Z3RrbW0uaD4KCmNsYXNzIEV4YW1wbGVX aW5kb3c6IHB1YmxpYyBHdGs6OkFwcGxpY2F0aW9uV2luZG93IHsKcHVibGljOgogICBFeGFtcGxl V2luZG93KCk7CiAgIHZpcnR1YWwgfkV4YW1wbGVXaW5kb3coKTsKCnByb3RlY3RlZDoKICAgLy9T aWduYWwgaGFuZGxlcnM6CiAgIHZvaWQgb25fbWVudV9vdGhlcnMoKTsKCiAgIHZvaWQgb25fbWVu dV9jaG9pY2VzKGNvbnN0IEdsaWI6OnVzdHJpbmcmIHBhcmFtZXRlcik7CiAgIHZvaWQgb25fbWVu dV9jaG9pY2VzX290aGVyKGludCBwYXJhbWV0ZXIpOwogICB2b2lkIG9uX21lbnVfdG9nZ2xlKCk7 CgogICAvL0NoaWxkIHdpZGdldHM6CiAgIEd0azo6Qm94IG1fQm94OwoKICAgLy9Ud28gc2V0cyBv ZiBjaG9pY2VzOgogICBHbGliOjpSZWZQdHI8R2lvOjpTaW1wbGVBY3Rpb24+IG1fcmVmQ2hvaWNl LCBtX3JlZkNob2ljZU90aGVyOwoKICAgR2xpYjo6UmVmUHRyPEdpbzo6U2ltcGxlQWN0aW9uPiBt X3JlZlRvZ2dsZTsKfTsKCiNlbmRpZiAvL0dUS01NX0VYQU1QTEVXSU5ET1dfSAoK --=-wrFBfPyEU4HOKuWbZVUE Content-Disposition: attachment; filename="main.cc" Content-Transfer-Encoding: base64 Content-Type: text/x-c++src; name="main.cc"; charset="UTF-8" LyoKICogRW5oYW5jaW5nIHRoZSBtYWluIG1lbnUgZXhhbXBsZSBvZiBndGttbS10dXRvcmlhbC91 bnN0YWJsZSBwcmVzZW50ZWQgaW4KICogaHR0cHM6Ly9kZXZlbG9wZXIuZ25vbWUub3JnL2d0a21t LXR1dG9yaWFsL3Vuc3RhYmxlL1wKICogICAgICAgc2VjLW1lbnVzLWV4YW1wbGVzLmh0bWwuZGUj bWVudS1leGFtcGxlLW1haW4KICogdG8gc2hvdyBhbiBhcHBsaWNhdGlvbiBtZW51IGFzIHN1Z2dl c3RlZCBpbgogKiBodHRwczovL3dpa2kuZ25vbWUub3JnL1RocmVlUG9pbnRUaHJlZS9GZWF0dXJl cy9BcHBsaWNhdGlvbk1lbnUsCiAqIGRlc2NyaWJlZCBpbgogKiBodHRwczovL3dpa2kuZ25vbWUu b3JnL0hvd0RvSS9BcHBsaWNhdGlvbk1lbnUKICogYW5kIHJlYWxpc2VkIHVzaW5nIGd0a21tIGlu CiAqIGh0dHBzOi8vZ2l0Lmdub21lLm9yZy9icm93c2UvZ3RrbW0tZG9jdW1lbnRhdGlvbi90cmVl L2V4YW1wbGVzL2Jvb2svXAogKiAgICAgICBhcHBsaWNhdGlvbi9hcHBfYW5kX3dpbl9tZW51cwog KgogKiBTdGFydGVkIG9uIDIwMTQtMTEtMTAKICogQ3VycmVudCB2ZXJzaW9uOiAyMDE0LTExLTEw CiAqIFBlcmZvcm1lZCBieTogSsO8cmdlbiBLbGViZXIgKGprbGViZXIyNzAxQHQtb25saW5lLmRl KQogKgogKiBPcmlnaW5hbCBmaWxlIGRvd25sb2FkZWQgb24gU3VuZGF5LCA5dGggb2YgTm92ZW1i ZXIsIDIwMTQgZnJvbQogKiBodHRwczovL2dpdC5nbm9tZS5vcmcvYnJvd3NlL2d0a21tLWRvY3Vt ZW50YXRpb24vdHJlZS9leGFtcGxlcy9ib29rL1wKICogICAgICAgYXBwbGljYXRpb24vYXBwX2Fu ZF93aW5fbWVudXMvbWFpbi5jYwogKi8KCiNpbmNsdWRlIDxpb3N0cmVhbT4KCiNpbmNsdWRlICJl eGFtcGxlYXBwbGljYXRpb24uaCIKCmludCBtYWluKGludCBhcmdjLCBjaGFyICphcmd2W10pIHsK ICAgR2xpYjo6UmVmUHRyPEV4YW1wbGVBcHBsaWNhdGlvbj4gYXBwbGljYXRpb24gPSBFeGFtcGxl QXBwbGljYXRpb246OmNyZWF0ZSgpOwoKICAgLy8gU3RhcnQgdGhlIGFwcGxpY2F0aW9uLCBzaG93 aW5nIHRoZSBpbml0aWFsIHdpbmRvdywKICAgLy8gYW5kIG9wZW5pbmcgZXh0cmEgd2luZG93cyBm b3IgYW55IGZpbGVzIHRoYXQgaXQgaXMgYXNrZWQgdG8gb3BlbiwKICAgLy8gZm9yIGluc3RhbmNl IGFzIGEgY29tbWFuZC1saW5lIHBhcmFtZXRlci4KICAgLy8gcnVuKCkgd2lsbCByZXR1cm4gd2hl biB0aGUgbGFzdCB3aW5kb3cgaGFzIGJlZW4gY2xvc2VkIGJ5IHRoZSB1c2VyLgogICBjb25zdCBp bnQgc3RhdHVzID0gYXBwbGljYXRpb24tPnJ1bihhcmdjLCBhcmd2KTsKICAgcmV0dXJuIHN0YXR1 czsKfQo= --=-wrFBfPyEU4HOKuWbZVUE-- From marcin.kolny@gmail.com Fri Nov 21 09:18:37 2014 Return-Path: X-Original-To: gtkmm-list@gnome.org Delivered-To: gtkmm-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 6057576A13 for ; Fri, 21 Nov 2014 09:18:37 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWi2R43McS_u for ; Fri, 21 Nov 2014 09:18:36 +0000 (UTC) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by restaurant.gnome.org (Postfix) with ESMTP id 21D20769B7 for ; Fri, 21 Nov 2014 09:18:25 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id rd18so4533370iec.29 for ; Fri, 21 Nov 2014 01:18:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=IMqs2RCQNwo/CioPAJa+IVsB3rxeISe4c/JIA50Wphw=; b=m7pBS5ybZSZA3Pzr795q/KbWYZe/mhKNznEutWZh2XPegnCQRUbWxgg6QQxUMCN/g5 AOiIJVZMF5KsTrqCikvt26XD+T78yivJ0KunDi3gFUI7dOqGow8dbL21wCzZaBN5xblm qlnWA2FdNB4e5mxHerAZMu7CucNYBlU7hL6/pYz9Idqg0fq+qOUknBAhIXLMRdNOeCN9 q1IOEGwxNpAaPybzVNt3auNRg13D3Ztag+c7yK4Q58lb3Ie+HmgmBBk1PPA72EpxAiXy 4jVJH3+8ZleHN/8oghjafXpG6Xa+pbK9o+T5ieZzmw+tDnJ/8EwthBfaVOsiMdNLZU6b 6Gpg== MIME-Version: 1.0 X-Received: by 10.107.39.5 with SMTP id n5mr1590528ion.72.1416561504072; Fri, 21 Nov 2014 01:18:24 -0800 (PST) Received: by 10.64.126.1 with HTTP; Fri, 21 Nov 2014 01:18:24 -0800 (PST) Date: Fri, 21 Nov 2014 10:18:24 +0100 Message-ID: Subject: Unmanaged mode in RefPtr From: Marcin Kolny To: gtkmm-list Content-Type: multipart/alternative; boundary=001a11406f1840bb5505085aeda9 X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 09:18:37 -0000 --001a11406f1840bb5505085aeda9 Content-Type: text/plain; charset=UTF-8 Hi, I've got following problem; I've got a class Query, which is base class for QueryAllocation. Passing \ QueryAllocation object as Query to a function is pretty simple because of automatic cas\ ting: void do_sth(const RefPtr& query); ... RefPtr alloc_query = QueryAllocation::create (); do_sth (alloc_query); But... in do_sth method, refcount of my object equals 2 (because casting \ increases ref count, it's obvious). Unfortunately, I have to have refcoun\ t=1 in do_sth method, so that's what I'm doing now: RefPtr alloc_query = QueryAllocation::create(); RefPtr query = alloc_query; query->unreference(); do_sth(query); query->reference(); query.reset(); It's workaround.. that would be great, if I can do something like "unmana\ ged RefPtr". It might look like this: RefPtr alloc_query = QueryAllocation::create(); do_sth(RefPtr(alloc_query, false)); And constructor declaration: template RefPtr(const RefPtr& src, bool manage = true); If 'manage' equals false, RefPtr doesn't increase/decrease refcount durin\ g construction and destruction. I know, it's unsafe, and might lead to a \ problems, if somebody uses it wrong, but it allows me to remove a lot of \ magic from my code. Of course, it's only conceptual solution, maybe it would be better to do \ single function instead of constructor, ideas are welcome. Best regards, Marcin Kolny --001a11406f1840bb5505085aeda9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+SGksPGJyPkkmIzM5O3ZlIGdvdCBmb2xsb3dpbmcgcHJvYmxlbTvCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgwqA8YnI+SSYjMzk7dmUgZ290IGEgY2xhc3Mg UXVlcnksIHdoaWNoIGlzIGJhc2UgY2xhc3MgZm9yIFF1ZXJ5QWxsb2NhdGlvbi4gUGFzc2luZyBc PGJyPlF1ZXJ5QWxsb2NhdGlvbiBvYmplY3QgYXMgUXVlcnkgdG8gYSBmdW5jdGlvbiBpcyBwcmV0 dHkgc2ltcGxlIGJlY2F1c2Ugb2YgYXV0b21hdGljIGNhc1w8YnI+dGluZzo8YnI+PGJyPnZvaWQg ZG9fc3RoKGNvbnN0IFJlZlB0ciZsdDtRdWVyeSZndDsmYW1wOyBxdWVyeSk7wqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCDCoDxi cj4uLi48YnI+UmVmUHRyJmx0O1F1ZXJ5QWxsb2NhdGlvbiZndDsgYWxsb2NfcXVlcnkgPSBRdWVy eUFsbG9jYXRpb246OmNyZWF0ZSAoKTvCoMKgwqDCoMKgwqDCoCDCoDxicj5kb19zdGggKGFsbG9j X3F1ZXJ5KTvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgwqA8 YnI+PGJyPkJ1dC4uLiBpbiBkb19zdGggbWV0aG9kLCByZWZjb3VudCBvZiBteSBvYmplY3QgZXF1 YWxzIDIgKGJlY2F1c2UgY2FzdGluZyBcPGJyPmluY3JlYXNlcyByZWYgY291bnQsIGl0JiMzOTtz IG9idmlvdXMpLiBVbmZvcnR1bmF0ZWx5LCBJIGhhdmUgdG8gaGF2ZSByZWZjb3VuXDxicj50PTEg aW4gZG9fc3RoIG1ldGhvZCwgc28gdGhhdCYjMzk7cyB3aGF0IEkmIzM5O20gZG9pbmcgbm93Ojxi cj48YnI+UmVmUHRyJmx0O1F1ZXJ5QWxsb2NhdGlvbiZndDsgYWxsb2NfcXVlcnkgPSBRdWVyeUFs bG9jYXRpb246OmNyZWF0ZSgpO8KgwqDCoMKgwqDCoMKgwqAgwqA8YnI+UmVmUHRyJmx0O1F1ZXJ5 Jmd0OyBxdWVyeSA9IGFsbG9jX3F1ZXJ5O8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgwqA8YnI+cXVlcnkt Jmd0O3VucmVmZXJlbmNlKCk7wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIMKgPGJyPmRvX3N0aChxdWVyeSk7wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgwqA8YnI+cXVlcnktJmd0O3JlZmVyZW5jZSgp O8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgwqA8YnI+ cXVlcnkucmVzZXQoKTvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCDCoDxicj48YnI+SXQmIzM5O3Mgd29ya2Fyb3VuZC4uIHRoYXQgd291 bGQgYmUgZ3JlYXQsIGlmIEkgY2FuIGRvIHNvbWV0aGluZyBsaWtlICZxdW90O3VubWFuYVw8YnI+ Z2VkIFJlZlB0ciZxdW90Oy4gSXQgbWlnaHQgbG9vayBsaWtlIHRoaXM6PGJyPjxicj5SZWZQdHIm bHQ7UXVlcnlBbGxvY2F0aW9uJmd0OyBhbGxvY19xdWVyeSA9IFF1ZXJ5QWxsb2NhdGlvbjo6Y3Jl YXRlKCk7wqDCoMKgwqDCoMKgwqDCoCDCoDxicj5kb19zdGgoUmVmUHRyJmx0O1F1ZXJ5Jmd0Oyhh bGxvY19xdWVyeSwgZmFsc2UpKTvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgwqA8YnI+PGJyPkFuZCBjb25zdHJ1Y3RvciBkZWNsYXJh dGlvbjo8YnI+dGVtcGxhdGUmbHQ7dHlwZW5hbWUgVCZndDs8YnI+UmVmUHRyKGNvbnN0IFJlZlB0 ciZsdDtUJmd0OyZhbXA7IHNyYywgYm9vbCBtYW5hZ2UgPSB0cnVlKTvCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIMKgPGJyPjxicj5JZiAmIzM5O21hbmFnZSYj Mzk7IGVxdWFscyBmYWxzZSwgUmVmUHRyIGRvZXNuJiMzOTt0IGluY3JlYXNlL2RlY3JlYXNlIHJl ZmNvdW50IGR1cmluXDxicj5nIGNvbnN0cnVjdGlvbiBhbmQgZGVzdHJ1Y3Rpb24uIEkga25vdywg aXQmIzM5O3MgdW5zYWZlLCBhbmQgbWlnaHQgbGVhZCB0byBhIFw8YnI+cHJvYmxlbXMsIGlmIHNv bWVib2R5IHVzZXMgaXQgd3JvbmcsIGJ1dCBpdCBhbGxvd3MgbWUgdG8gcmVtb3ZlIGEgbG90IG9m IFw8YnI+bWFnaWMgZnJvbSBteSBjb2RlLjxicj48YnI+T2YgY291cnNlLCBpdCYjMzk7cyBvbmx5 IGNvbmNlcHR1YWwgc29sdXRpb24sIG1heWJlIGl0IHdvdWxkIGJlIGJldHRlciB0byBkbyBcPGJy PnNpbmdsZSBmdW5jdGlvbiBpbnN0ZWFkIG9mIGNvbnN0cnVjdG9yLCBpZGVhcyBhcmUgd2VsY29t ZS48YnI+PGJyPkJlc3QgcmVnYXJkcyw8YnI+TWFyY2luIEtvbG55PGJyPjxicj48L2Rpdj4NCg== --001a11406f1840bb5505085aeda9-- From kjell.ahlstedt@bredband.net Fri Nov 21 14:02:35 2014 Return-Path: X-Original-To: gtkmm-list@gnome.org Delivered-To: gtkmm-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 98EE576A55 for ; Fri, 21 Nov 2014 14:02:35 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-WvYZKfr8oE for ; Fri, 21 Nov 2014 14:02:33 +0000 (UTC) Received: from smtprelay-h21.telenor.se (smtprelay-h21.telenor.se [195.54.99.196]) by restaurant.gnome.org (Postfix) with ESMTP id DDEEE76976 for ; Fri, 21 Nov 2014 14:02:17 +0000 (UTC) Received: from ipb2.telenor.se (ipb2.telenor.se [195.54.127.165]) by smtprelay-h21.telenor.se (Postfix) with ESMTP id 4C159C8EC for ; Fri, 21 Nov 2014 15:02:15 +0100 (CET) X-SMTPAUTH-B2: [kjell.ahlstedt@bredband.net] X-SENDER-IP: [85.229.156.35] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8CAC9Fb1RV5ZwjPGdsb2JhbAANT4tFwhSGc4McAoEYAQEBAQEBBQEBAQE4hD4BAQQnUQEQCyEWDwkDAgECATEUBg0BBwEBF4grtwKXZwEBAQEBAQQBAQEBAQEBAQEZinCCWoM+B4RLBblYgzcBAQE X-IPAS-Result: An8CAC9Fb1RV5ZwjPGdsb2JhbAANT4tFwhSGc4McAoEYAQEBAQEBBQEBAQE4hD4BAQQnUQEQCyEWDwkDAgECATEUBg0BBwEBF4grtwKXZwEBAQEBAQQBAQEBAQEBAQEZinCCWoM+B4RLBblYgzcBAQE X-IronPort-AV: E=Sophos;i="5.07,431,1413237600"; d="scan'208,217";a="115773586" Received: from c-239ce555.06-203-73746f44.cust.bredbandsbolaget.se (HELO [192.168.1.64]) ([85.229.156.35]) by ipb2.telenor.se with ESMTP; 21 Nov 2014 15:02:14 +0100 Message-ID: <546F45E6.1080608@bredband.net> Date: Fri, 21 Nov 2014 15:02:14 +0100 From: Kjell Ahlstedt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Marcin Kolny Subject: Re: Unmanaged mode in RefPtr References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080003010408070308080408" Cc: gtkmm-list X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 14:02:35 -0000 This is a multi-part message in MIME format. --------------080003010408070308080408 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Have you tried: Glib::RefPtr query = QueryAllocation::create(); do_sth(query); Glib::RefPtr alloc_query = Glib::RefPtr::cast_dynamic(query); It's not very nice, but if it works, it's better than fiddling with unreference() and reference(). The obvious suggestion is to fix do_sth(). It's really odd to require refcount==1. Kjell Den 2014-11-21 10:18, Marcin Kolny skrev: > Hi, > I've got following problem; > I've got a class Query, which is base class for QueryAllocation. Passing \ > QueryAllocation object as Query to a function is pretty simple because > of automatic cas\ > ting: > > void do_sth(const RefPtr& query); > ... > RefPtr alloc_query = QueryAllocation::create (); > do_sth (alloc_query); > > But... in do_sth method, refcount of my object equals 2 (because casting \ > increases ref count, it's obvious). Unfortunately, I have to have refcoun\ > t=1 in do_sth method, so that's what I'm doing now: > > RefPtr alloc_query = QueryAllocation::create(); > RefPtr query = alloc_query; > query->unreference(); > do_sth(query); > query->reference(); > query.reset(); > > It's workaround.. that would be great, if I can do something like "unmana\ > ged RefPtr". It might look like this: > > RefPtr alloc_query = QueryAllocation::create(); > do_sth(RefPtr(alloc_query, false)); > > And constructor declaration: > template > RefPtr(const RefPtr& src, bool manage = true); > > If 'manage' equals false, RefPtr doesn't increase/decrease refcount durin\ > g construction and destruction. I know, it's unsafe, and might lead to a \ > problems, if somebody uses it wrong, but it allows me to remove a lot of \ > magic from my code. > > Of course, it's only conceptual solution, maybe it would be better to do \ > single function instead of constructor, ideas are welcome. > > Best regards, > Marcin Kolny --------------080003010408070308080408 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Have you tried:

Glib::RefPtr<Query> query = QueryAllocation::create();
do_sth(query);
Glib::RefPtr<QueryAllocation> alloc_query = Glib::RefPtr<QueryAllocation>::cast_dynamic(query);

It's not very nice, but if it works, it's better than fiddling with unreference() and reference().
The obvious suggestion is to fix do_sth(). It's really odd to require refcount==1.

Kjell

Den 2014-11-21 10:18, Marcin Kolny skrev:

Hi,
I've got following problem;
I've got a class Query, which is base class for QueryAllocation. Passing \
QueryAllocation object as Query to a function is pretty simple because of automatic cas\
ting:

void do_sth(const RefPtr<Query>& query);
...
RefPtr<QueryAllocation> alloc_query = QueryAllocation::create ();
do_sth (alloc_query);

But... in do_sth method, refcount of my object equals 2 (because casting \
increases ref count, it's obvious). Unfortunately, I have to have refcoun\
t=1 in do_sth method, so that's what I'm doing now:

RefPtr<QueryAllocation> alloc_query = QueryAllocation::create();
RefPtr<Query> query = alloc_query;
query->unreference();
do_sth(query);
query->reference();
query.reset();

It's workaround.. that would be great, if I can do something like "unmana\
ged RefPtr". It might look like this:

RefPtr<QueryAllocation> alloc_query = QueryAllocation::create();
do_sth(RefPtr<Query>(alloc_query, false));

And constructor declaration:
template<typename T>
RefPtr(const RefPtr<T>& src, bool manage = true);

If 'manage' equals false, RefPtr doesn't increase/decrease refcount durin\
g construction and destruction. I know, it's unsafe, and might lead to a \
problems, if somebody uses it wrong, but it allows me to remove a lot of \
magic from my code.

Of course, it's only conceptual solution, maybe it would be better to do \
single function instead of constructor, ideas are welcome.

Best regards,
Marcin Kolny

--------------080003010408070308080408-- From marcin.kolny@gmail.com Sat Nov 22 00:21:14 2014 Return-Path: X-Original-To: gtkmm-list@gnome.org Delivered-To: gtkmm-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 958AA76A22 for ; Sat, 22 Nov 2014 00:21:14 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ztT14By2QK9 for ; Sat, 22 Nov 2014 00:21:12 +0000 (UTC) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) by restaurant.gnome.org (Postfix) with ESMTP id 4940D76944 for ; Sat, 22 Nov 2014 00:21:01 +0000 (UTC) Received: by mail-ig0-f179.google.com with SMTP id r2so518035igi.12 for ; Fri, 21 Nov 2014 16:21:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ksSGQsVwNDQt7iBRV5k39IzKvsbBTr2dKMCXExvgvkc=; b=Gtmp9fF7sQWzK0jVwQ3nERfjKP4q+xsEQYVd1yqvwmK55AO0YaBKpn9ZAvEGIPIAXQ 02EgizFxTeLSKoO2CZVjH2RoRPcfdW5IjBu8Fc9lMukLySFi1vzPckGpPdaRf5cRVP0L kfKQDaYs78siLNVYf37fo1uLe0hiPSMJcY738mNE465Yq4jtnrgAB4h706eXYBNHH5IG dPOKhhTYE7Io91nQv2bZYE470mHKDvdze0Fy25PRz4s4A72VxuRC7pupVYjoajyt1foa 8UgUWj4ycHCmVE3xfzWVsGidlPLgEZE6w6HeXDvjwK27vd5EOxxk/20xOgOAb1u5l492 Qh9A== MIME-Version: 1.0 X-Received: by 10.42.179.132 with SMTP id bq4mr8392260icb.61.1416615660378; Fri, 21 Nov 2014 16:21:00 -0800 (PST) Received: by 10.64.126.1 with HTTP; Fri, 21 Nov 2014 16:21:00 -0800 (PST) In-Reply-To: <546F45E6.1080608@bredband.net> References: <546F45E6.1080608@bredband.net> Date: Sat, 22 Nov 2014 01:21:00 +0100 Message-ID: Subject: Re: Unmanaged mode in RefPtr From: Marcin Kolny To: Kjell Ahlstedt Content-Type: multipart/alternative; boundary=90e6ba6e80fe385fe60508678943 Cc: gtkmm-list X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 00:21:14 -0000 --90e6ba6e80fe385fe60508678943 Content-Type: text/plain; charset=UTF-8 2014-11-21 15:02 GMT+01:00 Kjell Ahlstedt : > Have you tried: > > Glib::RefPtr query = QueryAllocation::create(); > do_sth(query); > Glib::RefPtr alloc_query = > Glib::RefPtr::cast_dynamic(query); > > It's not very nice, but if it works, it's better than fiddling with > unreference() and reference(). > It doesn't really solve my problem, but it's still some kind of workaround (probably better than my trick with inc/dec refcounts, but still - workaround). When I'd like to call QueryAllocation's methods, I have to do castings: Glib::RefPtr::cast_static(query)->call1(); Glib::RefPtr::cast_static(query)->call2(); It's inconvenient. > The obvious suggestion is to fix do_sth(). It's really odd to require > refcount==1. > It's not odd in gstreamer. A lot of methods requires refcount equals 1, because if refcount is greater, a copy of object is created (or even assertion fails, in some cases). That's why I don't want to increase refcount, if it's in fact not necessary. Of course, I can implement my method as template function: template void do_sth(const Glib::RefPtr& arg); and it's even type-safe, but I've got bad feelings about it. It's tricky, type of argument isn't obvious, and a lot of code has to be moved to a header files (or instantiate template by every possible query type in source file, but it's inconvenient). Best regards, Marcin Kolny > Kjell > > Den 2014-11-21 10:18, Marcin Kolny skrev: > > Hi, > I've got following problem; > I've got a class Query, which is base class for QueryAllocation. Passing \ > QueryAllocation object as Query to a function is pretty simple because of > automatic cas\ > ting: > > void do_sth(const RefPtr& query); > ... > RefPtr alloc_query = QueryAllocation::create (); > do_sth (alloc_query); > > But... in do_sth method, refcount of my object equals 2 (because casting \ > increases ref count, it's obvious). Unfortunately, I have to have refcoun\ > t=1 in do_sth method, so that's what I'm doing now: > > RefPtr alloc_query = QueryAllocation::create(); > RefPtr query = alloc_query; > query->unreference(); > do_sth(query); > query->reference(); > query.reset(); > > It's workaround.. that would be great, if I can do something like "unmana\ > ged RefPtr". It might look like this: > > RefPtr alloc_query = QueryAllocation::create(); > do_sth(RefPtr(alloc_query, false)); > > And constructor declaration: > template > RefPtr(const RefPtr& src, bool manage = true); > > If 'manage' equals false, RefPtr doesn't increase/decrease refcount durin\ > g construction and destruction. I know, it's unsafe, and might lead to a \ > problems, if somebody uses it wrong, but it allows me to remove a lot of \ > magic from my code. > > Of course, it's only conceptual solution, maybe it would be better to do \ > single function instead of constructor, ideas are welcome. > > Best regards, > Marcin Kolny > > > --90e6ba6e80fe385fe60508678943 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

2014= -11-21 15:02 GMT+01:00 Kjell Ahlstedt <kjell.ahlstedt@bredband.n= et>:

=20 =20 =20
Have you tried:

Glib::RefPtr<Query> query =3D QueryAllocation::create();
do_sth(query);
Glib::RefPtr<QueryAllocation> alloc_query =3D Glib::RefPtr<QueryAllocation>::cast_dynamic(query);

It's not very nice, but if it works, it's bet= ter than fiddling with unreference() and reference().
It doesn't really solve my problem, but it's still s= ome kind of workaround (probably better than my trick with inc/dec refcount= s, but still - workaround). When I'd like to call QueryAllocation's= methods, I have to do castings:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Glib::= RefPtr<QueryAllocation>::cast_static(query)->call1();
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Glib::RefPtr<QueryAllocati= on>::cast_static(query)->call2();
It's inconvenient= .
The obvious suggestion is to fix do_sth(). It's really odd to require refcount=3D=3D1.
It's = not odd in gstreamer. A lot of methods requires refcount equals 1, because = if refcount is greater, a copy of object is created (or even assertion fail= s, in some cases). That's why I don't want to increase refcount, if= it's in fact not necessary. Of course, I can implement my method as te= mplate function:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 template<typename T> void do_sth(const Glib::RefPtr&l= t;T>& arg);

and it's even type-safe, but I'= ;ve got bad feelings about it. It's tricky, type of argument isn't = obvious, and a lot of code has to be moved to a header files (or instantiat= e template by every possible query type in source file, but it's inconv= enient).

Best regards,
Marcin Koln= y

Kjell

Den 2014-11-21 10:18, Marcin Kolny skrev:

Hi,
I've got following problem;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0
I've got a class Query, which is base class for QueryAllocation= . Passing \
QueryAllocation object as Query to a function is pretty simple because of automatic cas\
ting:

void do_sth(const RefPtr<Query>& query);=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0
...
RefPtr<QueryAllocation> alloc_query =3D QueryAllocation::create ();=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 =C2=A0
do_sth (alloc_query);=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0

But... in do_sth method, refcount of my object equals 2 (because casting \
increases ref count, it's obvious). Unfortunately, I have to have refcoun\
t=3D1 in do_sth method, so that's what I'm doing now:

RefPtr<QueryAllocation> alloc_query =3D QueryAllocation::create();=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 =C2=A0
RefPtr<Query> query =3D alloc_query;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0
query->unreference();=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0
do_sth(query);=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0
query->reference();=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0
query.reset();=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0

It's workaround.. that would be great, if I can do something like "unmana\
ged RefPtr". It might look like this:

RefPtr<QueryAllocation> alloc_query =3D QueryAllocation::create();=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 =C2=A0
do_sth(RefPtr<Query>(alloc_query, false));=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0

And constructor declaration:
template<typename T>
RefPtr(const RefPtr<T>& src, bool manage =3D true);=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 =C2=A0

If 'manage' equals false, RefPtr doesn't increase/decre= ase refcount durin\
g construction and destruction. I know, it's unsafe, and might lead to a \
problems, if somebody uses it wrong, but it allows me to remove a lot of \
magic from my code.

Of course, it's only conceptual solution, maybe it would be better to do \
single function instead of constructor, ideas are welcome.

Best regards,
Marcin Kolny

--90e6ba6e80fe385fe60508678943-- From kjell.ahlstedt@bredband.net Tue Nov 25 07:50:21 2014 Return-Path: X-Original-To: gtkmm-list@gnome.org Delivered-To: gtkmm-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 46FD4768CF for ; Tue, 25 Nov 2014 07:50:21 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDmpz_Qj1NVB for ; Tue, 25 Nov 2014 07:50:19 +0000 (UTC) Received: from smtprelay-h21.telenor.se (smtprelay-h21.telenor.se [195.54.99.196]) by restaurant.gnome.org (Postfix) with ESMTP id 1D91C762EB for ; Tue, 25 Nov 2014 07:50:08 +0000 (UTC) Received: from ipb5.telenor.se (ipb5.telenor.se [195.54.127.168]) by smtprelay-h21.telenor.se (Postfix) with ESMTP id E22FAE027 for ; Tue, 25 Nov 2014 08:50:06 +0100 (CET) X-SMTPAUTH-B2: [kjell.ahlstedt@bredband.net] X-SENDER-IP: [85.229.156.35] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwDAEgzdFRV5ZwjOmdsb2JhbAANToNYVwGDBMNIGoJLhk4CgSkBAQEBAQEFAQEBASIWhD4BAQQjVQEQCwQdFgsCAgkDAgECATEUBg0BBwEBiEEIuHl4lmkBAQEBAQEBAQIBAQEBAQEBAQEZkHoHgniBVQWXSIhmP5EbiAd3gkkBAQE X-IPAS-Result: AlwDAEgzdFRV5ZwjOmdsb2JhbAANToNYVwGDBMNIGoJLhk4CgSkBAQEBAQEFAQEBASIWhD4BAQQjVQEQCwQdFgsCAgkDAgECATEUBg0BBwEBiEEIuHl4lmkBAQEBAQEBAQIBAQEBAQEBAQEZkHoHgniBVQWXSIhmP5EbiAd3gkkBAQE X-IronPort-AV: E=Sophos;i="5.07,454,1413237600"; d="scan'208,217";a="822425125" Received: from c-239ce555.06-203-73746f44.cust.bredbandsbolaget.se (HELO [192.168.1.64]) ([85.229.156.35]) by ipb5.telenor.se with ESMTP; 25 Nov 2014 08:50:06 +0100 Message-ID: <547434AD.8060709@bredband.net> Date: Tue, 25 Nov 2014 08:50:05 +0100 From: Kjell Ahlstedt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: =?UTF-8?B?SsO8cmdlbiBLbGViZXI=?= Subject: Re: Upgrade menu-example-main to Gtk::Application/Gtk::ApplicationWindow? References: <1415900906.10101.2.camel@localhost.localdomain> <546CB8BE.6020202@bredband.net> <1416423328.4534.1.camel@t-online.de> In-Reply-To: <1416423328.4534.1.camel@t-online.de> Content-Type: multipart/alternative; boundary="------------080101050002070803070300" Cc: gtkmm-list@gnome.org X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 07:50:21 -0000 This is a multi-part message in MIME format. --------------080101050002070803070300 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I have pushed modified versions of your files to the git repository, and added some text to the /Menus and To//olbars/ chapter in the gtkmm tutorial. That chapter is still not up to date. It needs a total rewrite. Kjell Den 2014-11-19 19:55, JÃ¼rgen Kleber skrev: > I'm following your second proposal and attached the source files, hoping > you can make a patch out of them. You can also see the files in > http://jkleber.homepage.t-online.de/c > ++/menu_appwin_builder_app/index.html . > > JÃ¼rgen > > Am Mittwoch, den 19.11.2014, 16:35 +0100 schrieb Kjell Ahlstedt: >> If you file a bug in Bugzilla and attach a patch, I can push it to the >> git repository. >> If you haven't installed git, and don't want to do it, you can attach >> the new and the modified files. I can make a patch out of them. >> Third alternative: File a bug without attachments, and hope for the >> best. Someone will probably fix it some day, but it will be fixed >> quicker if you do most of the job yourself. >> >> Kjell >> >> Den 2014-11-13 18:48, JÃ¼rgen Kleber skrev: >> >>> Hi, >>> >>> quite a lot of Gnome applications have an application menu allowing for >>> menu items covering the application as a whole to place into the top bar >>> of Gnome-shell. I should appreciate this feature being reflected in the >>> menu-example of the gtkmm-tutorial. This could easily be done by >>> deriving ExampleWindow from Gtk::ApplicationWindow instead from >>> Gtk::Window and adding a new class ExampleApplication derived from >>> Gtk::Application using this example >>> https://git.gnome.org/browse/gtkmm-documentation/tree/examples/book/application/app_and_win_menus >>> as a guideline. >>> >>> Best regards, >>> JÃ¼rgen >>> >>> --------------080101050002070803070300 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I have pushed modified versions of your files to the git repository, and added some text to the Menus and Toolbars chapter in the gtkmm tutorial. That chapter is still not up to date. It needs a total rewrite.

Kjell

Den 2014-11-19 19:55, JÃ¼rgen Kleber skrev:

I'm following your second proposal and attached the source files, hoping
you can make a patch out of them. You can also see the files in
http://jkleber.homepage.t-online.de/c
++/menu_appwin_builder_app/index.html .

JÃ¼rgen

Am Mittwoch, den 19.11.2014, 16:35 +0100 schrieb Kjell Ahlstedt:

If you file a bug in Bugzilla and attach a patch, I can push it to the
git repository.
If you haven't installed git, and don't want to do it, you can attach
the new and the modified files. I can make a patch out of them.
Third alternative: File a bug without attachments, and hope for the
best. Someone will probably fix it some day, but it will be fixed
quicker if you do most of the job yourself.

Kjell

Den 2014-11-13 18:48, JÃ¼rgen Kleber skrev:

Hi,

quite a lot of Gnome applications have an application menu allowing for
menu items covering the application as a whole to place into the top bar
of Gnome-shell. I should appreciate this feature being reflected in the
menu-example of the gtkmm-tutorial. This could easily be done by
deriving ExampleWindow from Gtk::ApplicationWindow instead from
Gtk::Window and adding a new class ExampleApplication derived from
Gtk::Application using this example
https://git.gnome.org/browse/gtkmm-documentation/tree/examples/book/application/app_and_win_menus
as a guideline.

Best regards,
JÃ¼rgen

--------------080101050002070803070300-- From adiabat@centurylink.net Wed Nov 26 04:32:44 2014 Return-Path: X-Original-To: gtkmm-list@gnome.org Delivered-To: gtkmm-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id CC1AB76962 for ; Wed, 26 Nov 2014 04:32:44 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9dVxu7jd9n9 for ; Wed, 26 Nov 2014 04:32:43 +0000 (UTC) Received: from smtp.centurylink.net (mail.centurylink.net [205.219.233.9]) by restaurant.gnome.org (Postfix) with ESMTP id 1655B762D0 for ; Wed, 26 Nov 2014 04:32:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; d=centurylink.net; s=ctl201402; c=relaxed/simple; q=dns/txt; i=@centurylink.net; t=1416976350; h=From:Subject:Date:To:MIME-Version:Content-Type; bh=hbKFYkUBus6tud74XNVNXcWLcjQ=; b=zcDELF4bVExO5sgT+Q4p1a8nRRk6adImvu1gCLsM1f0eNplnoJRMKLR0bVNjL/Jj 0S+Xr1zqgCNLK6ppCAB9sMq4yqILEDcSVqilaSYv9lgCdNT6TckhKtT40aKDeK5t PRf0AQn/9IdtKhbsZldt57XNJfkeVTcS4KfJNPNw/xYmxrfaCs4UWOUN5+Y9VmGW W2gMQ0YlnzM7yv41cOOKXMWS5c9RyyQZ0Waiz5bJ5c2yhAEB3uGqE13bTThF0ABD 8uIw+1eXsVvRm43x9ULZFRa+DFr8N4HUxX2QJJzmEbQZkSocubI9OZZ7fSK+Rkqd 82/MpeJ62peJXggRzS46zA==; X_CMAE_Category: , , X-CNFS-Analysis: v=2.0 cv=YNQdOG6x c=1 sm=1 a=H03XQNzO3ZIBWxh40sAgAw==:17 a=5ZTteq0x3j8A:10 a=IkcTkHD0fZMA:10 a=I_5RNyk1AAAA:8 a=aiIX5UjjAAAA:8 a=uJLZOLH3KYxBR_rK7Y4A:9 a=QEXdDO2ut3YA:10 a=Nj4Hl1Ei7yMA:10 a=99EM7YJ8h3IA:10 a=H03XQNzO3ZIBWxh40sAgAw==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: YWRpYWJhdEBjZW50dXJ5bGluay5uZXQ= Authentication-Results: smtp02.agate.dfw.synacor.com smtp.user=adiabat@centurylink.net; auth=pass (LOGIN) Received: from [75.165.62.138] ([75.165.62.138:12138] helo=[192.168.0.101]) by smtp.centurylink.net (envelope-from ) (ecelerity 3.5.1.37854 r(Momo-dev:3.5.1.0)) with ESMTPSA (cipher=AES128-SHA) id 91/B2-23789-ED755745; Tue, 25 Nov 2014 23:32:30 -0500 Message-ID: <547557DD.3070000@centurylink.net> Date: Tue, 25 Nov 2014 20:32:29 -0800 From: Phil Wolff User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: gtkmm-list@gnome.org Subject: App menu name Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 04:32:44 -0000 I'm looking at the example code at https://git.gnome.org/browse/gtkmm-documentation/tree/examples/book/application/app_and_win_menus. At runtime the app menu is titled "Unknown Application Name," but the win menus are properly titled as "File," "Edit," and "Notification." Does this imply that something is missing from the code? From kjell.ahlstedt@bredband.net Wed Nov 26 10:04:14 2014 Return-Path: X-Original-To: gtkmm-list@gnome.org Delivered-To: gtkmm-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 8838276962 for ; Wed, 26 Nov 2014 10:04:14 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHtSZYVE4Y59 for ; Wed, 26 Nov 2014 10:04:13 +0000 (UTC) Received: from smtprelay-h31.telenor.se (smtprelay-h31.telenor.se [213.150.131.4]) by restaurant.gnome.org (Postfix) with ESMTP id AEDD5762C3 for ; Wed, 26 Nov 2014 10:04:02 +0000 (UTC) Received: from ipb2.telenor.se (ipb2.telenor.se [195.54.127.165]) by smtprelay-h31.telenor.se (Postfix) with ESMTP id 641F9DB9A for ; Wed, 26 Nov 2014 11:03:40 +0100 (CET) X-SMTPAUTH-B2: [kjell.ahlstedt@bredband.net] X-SENDER-IP: [85.229.156.35] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoBAHekdVRV5ZwjPGdsb2JhbAANToNYyHeGSwKBIQEBAQEBAQUBAQEBOIQ+AQEEOEABEAsOExYPCQMCAQIBMRQGDQEHAQEaiCcIuiyXGAEBAQEBAQEBAQEBAQEBAQEBAQEBFASQeweETQEEl0iiTYNAAQEB X-IPAS-Result: AsoBAHekdVRV5ZwjPGdsb2JhbAANToNYyHeGSwKBIQEBAQEBAQUBAQEBOIQ+AQEEOEABEAsOExYPCQMCAQIBMRQGDQEHAQEaiCcIuiyXGAEBAQEBAQEBAQEBAQEBAQEBAQEBFASQeweETQEEl0iiTYNAAQEB X-IronPort-AV: E=Sophos;i="5.07,461,1413237600"; d="scan'208";a="118726509" Received: from c-239ce555.06-203-73746f44.cust.bredbandsbolaget.se (HELO [192.168.1.64]) ([85.229.156.35]) by ipb2.telenor.se with ESMTP; 26 Nov 2014 11:03:06 +0100 Message-ID: <5475A559.2060302@bredband.net> Date: Wed, 26 Nov 2014 11:03:05 +0100 From: Kjell Ahlstedt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Phil Wolff Subject: Re: App menu name References: <547557DD.3070000@centurylink.net> In-Reply-To: <547557DD.3070000@centurylink.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: gtkmm-list@gnome.org X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 10:04:14 -0000 Den 2014-11-26 05:32, Phil Wolff skrev: > I'm looking at the example code at > https://git.gnome.org/browse/gtkmm-documentation/tree/examples/book/application/app_and_win_menus. > > > At runtime the app menu is titled "Unknown Application Name," but the > win menus are properly titled as "File," "Edit," and "Notification." > > Does this imply that something is missing from the code? > ______________________________________________ I have recently pushed some changes that make the menus/main_menu example use an application menu. Then I noticed the same thing. I use Ubuntu, which has two desktop environments to choose from: Ubuntu Unity and Gnome Flashback. Ubuntu Unity shows both the app menu and the menubar outside the application's window, and the app menu is titled "Unknown Application Name". Gnome Flashback shows both the app menu and the menubar in the application's window, and the app menu is titled "Gtk::Application Example" (or whatever name is set with Glib::set_application_name()). Gtk+'s demo program behaves the same. I don't know if something is missing in these programs, or if it's a bug in the Ubuntu Unity desktop shell. Which operating system do you use? Kjell From adiabat@centurylink.net Wed Nov 26 12:48:58 2014 Return-Path: X-Original-To: gtkmm-list@gnome.org Delivered-To: gtkmm-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 9751176A05 for ; Wed, 26 Nov 2014 12:48:58 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMicKl0uwliK for ; Wed, 26 Nov 2014 12:48:57 +0000 (UTC) Received: from smtp.centurylink.net (mail.centurylink.net [205.219.233.9]) by restaurant.gnome.org (Postfix) with ESMTP id 18631762C3 for ; Wed, 26 Nov 2014 12:48:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; d=centurylink.net; s=ctl201402; c=relaxed/simple; q=dns/txt; i=@centurylink.net; t=1417006119; h=From:Subject:Date:To:MIME-Version:Content-Type; bh=hI7BWRyK3vrXnucNtX2AIVq9MvE=; b=Z7CkJ0qMbUCR7dgGxlg+P/krjb7h0RFM0C8J2CaQ0bq356PItp+ZsZ/KoCBfmkXp 9lnh64uJUvGMH9BAwvHDi6jCmbWeRS/1hsu/nq0r+J5GbKvVzhLcF1K2u2c8LGeR X5fkcBVercnUSuXqTO0jkO/T4tndkjux4EKu8W/uNWKj1uBx69GFLEywl2HsdlaO X3yD4aeYm4lPrKe76YQNzjAzRBWsLXR0vBKc2t7YiXOXy8RNkfrtrrHgp3KIZHHt T/HCOOep03ZwapwjwXfLhQkj9581lim2JafOpd5y1VrdygLn5EsGPhkkHqlafDbK +Hz1g5IIMOu9mHaytjDOPw==; X_CMAE_Category: , , X-CNFS-Analysis: v=2.0 cv=H91ZMpki c=1 sm=1 a=H03XQNzO3ZIBWxh40sAgAw==:17 a=5ZTteq0x3j8A:10 a=N659UExz7-8A:10 a=I_5RNyk1AAAA:8 a=aiIX5UjjAAAA:8 a=HGax8fYCcaDHn9W9flQA:9 a=pILNOxqGKmIA:10 a=H03XQNzO3ZIBWxh40sAgAw==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: YWRpYWJhdEBjZW50dXJ5bGluay5uZXQ= Authentication-Results: smtp03.agate.dfw.synacor.com smtp.user=adiabat@centurylink.net; auth=pass (LOGIN) Received: from [75.165.62.138] ([75.165.62.138:1998] helo=[192.168.0.101]) by smtp.centurylink.net (envelope-from ) (ecelerity 3.5.1.37854 r(Momo-dev:3.5.1.0)) with ESMTPSA (cipher=AES128-SHA) id B9/77-28279-72CC5745; Wed, 26 Nov 2014 07:48:39 -0500 Message-ID: <5475CC26.700@centurylink.net> Date: Wed, 26 Nov 2014 04:48:38 -0800 From: Phil Wolff User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Kjell Ahlstedt Subject: Re: App menu name References: <547557DD.3070000@centurylink.net> <5475A559.2060302@bredband.net> In-Reply-To: <5475A559.2060302@bredband.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: gtkmm-list@gnome.org X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 12:48:58 -0000 I'm also running Ubuntu (14.10), and I use the Unity desktop. I'm inclined to regard Unity as the prime suspect, so I'll submit a bug report accordingly. I was also looking at the changes you mention, and I think it would be great if you could demo the handling of command-line option and file parameters as well... On 2014/11/26 02:03, Kjell Ahlstedt wrote: > Den 2014-11-26 05:32, Phil Wolff skrev: >> I'm looking at the example code at >> https://git.gnome.org/browse/gtkmm-documentation/tree/examples/book/application/app_and_win_menus. >> >> >> At runtime the app menu is titled "Unknown Application Name," but the >> win menus are properly titled as "File," "Edit," and "Notification." >> >> Does this imply that something is missing from the code? >> ______________________________________________ > I have recently pushed some changes that make the menus/main_menu > example use an application menu. Then I noticed the same thing. > > I use Ubuntu, which has two desktop environments to choose from: > Ubuntu Unity and Gnome Flashback. Ubuntu Unity shows both the app menu > and the menubar outside the application's window, and the app menu is > titled "Unknown Application Name". Gnome Flashback shows both the app > menu and the menubar in the application's window, and the app menu is > titled "Gtk::Application Example" (or whatever name is set with > Glib::set_application_name()). Gtk+'s demo program behaves the same. > > I don't know if something is missing in these programs, or if it's a > bug in the Ubuntu Unity desktop shell. Which operating system do you use? > > Kjell -- If sunbeams were weapons of war, we would have had solar energy centuries ago. -- George Porter From john@creativepost.co.uk Wed Nov 26 13:36:43 2014 Return-Path: X-Original-To: gtkmm-list@gnome.org Delivered-To: gtkmm-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 6C29776A24 for ; Wed, 26 Nov 2014 13:36:43 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_FROM_12LTRDOM=0.01] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4ThZp8pd__0 for ; Wed, 26 Nov 2014 13:36:41 +0000 (UTC) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) by restaurant.gnome.org (Postfix) with ESMTP id 7505476A05 for ; Wed, 26 Nov 2014 13:36:30 +0000 (UTC) Received: from [192.168.1.2] (88-104-23-223.dynamic.dsl.as9105.com [88.104.23.223]) by mrelayeu.kundenserver.de (node=mreue102) with ESMTP (Nemesis) id 0LqlQA-1YOoeM3p7i-00eJIk; Wed, 26 Nov 2014 14:36:29 +0100 Message-ID: <5475D75B.8040506@creativepost.co.uk> Date: Wed, 26 Nov 2014 13:36:27 +0000 From: John Emmas User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: gtkmm Subject: MSVC build problems after updating from git Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:GBka+6jRZUUTGAQUityMD9/dOkVM5juY9dezZPjQ88b evk+O5hmTt38ARjPLM7FA71pU8TO83+INbFSzQCr/NilGJrP6i BW+nJmyATZ/gTeimE3ITNjnAXFawOLv7YirmD0XRmh+dNp23T/ hmannz1HFBXjx3y4LpybAQlXPWgymsck/6TVM+8TZrUyAXY+R9 bjxDit0X8VNfsxXprBneY3RBrlvSR/8UGk/Si0I3I4uStbHe7t jTk60AlKIN62PUm/u4ukCO+6XlWIXGTlHFdoiIaide4ZyViFm1 Rua+P0Mkr5lv0TEnpLaR8Lv8wYizaXFLH8q6qJtmnd4oAXfbjh c2G7xqYhlGrv4zNOUDo4452kbVlu6j5hUGnoEkZAt X-UI-Out-Filterresults: notjunk:1; X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 13:36:43 -0000 Firstly, a rider... I'm using my own-built MSVC projects for building glibmm and giomm (i.e. I don't use the ones supplied by git) - but having said that, my projects have worked perfectly up until this morning. After updating from git master this morning I noticed that some new sources got added to glibmm (namely, 'glib/src/binding.ccg' and its header file, 'binding.hg'). I added them to my project and glibmm built perfectly (i.e. my project converts them into the corresponding cc and h files). However, when the build then moved to giomm I suddenly see a lot of errors like this (which I've never seen before) and the build fails:- DocsParser.pm:lookup_object_of_method(): Warning: GtkDefs::lookup_object() failed for object name=GNotification, function name=g_notification_set_priority This may be a missing define-object in a *.defs file. There are probably half a dozen similar errors (where 'function name' is 'g_resources_register' / 'g_settings_schema_source_lookup' or whatever). I've never seen these errors before. Can anyone suggest what might be causing them? A new script that I need to run, maybe?? FWIW all the named 'function names' can be found in 'gio/src/gio_methods.defs') - except for the very last one which is 'g_settings_schema_key_range_check' (that one isn't found in any of my .defs files). Does that shed any light on the problem? Thanks, John From kjell.ahlstedt@bredband.net Wed Nov 26 14:32:29 2014 Return-Path: X-Original-To: gtkmm-list@gnome.org Delivered-To: gtkmm-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id D382576A67 for ; Wed, 26 Nov 2014 14:32:29 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQd4enauzX8H for ; Wed, 26 Nov 2014 14:32:27 +0000 (UTC) Received: from smtprelay-h21.telenor.se (smtprelay-h21.telenor.se [195.54.99.196]) by restaurant.gnome.org (Postfix) with ESMTP id 13283769CC for ; Wed, 26 Nov 2014 14:32:16 +0000 (UTC) Received: from ipb5.telenor.se (ipb5.telenor.se [195.54.127.168]) by smtprelay-h21.telenor.se (Postfix) with ESMTP id 00E12D119 for ; Wed, 26 Nov 2014 15:32:14 +0100 (CET) X-SMTPAUTH-B2: [kjell.ahlstedt@bredband.net] X-SENDER-IP: [85.229.156.35] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMBAHzjdVRV5ZwjPGdsb2JhbAANToNYV8U8gmeGSQKBIAEBAQEBAQUBAQEBOIQ+AQEEeAEQCw4KCRYPCQMCAQIBMRQGDQEHAQEaiCcIumqXHgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEkHsHhE0Fl0iiTXYBgkkBAQE X-IPAS-Result: AtMBAHzjdVRV5ZwjPGdsb2JhbAANToNYV8U8gmeGSQKBIAEBAQEBAQUBAQEBOIQ+AQEEeAEQCw4KCRYPCQMCAQIBMRQGDQEHAQEaiCcIumqXHgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEkHsHhE0Fl0iiTXYBgkkBAQE X-IronPort-AV: E=Sophos;i="5.07,462,1413237600"; d="scan'208,217";a="823594795" Received: from c-239ce555.06-203-73746f44.cust.bredbandsbolaget.se (HELO [192.168.1.64]) ([85.229.156.35]) by ipb5.telenor.se with ESMTP; 26 Nov 2014 15:32:14 +0100 Message-ID: <5475E46D.5060705@bredband.net> Date: Wed, 26 Nov 2014 15:32:13 +0100 From: Kjell Ahlstedt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Phil Wolff Subject: Re: App menu name References: <547557DD.3070000@centurylink.net> <5475A559.2060302@bredband.net> <5475CC26.700@centurylink.net> In-Reply-To: <5475CC26.700@centurylink.net> Content-Type: multipart/alternative; boundary="------------070402070806030709010007" Cc: gtkmm-list@gnome.org X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 14:32:29 -0000 This is a multi-part message in MIME format. --------------070402070806030709010007 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I suppose you have seen the example at https://git.gnome.org/browse/gtkmm-documentation/tree/examples/book/application/command_line_handling. Unfortunately it's not mentioned in the gtkmm tutorial. The tutorial would benefit from a whole new chapter, describing Gtk::Application and Gtk::ApplicationWindow. More volunteers would be welcome. The gtkmm tutorial has not been kept up-to-date with the latest changes in gtk+ and gtkmm. As an example, the Gesture classes are not mentioned. There is a short description of command-line options in the section that describes Boxes, https://developer.gnome.org/gtkmm-tutorial/stable/sec-multi-item-containers.html.en#boxes-command-line-options. Kjell Den 2014-11-26 13:48, Phil Wolff skrev: > I'm also running Ubuntu (14.10), and I use the Unity desktop. I'm > inclined to regard Unity as the prime suspect, so I'll submit a bug > report accordingly. > > I was also looking at the changes you mention, and I think it would be > great if you could demo the handling of command-line option and file > parameters as well... > > On 2014/11/26 02:03, Kjell Ahlstedt wrote: >> Den 2014-11-26 05:32, Phil Wolff skrev: >>> I'm looking at the example code at >>> https://git.gnome.org/browse/gtkmm-documentation/tree/examples/book/application/app_and_win_menus. >>> >>> >>> At runtime the app menu is titled "Unknown Application Name," but >>> the win menus are properly titled as "File," "Edit," and >>> "Notification." >>> >>> Does this imply that something is missing from the code? >>> ______________________________________________ >> I have recently pushed some changes that make the menus/main_menu >> example use an application menu. Then I noticed the same thing. >> >> I use Ubuntu, which has two desktop environments to choose from: >> Ubuntu Unity and Gnome Flashback. Ubuntu Unity shows both the app >> menu and the menubar outside the application's window, and the app >> menu is titled "Unknown Application Name". Gnome Flashback shows both >> the app menu and the menubar in the application's window, and the app >> menu is titled "Gtk::Application Example" (or whatever name is set >> with Glib::set_application_name()). Gtk+'s demo program behaves the >> same. >> >> I don't know if something is missing in these programs, or if it's a >> bug in the Ubuntu Unity desktop shell. Which operating system do you >> use? >> >> Kjell > --------------070402070806030709010007 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit I suppose you have seen the example at https://git.gnome.org/browse/gtkmm-documentation/tree/examples/book/application/command_line_handling. Unfortunately it's not mentioned in the gtkmm tutorial. The tutorial would benefit from a whole new chapter, describing Gtk::Application and Gtk::ApplicationWindow. More volunteers would be welcome. The gtkmm tutorial has not been kept up-to-date with the latest changes in gtk+ and gtkmm. As an example, the Gesture classes are not mentioned.

There is a short description of command-line options in the section that describes Boxes, https://developer.gnome.org/gtkmm-tutorial/stable/sec-multi-item-containers.html.en#boxes-command-line-options.

Kjell

Den 2014-11-26 13:48, Phil Wolff skrev:

I'm also running Ubuntu (14.10), and I use the Unity desktop. I'm inclined to regard Unity as the prime suspect, so I'll submit a bug report accordingly.

I was also looking at the changes you mention, and I think it would be great if you could demo the handling of command-line option and file parameters as well...

On 2014/11/26 02:03, Kjell Ahlstedt wrote:

Den 2014-11-26 05:32, Phil Wolff skrev:

I'm looking at the example code at https://git.gnome.org/browse/gtkmm-documentation/tree/examples/book/application/app_and_win_menus.

At runtime the app menu is titled "Unknown Application Name," but the win menus are properly titled as "File," "Edit," and "Notification."

Does this imply that something is missing from the code?
______________________________________________

I have recently pushed some changes that make the menus/main_menu example use an application menu. Then I noticed the same thing.

I use Ubuntu, which has two desktop environments to choose from: Ubuntu Unity and Gnome Flashback. Ubuntu Unity shows both the app menu and the menubar outside the application's window, and the app menu is titled "Unknown Application Name". Gnome Flashback shows both the app menu and the menubar in the application's window, and the app menu is titled "Gtk::Application Example" (or whatever name is set with Glib::set_application_name()). Gtk+'s demo program behaves the same.

I don't know if something is missing in these programs, or if it's a bug in the Ubuntu Unity desktop shell. Which operating system do you use?

Kjell

--------------070402070806030709010007-- From kjell.ahlstedt@bredband.net Wed Nov 26 14:44:07 2014 Return-Path: X-Original-To: gtkmm-list@gnome.org Delivered-To: gtkmm-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 3ACE8769AE for ; Wed, 26 Nov 2014 14:44:07 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yteFtKyvauwf for ; Wed, 26 Nov 2014 14:44:06 +0000 (UTC) Received: from smtprelay-b32.telenor.se (smtprelay-b32.telenor.se [213.150.131.21]) by restaurant.gnome.org (Postfix) with ESMTP id ABA067696B for ; Wed, 26 Nov 2014 14:43:55 +0000 (UTC) Received: from ipb2.telenor.se (ipb2.telenor.se [195.54.127.165]) by smtprelay-b32.telenor.se (Postfix) with ESMTP id 3BB72EF83E for ; Wed, 26 Nov 2014 15:43:52 +0100 (CET) X-SMTPAUTH-B2: [kjell.ahlstedt@bredband.net] X-SENDER-IP: [85.229.156.35] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngCAMDmdVRV5ZwjPGdsb2JhbAANTopovwOGH4MRAoEgAQEBAQEBBQEBAQE4hD4BAQR4ARALBB0WDwkDAgECATEUBg0BBwEBiEG7AZcdAQEBAQEBAQECAQEBAQEBAQEBGZB7B4RNBboVg0ABAQE X-IPAS-Result: AngCAMDmdVRV5ZwjPGdsb2JhbAANTopovwOGH4MRAoEgAQEBAQEBBQEBAQE4hD4BAQR4ARALBB0WDwkDAgECATEUBg0BBwEBiEG7AZcdAQEBAQEBAQECAQEBAQEBAQEBGZB7B4RNBboVg0ABAQE X-IronPort-AV: E=Sophos;i="5.07,462,1413237600"; d="scan'208,217";a="118949372" Received: from c-239ce555.06-203-73746f44.cust.bredbandsbolaget.se (HELO [192.168.1.64]) ([85.229.156.35]) by ipb2.telenor.se with ESMTP; 26 Nov 2014 15:43:52 +0100 Message-ID: <5475E728.3050801@bredband.net> Date: Wed, 26 Nov 2014 15:43:52 +0100 From: Kjell Ahlstedt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: John Emmas Subject: Re: MSVC build problems after updating from git References: <5475D75B.8040506@creativepost.co.uk> In-Reply-To: <5475D75B.8040506@creativepost.co.uk> Content-Type: multipart/alternative; boundary="------------070700060405030807010605" Cc: gtkmm X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 14:44:07 -0000 This is a multi-part message in MIME format. --------------070700060405030807010605 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit When I deleted the glibmm/gio/src/.stamps directory, thus forcing gmmproc to process all .hg an .ccg files, I got 7 warnings of the type you mention. When I did the same with gtkmm/gtk/src/.stamps, I got 9 such warnings. Those warnings are quite common. They only affect the documentation that gmmproc generates. gmmproc fails to convert a C function name to a corresponding C++ method name. It shouldn't make the build fail. I'm sure you've got similar warnings before, just you haven't noticed them when the build succeeded. You should probably search for the reason for the build failure somewhere else. Did any compilation start? Did you get compilation errors? Kjell Den 2014-11-26 14:36, John Emmas skrev: > Firstly, a rider... I'm using my own-built MSVC projects for building > glibmm and giomm (i.e. I don't use the ones supplied by git) - but > having said that, my projects have worked perfectly up until this > morning. > > After updating from git master this morning I noticed that some new > sources got added to glibmm (namely, 'glib/src/binding.ccg' and its > header file, 'binding.hg'). I added them to my project and glibmm > built perfectly (i.e. my project converts them into the corresponding > cc and h files). > > However, when the build then moved to giomm I suddenly see a lot of > errors like this (which I've never seen before) and the build fails:- > > DocsParser.pm:lookup_object_of_method(): Warning: > GtkDefs::lookup_object() failed > for object name=GNotification, function > name=g_notification_set_priority > This may be a missing define-object in a *.defs file. > > There are probably half a dozen similar errors (where 'function name' > is 'g_resources_register' / 'g_settings_schema_source_lookup' or > whatever). I've never seen these errors before. Can anyone suggest > what might be causing them? A new script that I need to run, maybe?? > > FWIW all the named 'function names' can be found in > 'gio/src/gio_methods.defs') - except for the very last one which is > 'g_settings_schema_key_range_check' (that one isn't found in any of my > .defs files). Does that shed any light on the problem? > > Thanks, > John > --------------070700060405030807010605 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit When I deleted the glibmm/gio/src/.stamps directory, thus forcing gmmproc to process all .hg an .ccg files, I got 7 warnings of the type you mention. When I did the same with gtkmm/gtk/src/.stamps, I got 9 such warnings. Those warnings are quite common. They only affect the documentation that gmmproc generates. gmmproc fails to convert a C function name to a corresponding C++ method name. It shouldn't make the build fail. I'm sure you've got similar warnings before, just you haven't noticed them when the build succeeded.

You should probably search for the reason for the build failure somewhere else. Did any compilation start? Did you get compilation errors?

Kjell

Den 2014-11-26 14:36, John Emmas skrev:

Firstly, a rider... I'm using my own-built MSVC projects for building glibmm and giomm (i.e. I don't use the ones supplied by git) - but having said that, my projects have worked perfectly up until this morning.

After updating from git master this morning I noticed that some new sources got added to glibmm (namely, 'glib/src/binding.ccg' and its header file, 'binding.hg'). I added them to my project and glibmm built perfectly (i.e. my project converts them into the corresponding cc and h files).

However, when the build then moved to giomm I suddenly see a lot of errors like this (which I've never seen before) and the build fails:-

      DocsParser.pm:lookup_object_of_method(): Warning: GtkDefs::lookup_object() failed
          for object name=GNotification, function name=g_notification_set_priority
              This may be a missing define-object in a *.defs file.

There are probably half a dozen similar errors (where 'function name' is 'g_resources_register' / 'g_settings_schema_source_lookup' or whatever). I've never seen these errors before. Can anyone suggest what might be causing them? A new script that I need to run, maybe??

FWIW all the named 'function names' can be found in 'gio/src/gio_methods.defs') - except for the very last one which is 'g_settings_schema_key_range_check' (that one isn't found in any of my .defs files). Does that shed any light on the problem?

Thanks,
John

--------------070700060405030807010605-- From john@creativepost.co.uk Wed Nov 26 18:59:30 2014 Return-Path: X-Original-To: gtkmm-list@gnome.org Delivered-To: gtkmm-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id BC68B76A06 for ; Wed, 26 Nov 2014 18:59:30 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -0.878 X-Spam-Level: X-Spam-Status: No, score=-0.878 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HnSc79RAmoI for ; Wed, 26 Nov 2014 18:59:29 +0000 (UTC) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) by restaurant.gnome.org (Postfix) with ESMTP id 3B271769F7 for ; Wed, 26 Nov 2014 18:59:18 +0000 (UTC) Received: from [192.168.1.2] (88-104-7-179.dynamic.dsl.as9105.com [88.104.7.179]) by mrelayeu.kundenserver.de (node=mreue002) with ESMTP (Nemesis) id 0Ly6KL-1XxTQP2AOD-015WtC; Wed, 26 Nov 2014 19:59:16 +0100 Message-ID: <54762304.7060704@creativepost.co.uk> Date: Wed, 26 Nov 2014 18:59:16 +0000 From: John Emmas User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 CC: gtkmm Subject: Re: MSVC build problems after updating from git References: <5475D75B.8040506@creativepost.co.uk> <5475E728.3050801@bredband.net> In-Reply-To: <5475E728.3050801@bredband.net> Content-Type: multipart/alternative; boundary="------------040805030309060801010901" X-Provags-ID: V02:K0:n8htoRtQdadkblXRskdIv1eMOg9M+TMQQFMweADxgP+ oFbI7ArWpJ4SMKhnWb/d46diIdVuomB5uH3eqGp0gmuWqUyzfc mFLnkHd6Vas2OYE2tY6PPXo1mpOMJm0MsbiL71cFmqTmoUmrcU OaJKunBpfVYlLAlRq+HOPc22Pv+i34K5FcxVvY1wLD5EepaL1v 88CeKpLkiI8ppX9pz03AE8QYCM8n7vGe5djs/AVixij7d1vM07 IAIodpZ+L4a7JW8OQ0hDU82l8EPOUfTjU8yn4ed9d8Uc1hKl4Q e4flhcrYKCxsv+x9JVSRSTd/pDTBrdkS7bggx0kyFzCFE+hwui 08q68r467NP9iZwlADALUAo0Sh8jAMeQKFBA5Iqk+ X-UI-Out-Filterresults: notjunk:1; X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 18:59:30 -0000 This is a multi-part message in MIME format. --------------040805030309060801010901 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 26/11/2014 14:43, Kjell Ahlstedt wrote: > Those warnings are quite common. They only affect the documentation > that gmmproc generates. gmmproc fails to convert a C function name to > a corresponding C++ method name. It shouldn't make the build fail. I'm > sure you've got similar warnings before, just you haven't noticed them > when the build succeeded. > Hi Kjell and thanks for the prompt reply. Firstly, you're right about those messages. My last update was about a fortnight ago (Nov 11th) and by a stroke of luck I backed it up. So I restored my old backup and ran a build (which worked). I only see 4 of those messages for giomm - but they do include the one I thought might be problematic (g_settings_schema_key_range_check). So I think you're right about that just being coincidental. > > You should probably search for the reason for the build failure > somewhere else. Did any compilation start? Did you get compilation errors? > No - in fact it fails exactly at the point where the compilation would normally begin. But there's no obvious reason. All the ccg and hg files got converted (correctly AFAICT). And I can compile the generated cc files (manually) and link them manually. It just won't flow from the pre-compile step into the compile stage any more. I decided to examine the generated cc and h files for giomm. 'resource.cc', 'resource.h' and 'error.h' are all significantly bigger than a fortnight ago but they all compile okay (so I don't think they're causing any problem) and everything else looks the same! Does gmmproc have any kind of return value? I'm just wondering if it might be returning an error status now, when it wasn't previously? Anyway, I'm too tired tonight to do any more work on this. It'll have to wait until I feel a bit fresher, tomorrow! John --------------040805030309060801010901 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

On 26/11/2014 14:43, Kjell Ahlstedt wrote:

Those warnings are quite common. They only affect the documentation that gmmproc generates. gmmproc fails to convert a C function name to a corresponding C++ method name. It shouldn't make the build fail. I'm sure you've got similar warnings before, just you haven't noticed them when the build succeeded.

Hi Kjell and thanks for the prompt reply.

Firstly, you're right about those messages. My last update was about a fortnight ago (Nov 11th) and by a stroke of luck I backed it up. So I restored my old backup and ran a build (which worked). I only see 4 of those messages for giomm - but they do include the one I thought might be problematic (g_settings_schema_key_range_check). So I think you're right about that just being coincidental.

You should probably search for the reason for the build failure somewhere else. Did any compilation start? Did you get compilation errors?

No - in fact it fails exactly at the point where the compilation would normally begin. But there's no obvious reason. All the ccg and hg files got converted (correctly AFAICT). And I can compile the generated cc files (manually) and link them manually. It just won't flow from the pre-compile step into the compile stage any more.

I decided to examine the generated cc and h files for giomm. 'resource.cc', 'resource.h' and 'error.h' are all significantly bigger than a fortnight ago but they all compile okay (so I don't think they're causing any problem) and everything else looks the same!

Does gmmproc have any kind of return value? I'm just wondering if it might be returning an error status now, when it wasn't previously?

Anyway, I'm too tired tonight to do any more work on this. It'll have to wait until I feel a bit fresher, tomorrow!

John
--------------040805030309060801010901-- From adiabat@centurylink.net Thu Nov 27 00:07:23 2014 Return-Path: X-Original-To: gtkmm-list@gnome.org Delivered-To: gtkmm-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id D821A76A79 for ; Thu, 27 Nov 2014 00:07:23 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYBycvdgOJIB for ; Thu, 27 Nov 2014 00:07:22 +0000 (UTC) Received: from smtp.centurylink.net (mail.centurylink.net [205.219.233.9]) by restaurant.gnome.org (Postfix) with ESMTP id 1325C76983 for ; Thu, 27 Nov 2014 00:07:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; d=centurylink.net; s=ctl201402; c=relaxed/simple; q=dns/txt; i=@centurylink.net; t=1417046829; h=From:Subject:Date:To:MIME-Version:Content-Type; bh=cTELQdWdhXyYXXwYW0zKXO65NpI=; b=Ejo76uO3NB+sgtLBDXNdyVdZ5MS6VumVp3mUYHzHs0KW2nFPvzRSskiVlxk30MS+ J5D9vX/xXNNpwHbdyphcTdIPhyO3B204v/A8tZRJKTenBnqMjc2S9PrTwTkHTExz TjLhJY/Di4NGUIovp6VzKJ9SQxYUKGqRzhan7rk0n5shp74CNTsN3r/73cna5whx XLBTVUT7ntcCg4EgzV8uKchHxivrUzcUixzwMcMJ2uLyZskaKRAPPxgXp67S5af7 nNrUCUWl5S3edmQmnxovbizKdbYAu7JCNscMKgO0AcrBfD/Cj1U86OezqDJiuf58 RdFa4xyGeZOpLNedd6m9oA==; X_CMAE_Category: , , X-CNFS-Analysis: v=2.0 cv=IdgFqBWa c=1 sm=1 a=H03XQNzO3ZIBWxh40sAgAw==:17 a=5ZTteq0x3j8A:10 a=N659UExz7-8A:10 a=I_5RNyk1AAAA:8 a=aiIX5UjjAAAA:8 a=WAzi3h8D1lWZKPi0etcA:9 a=pILNOxqGKmIA:10 a=2ipMPbs7hIUA:10 a=H03XQNzO3ZIBWxh40sAgAw==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: YWRpYWJhdEBjZW50dXJ5bGluay5uZXQ= Authentication-Results: smtp02.agate.dfw.synacor.com smtp.user=adiabat@centurylink.net; auth=pass (LOGIN) Received: from [75.165.62.138] ([75.165.62.138:5817] helo=[192.168.0.101]) by smtp.centurylink.net (envelope-from ) (ecelerity 3.5.1.37854 r(Momo-dev:3.5.1.0)) with ESMTPSA (cipher=AES128-SHA) id E1/1C-02382-C2B66745; Wed, 26 Nov 2014 19:07:09 -0500 Message-ID: <54766B2C.2010805@centurylink.net> Date: Wed, 26 Nov 2014 16:07:08 -0800 From: Phil Wolff User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Kjell Ahlstedt Subject: Re: App menu name References: <547557DD.3070000@centurylink.net> <5475A559.2060302@bredband.net> <5475CC26.700@centurylink.net> <5475E46D.5060705@bredband.net> In-Reply-To: <5475E46D.5060705@bredband.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: gtkmm-list@gnome.org X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: gtkmm general discussion