From kjell.ahlstedt@bredband.net Fri Mar 3 12:47:01 2017 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 smtp.gnome.org (Postfix) with ESMTP id 2851876232 for ; Fri, 3 Mar 2017 12:47:01 +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 smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsXRkNNm6VJI for ; Fri, 3 Mar 2017 12:46:59 +0000 (UTC) Received: from smtprelay-b12.telenor.se (smtprelay-b12.telenor.se [62.127.194.21]) by smtp.gnome.org (Postfix) with ESMTPS id 9127876227 for ; Fri, 3 Mar 2017 12:46:58 +0000 (UTC) Received: from ipb1.telenor.se (ipb1.telenor.se [195.54.127.164]) by smtprelay-b12.telenor.se (Postfix) with ESMTP id C6322C504 for ; Fri, 3 Mar 2017 13:46:55 +0100 (CET) X-SMTPAUTH-B2: [kjell.ahlstedt@bredband.net] X-SENDER-IP: [85.229.147.206] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DzCAC6ZLlYEM6T5VUNUR4GDIRbh2iYBZAqhBuBEXCBHRqJJxcBAgEBAQEBAQEGAQEBAQEBAjg5hhoBgQQaDQgBAbthgw4riw6GToIFCI0bBZwsggOhT5M7IQOBNjcqhxyKUgEBAQ X-IPAS-Result: A2DzCAC6ZLlYEM6T5VUNUR4GDIRbh2iYBZAqhBuBEXCBHRqJJxcBAgEBAQEBAQEGAQEBAQEBAjg5hhoBgQQaDQgBAbthgw4riw6GToIFCI0bBZwsggOhT5M7IQOBNjcqhxyKUgEBAQ X-IronPort-AV: E=Sophos;i="5.35,237,1484002800"; d="scan'208,217";a="1112858896" Received: from c-ce93e555.06-203-73746f44.cust.bredbandsbolaget.se (HELO [192.168.1.64]) ([85.229.147.206]) by ipb1.telenor.se with ESMTP; 03 Mar 2017 13:46:55 +0100 From: Kjell Ahlstedt Subject: Glibmm-2.52: Shall StreamIOChannel and IOChannel vfuncs be undeprecated? To: "gtkmm-list@gnome.org" Message-ID: Date: Fri, 3 Mar 2017 13:46:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------4E09C5FDA73BD0B0F24C978D" X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 12:47:01 -0000 This is a multi-part message in MIME format. --------------4E09C5FDA73BD0B0F24C978D Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit This concerns glibmm-2.52, the future API/ABI-breaking release. The whole StreamIOChannel class is deprecated. So are all virtual functions in IOChannel. A now removed comment explained why: This feature of being able to implement a custom Glib::IOChannel is deprecated in glibmm 2.2. The vfunc interface has not yet stabilized enough to allow that -- the C++ wrapper went in by pure accident. Is "not yet stabilized enough" still true? The latest ABI change in the vfuncs was made in February 2002. I can certainly remove StreamIOChannel and the vfuncs in glibmm 2.52, but wouldn't it be at least as good to keep them and undeprecate them? IMO the comment about not yet stabilized vfuncs is obsolete. --------------4E09C5FDA73BD0B0F24C978D Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

This concerns glibmm-2.52, the future API/ABI-breaking release.

The whole StreamIOChannel class is deprecated. So are all virtual functions in IOChannel. A now removed comment explained why:

This feature of being able to implement a custom Glib::IOChannel is
deprecated in glibmm 2.2.  The vfunc interface has not yet stabilized
enough to allow that -- the C++ wrapper went in by pure accident.

Is "not yet stabilized enough" still true? The latest ABI change in the vfuncs was made in February 2002. I can certainly remove StreamIOChannel and the vfuncs in glibmm 2.52, but wouldn't it be at least as good to keep them and undeprecate them? IMO the comment about not yet stabilized vfuncs is obsolete.

--------------4E09C5FDA73BD0B0F24C978D-- From dboles.src@gmail.com Fri Mar 10 09:40:06 2017 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 smtp.gnome.org (Postfix) with ESMTP id C0F2E76210 for ; Fri, 10 Mar 2017 09:40:06 +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 smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTj9LtwDBFY6 for ; Fri, 10 Mar 2017 09:40:05 +0000 (UTC) Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com [209.85.215.54]) by smtp.gnome.org (Postfix) with ESMTPS id 66829761F1 for ; Fri, 10 Mar 2017 09:40:05 +0000 (UTC) Received: by mail-lf0-f54.google.com with SMTP id j90so38701289lfk.2 for ; Fri, 10 Mar 2017 01:40:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=E5zBK3tjeue0alpOMrVt0QqqG/nG1nM2SmCDQyfaxaY=; b=r/7gNgiksTL28S6n6xVKR62VIPq/1FkxcmwJoH7KNExVse8x6C/UmWPgrCExMSNiqM +wE+OpdwXOoYfjzz46+k8bgOJj308ohMYIk2vqrKHG1FsU3QpH3d8F46vA7PDRLGDb/P 8r3RWCb9RYQxAekaihuMW7bSTtlCICagKudyb418wXv458EYLuEiTqWlCH84x1bY4YZm TF7OWycJ95+wRVcrVoREEgAsnsV10MwKvdoBq038ADadys+3bzIIcxdmvYg0D2kBOrdt 76MB9lRmk1doRcCMJSfh/EbogLvV7N7mJlLhrhKP8pfC6WrM27zemwLFjHQysxGrz9m/ VbHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=E5zBK3tjeue0alpOMrVt0QqqG/nG1nM2SmCDQyfaxaY=; b=Rw0l0I6FXZ3R2oId1IhvLepLbecA/M7Y+cwFji1X/nUPixLz6RE0Pv+0E45jf0g28h B1wJeBONTvLKUcPR3ykT6be6kKFudSUMn0re7GaKz7byIJA7VgeM/tktES5un1yMsgsJ KbnzBBcKqHfk6B1Kfo/VhEv2TYcHuddmCgXpMzOiQEkEALAKQbiK8yxyWoyaOXIVxzLO OepQNuDB7eBCSmQm0MP6bPW0cN9nXgZfScid9ibhcbv3U4XHmSFXEp39uJxtkfZIT7Se yaeENkBLhi4pc56xxzITwfanN/+jMc42PhWIgq3sqdxaz0O6RPgGMrqYQLQ1RYZmIqvF Z/Qw== X-Gm-Message-State: AMke39lfLqQNEFQpnt3scEvXCDZrxpp7F/TMHSn4FY5vrTk3ISaHHfAVEDtz2O70YvN1aZiVXff31uSqQ5HPPg== X-Received: by 10.46.71.198 with SMTP id u189mr5622985lja.97.1489138802210; Fri, 10 Mar 2017 01:40:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.18.222 with HTTP; Fri, 10 Mar 2017 01:40:01 -0800 (PST) From: Daniel Boles Date: Fri, 10 Mar 2017 09:40:01 +0000 Message-ID: Subject: Give multi-child containers a convenience Container::add(std::initializer_list) [and maybe ctor] ? To: gtkmm-list@gnome.org Content-Type: multipart/alternative; boundary=001a1141087053bf96054a5d2537 X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 09:40:06 -0000 --001a1141087053bf96054a5d2537 Content-Type: text/plain; charset=UTF-8 I don't know about you, but often I just want to create a Container, add a bunch of child Widgets to it, add it to a window or something, and forget about it. We then get repetitive code like this: box.add(foo); box.add(bar); box.add(bongo); Way back when, I had a wrapper class around Gtk::Box, which avoided the need for this by having an add() method that took an std::initializer_list: box.add( {&foo, &bar, &bongo} ); i.e.: it took an std::initializer_list and did the repetition for me - abstracting away that tedious part of the process and making the code look more like a visual representation of the UI layout. I also had an equivalent constructor overload, which did something like this: auto custom_box = CustomBox{ Gtk::ORIENTATION_HORIZONTAL, 8, {&foo, &bar, &bongo} ); i.e. which allowed constructing the container then adding to it in one step. Sometimes such Containers are even nested, and although I never got around to it, I can imagine being able to support that nicely too. Something like the following: auto nested_box = Box{ Gtk::ORIENTATION_VERTICAL, 8, // (assumes Box::spacing is kept!) { &blah, &wow, Gtk::manage( new Box{&some, &other, &widgets} ) } }; I stopped using that class for other reasons, but always missed the more succinct and visual representation of layout that it gave me in the code. I'm aware that .ui files exist for a similar goal, but call me old-fashioned: I want to create my layouts in code, not in an XML file that takes an additional round trip through Gtk::Builder to parse and create - plus still requires using C class names, afaict, Assuming it's not been discounted already, it would be great if this is the kind of overload of add(), and maybe also construction, that could be added to gtkmm. Has this been considered and rejected anywhere already? If not, I can add it as an RFE on Bugzilla. --001a1141087053bf96054a5d2537 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't know about you, but often I just want to = create a Container, = add a bunch of child Widget= s to it, add it to a window or something, and forget about it.

We then get repetitive code like this:

=C2=A0 box.add(foo);
=C2=A0 box.add(bar)= ;
=C2=A0 box.add(bongo);


Way back when, I had a wrappe= r class around Gtk::Box, which avoided the need for this by having an add() method that took an std::initializer_list:

=C2=A0 box.add( {&foo, &bar,= &bongo} );

i.e.: it took an std::initializer_list<Gtk::Widget*> and di= d the repetition for me - abstracting away that tedious part of the process= and making the code look more like a visual representation of the UI layou= t.


I also had an equivalent constructor overload, which did some= thing like this:

=C2= =A0 auto custom_box =3D CustomBox{ Gtk::ORIENTATION_HORIZONTAL, 8, {&fo= o, &bar, &bongo} );

i.e. which allowed constructing t= he container then adding to it in one step.


Sometimes such Containers are even neste= d, and although I never got around to it, I can imagine being able to suppo= rt that nicely too. Something like the following:

=C2=A0 auto nested_box =3D Box{=C2=A0=C2=A0=C2=A0 Gtk::ORIENTATION_VERTICAL, 8, // (assumes Box::spacing = is kept!)
=C2=A0=C2=A0=C2=A0 { &blah,
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 &wow,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Gtk::manage( new Box{&s= ome,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 &other,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &widgets} )
=C2=A0=C2=A0=C2= =A0 }
=C2=A0 };


I stopped using = that class for other reasons, but always missed the more succinct and visua= l representation of layout that it gave me in the code.


I'm = aware that .ui files= exist for a similar goal, but call me old-fashioned: I want to create my l= ayouts in code, not in an XML file that takes an additional round trip thro= ugh Gtk::Builder to = parse and create - plus still requires using C class names, afaict,


Assuming it's not been discounted already, it would be g= reat if this is the kind of overload of add(), and maybe also construction,= that could be added to gtk= mm.

Has this been considered and rejected anywhere already? I= f not, I can add it as an RFE on Bugzilla.

--001a1141087053bf96054a5d2537-- From piecuch@protonmail.com Fri Mar 10 12:33:02 2017 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 smtp.gnome.org (Postfix) with ESMTP id 1508D76233 for ; Fri, 10 Mar 2017 12:33:02 +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, MIME_BASE64_BLANKS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZ1V2jDh6nN0 for ; Fri, 10 Mar 2017 12:33:00 +0000 (UTC) Received: from mail3.protonmail.ch (mail3.protonmail.ch [185.70.40.25]) by smtp.gnome.org (Postfix) with ESMTPS id 5B16576232 for ; Fri, 10 Mar 2017 12:32:59 +0000 (UTC) Date: Fri, 10 Mar 2017 07:32:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1489149175; bh=9/+MztAc5JzIszNmlyNAxQ49yEWgJfhW2qgJNqBhV6Y=; h=To:From:Reply-To:Subject:Feedback-ID:From; b=B35j9Sc/uMedMQphvM032IBay3Q9QoE67axDCQsHFfsbnQev52hyj7YAOQtOGtl+O TR1oPrDUXWy+FzzuRlm4yI50oeJMOTtdbeSsvIesKvPQCyaUUdkDNkM40kfOUd/797 QWe7SpXjADGz7bdEb1z1xToxVhkjdnnBMnqshh7U= To: "gtkmm-list@gnome.org" From: Krzysztof Piecuch Reply-To: Krzysztof Piecuch Subject: Compiling gtkmm Message-ID: Feedback-ID: krphKiiPlx_XKIryTSpdJ_XtBwogkHXWA-Us-PsTeaBSrzOTAKWxwbFkseT4Z85b_7PMRvSnq3Ah7f9INXrOMw==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_c51648ea209427a6c12e96685a40d614" X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 12:33:02 -0000 This is a multi-part message in MIME format. --b1_c51648ea209427a6c12e96685a40d614 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGkgZ3V5cywgaXQncyBteSBmaXJzdCB0aW1lIGNvbnRyaWJ1dGluZyBoZXJlLiBNeSBuYW1lJ3Mg Q2hyaXMgYW5kIEkgd2FudGVkIHRvIGltcGxlbWVudCB1c3RyaW5nIG1ldGhvZCB3aGljaCBmaXhl cyBub24tdW5pY29kZSB1c3RyaW5ncyAoYW55IHBhcnRpY3VsYXIgcmVhc29uIGl0J3Mgbm90IHll dCBpbXBsZW1lbnRlZD8pCgpBbnl3YXksIEkgaGF2ZSBpbXBsZW1lbnRlZCBpdCwgYnV0IEkgaGF2 ZSB0cm91YmxlIHdpdGggY29tcGlsaW5nLiAuL2NvbmZpZ3VyZSBzYXlzIGd0a21tIG5lZWRzIHNp Z2MrKy0zLjAsIGFzIHdyaXR0ZW4gYmVsb3c6Cgpjb25maWd1cmU6IGVycm9yOiBQYWNrYWdlIHJl cXVpcmVtZW50cyAoc2lnYysrLTMuMCA+PSAyLjk5LjUgZ2xpYi0yLjAgPj0gMi41MC4wIGdvYmpl Y3QtMi4wID49IDIuNTAuMCBnbW9kdWxlLTIuMCA+PSAyLjUwLjApIHdlcmUgbm90IG1ldDoKTm8g cGFja2FnZSAnc2lnYysrLTMuMCcgZm91bmQKCkkgbG9va2VkIGZvciBzaWdjKystMy4wIGFuZCBm b3VuZCBvdXQgdGhhdCB0aGVyZSBpcyBubyBzdGFibGUgcmVsZWFzZSBvZiBpdCAoc2VlIGxpbmsg YmVsb3cpCmh0dHBzOi8vZ2l0aHViLmNvbS9HTk9NRS9saWJzaWdjcGx1c3BsdXMvYmxvYi9tYXN0 ZXIvTkVXUwpBbSBJIGNvcnJlY3QgdGhhdCB3ZSBhcmUgdXNpbmcgbm9uLXN0YWJsZSBsaWJyYXJ5 PyBJZiBzbywgd2hpY2ggdmVyc2lvbiBvZiBhIGxpYnJhcnkgaXMgYmVzdCB0byB1c2U/CgpZb3Vy cywKQ2hyaXM= --b1_c51648ea209427a6c12e96685a40d614 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdj5IaSBndXlzLCBpdCdzIG15IGZpcnN0IHRpbWUgY29udHJpYnV0aW5nIGhlcmUuIE15IG5h bWUncyBDaHJpcyBhbmQgSSB3YW50ZWQgdG8gaW1wbGVtZW50IHVzdHJpbmcgbWV0aG9kIHdoaWNo IGZpeGVzIG5vbi11bmljb2RlIHVzdHJpbmdzIChhbnkgcGFydGljdWxhciByZWFzb24gaXQncyBu b3QgeWV0IGltcGxlbWVudGVkPyk8YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5Bbnl3YXks IEkgaGF2ZSBpbXBsZW1lbnRlZCBpdCwgYnV0IEkgaGF2ZSB0cm91YmxlIHdpdGggY29tcGlsaW5n LiAuL2NvbmZpZ3VyZSBzYXlzIGd0a21tIG5lZWRzIHNpZ2MrKy0zLjAsIGFzIHdyaXR0ZW4gYmVs b3c6PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+Y29uZmlndXJlOiBlcnJvcjogUGFja2Fn ZSByZXF1aXJlbWVudHMgKHNpZ2MrKy0zLjAgJmd0Oz0gMi45OS41IGdsaWItMi4wICZndDs9IDIu NTAuMCBnb2JqZWN0LTIuMCAmZ3Q7PSAyLjUwLjAgZ21vZHVsZS0yLjAgJmd0Oz0gMi41MC4wKSB3 ZXJlIG5vdCBtZXQ6PGJyPjwvZGl2PjxkaXY+Tm8gcGFja2FnZSAnc2lnYysrLTMuMCcgZm91bmQ8 YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5JIGxvb2tlZCBmb3Igc2lnYysrLTMuMCBhbmQg Zm91bmQgb3V0IHRoYXQgdGhlcmUgaXMgbm8gc3RhYmxlIHJlbGVhc2Ugb2YgaXQgKHNlZSBsaW5r IGJlbG93KTxicj48L2Rpdj48ZGl2PjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9HTk9NRS9s aWJzaWdjcGx1c3BsdXMvYmxvYi9tYXN0ZXIvTkVXUyI+aHR0cHM6Ly9naXRodWIuY29tL0dOT01F L2xpYnNpZ2NwbHVzcGx1cy9ibG9iL21hc3Rlci9ORVdTPC9hPjxicj48L2Rpdj48ZGl2PkFtIEkg Y29ycmVjdCB0aGF0IHdlIGFyZSB1c2luZyBub24tc3RhYmxlIGxpYnJhcnk/IElmIHNvLCB3aGlj aCB2ZXJzaW9uIG9mIGEgbGlicmFyeSBpcyBiZXN0IHRvIHVzZT88YnI+PC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdj5Zb3Vycyw8YnI+PC9kaXY+PGRpdj5DaHJpczxicj48L2Rpdj4= --b1_c51648ea209427a6c12e96685a40d614-- From dboles.src@gmail.com Fri Mar 10 12:36:03 2017 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 smtp.gnome.org (Postfix) with ESMTP id A2B9C764A6 for ; Fri, 10 Mar 2017 12:36:03 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LjRM3nnG__C for ; Fri, 10 Mar 2017 12:36:02 +0000 (UTC) Received: from mail-lf0-f45.google.com (mail-lf0-f45.google.com [209.85.215.45]) by smtp.gnome.org (Postfix) with ESMTPS id 3C95F76232 for ; Fri, 10 Mar 2017 12:36:02 +0000 (UTC) Received: by mail-lf0-f45.google.com with SMTP id a6so40375423lfa.0 for ; Fri, 10 Mar 2017 04:36:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Q73c8kJnTo8CJLD/xW3I2sKxIc1uWhEeMIdKx95pm4Y=; b=AEElcWttacm65lJNOAGC4sV6FoTIxwB01ndvE9liytNcFAEYhwdEOhQxi83m7NSPXQ 0jQMF0z+KSKtSJPYH6epCH3DD1B6uTaVFmNuZQv6Y0y2cFwjc0DubT26EAOrvoIS+ufT YYSKJN+z7NgjHhRaovB/eQ3C5hQLL5i9wg+vA13ak8kvpi5G7N4BBdy+CPe0gfVs1dYp E5ywzsAuxcIDpU8dTz2VWjQeSIHzFF4BfK5Ygvyirt/JC4+wPKGCSjLdgbB8KXbHx8Ev bKk36UHZHoCOFHUIF5SmVDIM/4svNFh1VVhYk1rxrSugd+M/MUABhpOKajIHDrq5fGkK Xe8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Q73c8kJnTo8CJLD/xW3I2sKxIc1uWhEeMIdKx95pm4Y=; b=EYuyhC+g8khOdjQuvxvMQmbC7Eohmyo70FKRjCQN/XtvxtyiKEfXnZ3ctbyZGAubdC gUHFxWXiKyGul2a+pxtcCa6BuJKEmTQDJpWc4xk09JmjBDJxjD04I/cmI6MV7Srz0h/8 w6PzgrYrgvvlh6vjxoy+qmqx6rUfAYSqfRpf3PTvFaK3yCANgXWZUGAfIwUaJujy1PsI JqlCK6PMz5ZI1peIupQK0LNRIgyRTZjSUoW50Ka8RIsuF+htjnmubG7AfpYoc8ISpMIA sHn8EMRuMaDLQwcuhe6X9Qb7YDSPegDPSML+/WUbwwzsS4sWovJUhCTwqxA/Dzvhsk/b fXsw== X-Gm-Message-State: AMke39lEVno/8wvaFTOkWx/rBQKKGOeVARF7vPNTzyB7avFl9YiWyVBo9YDvTq/8hLKHj/O2Y5lC0giy4xZahw== X-Received: by 10.46.19.25 with SMTP id 25mr6039918ljt.103.1489149359294; Fri, 10 Mar 2017 04:35:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.18.222 with HTTP; Fri, 10 Mar 2017 04:35:58 -0800 (PST) From: Daniel Boles Date: Fri, 10 Mar 2017 12:35:58 +0000 Message-ID: Subject: Re: Compiling gtkmm To: gtkmm-list@gnome.org Content-Type: multipart/alternative; boundary=f403043605c6940c90054a5f9a0b X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 12:36:03 -0000 --f403043605c6940c90054a5f9a0b Content-Type: text/plain; charset=UTF-8 On 10 March 2017 at 12:32, Krzysztof Piecuch via gtkmm-list < gtkmm-list@gnome.org> wrote: > Hi guys, it's my first time contributing here. My name's Chris and I > wanted to implement ustring method which fixes non-unicode ustrings (any > particular reason it's not yet implemented?) > > Anyway, I have implemented it, but I have trouble with compiling. > ./configure says gtkmm needs sigc++-3.0, as written below: > > configure: error: Package requirements (sigc++-3.0 >= 2.99.5 glib-2.0 >= > 2.50.0 gobject-2.0 >= 2.50.0 gmodule-2.0 >= 2.50.0) were not met: > No package 'sigc++-3.0' found > > I looked for sigc++-3.0 and found out that there is no stable release of > it (see link below) > https://github.com/GNOME/libsigcplusplus/blob/master/NEWS > Am I correct that we are using non-stable library? If so, which version of > a library is best to use? > > Yours, > Chris > sigc++ 3 is the current unstable dev version, in branch master. It is not released yet. The same is true for the master branches of glibmm and gtkmm. How are you compiling glibmm/gtkmm? If you want stable, you should be compiling branches glibmm-2-50 and gtkmm-3-22 respectively - not master. In jhbuild, these are called glibmm-2.0 and gtkmm-3, or similar; the unsuffixed modules represent the master branches. --f403043605c6940c90054a5f9a0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 0 March 2017 at 12:32, Krzysztof Piecuch via gtkmm-list &= lt;gtkmm-list@gno= me.org> wrote:
Hi guys= , it's my first time contributing here. My name's Chris and I wante= d to implement ustring method which fixes non-unicode ustrings (any particu= lar reason it's not yet implemented?)

Anyw= ay, I have implemented it, but I have trouble with compiling. ./configure s= ays gtkmm needs sigc++-3.0, as written below:

= configure: error: Package requirements (sigc++-3.0 >=3D 2.99.5 glib-2.0 = >=3D 2.50.0 gobject-2.0 >=3D 2.50.0 gmodule-2.0 >=3D 2.50.0) were = not met:
No package 'sigc++-3.0' found
=
I looked for sigc++-3.0 and found out that there is no stabl= e release of it (see link below)
Am I= correct that we are using non-stable library? If so, which version of a li= brary is best to use?

Yours,
Chr= is


sigc++ 3 is the current un= stable dev version, in branch master. It is not released yet. The same is t= rue for the master branches of glibmm and gtkmm.

How are = you compiling glibmm/gtkmm? If you want stable, you should be compiling bra= nches glibmm-2-50 and gtkmm-3-22 respectively - not master. In jhbuild, the= se are called glibmm-2.0 and gtkmm-3, or similar; the unsuffixed modules re= present the master branches.



--f403043605c6940c90054a5f9a0b-- From piecuch@protonmail.com Fri Mar 10 12:47:53 2017 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 smtp.gnome.org (Postfix) with ESMTP id 4AB89764A6 for ; Fri, 10 Mar 2017 12:47:53 +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, MIME_BASE64_BLANKS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PN98qpXE676z for ; Fri, 10 Mar 2017 12:47:52 +0000 (UTC) Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27]) by smtp.gnome.org (Postfix) with ESMTPS id CF3E676233 for ; Fri, 10 Mar 2017 12:47:51 +0000 (UTC) Date: Fri, 10 Mar 2017 07:47:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1489150068; bh=9lWpo0mN5dn6NtSgQq7hA7LW02N9+fDb78SHu7Dgp2Q=; h=To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID:From; b=o/5EJUuulH8gjC5wu9r3C6Hzvu1TN1lHx/XszFlGT87phw54nFUyljdYbVclDIYVO 59QIFWTgVSQOjV0mR7NbO0T9GjUuVB+rI7874KNZfEszjLd5EYdqRqL0xBxrlZARCU ewdOmFfxd9rTkQB6M0guri+ynqOCk574mdCXtQcs= To: "gtkmm-list@gnome.org" From: Krzysztof Piecuch Reply-To: Krzysztof Piecuch Subject: Re: Compiling gtkmm Message-ID: In-Reply-To: References: Feedback-ID: krphKiiPlx_XKIryTSpdJ_XtBwogkHXWA-Us-PsTeaBSrzOTAKWxwbFkseT4Z85b_7PMRvSnq3Ah7f9INXrOMw==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_4fea971d1a7a15309707d8dd35cd9cc5" X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 12:47:53 -0000 This is a multi-part message in MIME format. --b1_4fea971d1a7a15309707d8dd35cd9cc5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 VGhhbmsgeW91IGZvciB5b3UgYW5zd2VyLCBJJ20gdHJ5aW5nIHRvIGNvbXBpbGUgaXQgd2l0aCAu L2F1dG9nZW4uc2guCkkgZG9uJ3QgcmVhbGx5IGtub3cgd2hpY2ggSSB3YW50IC0gSSAqdGhpbmsq IEkgc2hvdWxkIGNvbnRyaWJ1dGUgdG8gbWFzdGVyIGlmIEkgd2FudCB0byBpbnRyb2R1Y2UgbmV3 IHN0dWZmIHRvIHRoZSBsaWJyYXJ5LCBidXQgSSBjb3VsZG4ndCBmaW5kIGFueXRoaW5nIG9uIHRo YXQgdG9waWMgb24gdGhlIHdlYnNpdGUuCgoKLS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t LS0tLQpTdWJqZWN0OiBSZTogQ29tcGlsaW5nIGd0a21tCkxvY2FsIFRpbWU6IDEwIG1hcmNhIDIw MTcgMTozNSBQTQpVVEMgVGltZTogMTAgbWFyY2EgMjAxNyAxMjozNQpGcm9tOiBkYm9sZXMuc3Jj QGdtYWlsLmNvbQpUbzogZ3RrbW0tbGlzdEBnbm9tZS5vcmcKCgoKCk9uIDEwIE1hcmNoIDIwMTcg YXQgMTI6MzIsIEtyenlzenRvZiBQaWVjdWNoIHZpYSBndGttbS1saXN0IDxndGttbS1saXN0QGdu b21lLm9yZz4gd3JvdGU6CgpIaSBndXlzLCBpdCdzIG15IGZpcnN0IHRpbWUgY29udHJpYnV0aW5n IGhlcmUuIE15IG5hbWUncyBDaHJpcyBhbmQgSSB3YW50ZWQgdG8gaW1wbGVtZW50IHVzdHJpbmcg bWV0aG9kIHdoaWNoIGZpeGVzIG5vbi11bmljb2RlIHVzdHJpbmdzIChhbnkgcGFydGljdWxhciBy ZWFzb24gaXQncyBub3QgeWV0IGltcGxlbWVudGVkPykKCkFueXdheSwgSSBoYXZlIGltcGxlbWVu dGVkIGl0LCBidXQgSSBoYXZlIHRyb3VibGUgd2l0aCBjb21waWxpbmcuIC4vY29uZmlndXJlIHNh eXMgZ3RrbW0gbmVlZHMgc2lnYysrLTMuMCwgYXMgd3JpdHRlbiBiZWxvdzoKCmNvbmZpZ3VyZTog ZXJyb3I6IFBhY2thZ2UgcmVxdWlyZW1lbnRzIChzaWdjKystMy4wID49IDIuOTkuNSBnbGliLTIu MCA+PSAyLjUwLjAgZ29iamVjdC0yLjAgPj0gMi41MC4wIGdtb2R1bGUtMi4wID49IDIuNTAuMCkg d2VyZSBub3QgbWV0OgpObyBwYWNrYWdlICdzaWdjKystMy4wJyBmb3VuZAoKSSBsb29rZWQgZm9y IHNpZ2MrKy0zLjAgYW5kIGZvdW5kIG91dCB0aGF0IHRoZXJlIGlzIG5vIHN0YWJsZSByZWxlYXNl IG9mIGl0IChzZWUgbGluayBiZWxvdykKaHR0cHM6Ly9naXRodWIuY29tL0dOT01FL2xpYnNpZ2Nw bHVzcGx1cy9ibG9iL21hc3Rlci9ORVdTCkFtIEkgY29ycmVjdCB0aGF0IHdlIGFyZSB1c2luZyBu b24tc3RhYmxlIGxpYnJhcnk/IElmIHNvLCB3aGljaCB2ZXJzaW9uIG9mIGEgbGlicmFyeSBpcyBi ZXN0IHRvIHVzZT8KCllvdXJzLApDaHJpcwoKCgpzaWdjKysgMyBpcyB0aGUgY3VycmVudCB1bnN0 YWJsZSBkZXYgdmVyc2lvbiwgaW4gYnJhbmNoIG1hc3Rlci4gSXQgaXMgbm90IHJlbGVhc2VkIHll dC4gVGhlIHNhbWUgaXMgdHJ1ZSBmb3IgdGhlIG1hc3RlciBicmFuY2hlcyBvZiBnbGlibW0gYW5k IGd0a21tLgoKSG93IGFyZSB5b3UgY29tcGlsaW5nIGdsaWJtbS9ndGttbT8gSWYgeW91IHdhbnQg c3RhYmxlLCB5b3Ugc2hvdWxkIGJlIGNvbXBpbGluZyBicmFuY2hlcyBnbGlibW0tMi01MCBhbmQg Z3RrbW0tMy0yMiByZXNwZWN0aXZlbHkgLSBub3QgbWFzdGVyLiBJbiBqaGJ1aWxkLCB0aGVzZSBh cmUgY2FsbGVkIGdsaWJtbS0yLjAgYW5kIGd0a21tLTMsIG9yIHNpbWlsYXI7IHRoZSB1bnN1ZmZp eGVkIG1vZHVsZXMgcmVwcmVzZW50IHRoZSBtYXN0ZXIgYnJhbmNoZXMu --b1_4fea971d1a7a15309707d8dd35cd9cc5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdj5UaGFuayB5b3UgZm9yIHlvdSBhbnN3ZXIsIEknbSB0cnlpbmcgdG8gY29tcGlsZSBpdCB3 aXRoIC4vYXV0b2dlbi5zaC4gPGJyPjwvZGl2PjxkaXY+SSBkb24ndCByZWFsbHkga25vdyB3aGlj aCBJIHdhbnQgLSBJICp0aGluayogSSBzaG91bGQgY29udHJpYnV0ZSB0byBtYXN0ZXIgaWYgSSB3 YW50IHRvIGludHJvZHVjZSBuZXcgc3R1ZmYgdG8gdGhlIGxpYnJhcnksIGJ1dCBJIGNvdWxkbid0 IGZpbmQgYW55dGhpbmcgb24gdGhhdCB0b3BpYyBvbiB0aGUgd2Vic2l0ZS4gPGJyPjwvZGl2Pjxk aXY+PGJyPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSJwcm90b25tYWlsX3F1 b3RlIj48ZGl2Pi0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS08YnI+PC9kaXY+PGRp dj5TdWJqZWN0OiBSZTogQ29tcGlsaW5nIGd0a21tPGJyPjwvZGl2PjxkaXY+TG9jYWwgVGltZTog MTAgbWFyY2EgMjAxNyAxOjM1IFBNPGJyPjwvZGl2PjxkaXY+VVRDIFRpbWU6IDEwIG1hcmNhIDIw MTcgMTI6MzU8YnI+PC9kaXY+PGRpdj5Gcm9tOiBkYm9sZXMuc3JjQGdtYWlsLmNvbTxicj48L2Rp dj48ZGl2PlRvOiBndGttbS1saXN0QGdub21lLm9yZzxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48 ZGl2IGRpcj0ibHRyIj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGRpdiBjbGFzcz0iZ21haWxf cXVvdGUiPjxkaXY+T24gMTAgTWFyY2ggMjAxNyBhdCAxMjozMiwgS3J6eXN6dG9mIFBpZWN1Y2gg dmlhIGd0a21tLWxpc3QgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSByZWw9Im5vcmVmZXJyZXIgbm9m b2xsb3cgbm9vcGVuZXIiIGhyZWY9Im1haWx0bzpndGttbS1saXN0QGdub21lLm9yZyI+Z3RrbW0t bGlzdEBnbm9tZS5vcmc8L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPjwvZGl2PjxibG9ja3F1b3Rl IGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0 OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPjxkaXY+SGkgZ3V5cywgaXQncyBteSBm aXJzdCB0aW1lIGNvbnRyaWJ1dGluZyBoZXJlLiBNeSBuYW1lJ3MgQ2hyaXMgYW5kIEkgd2FudGVk IHRvIGltcGxlbWVudCB1c3RyaW5nIG1ldGhvZCB3aGljaCBmaXhlcyBub24tdW5pY29kZSB1c3Ry aW5ncyAoYW55IHBhcnRpY3VsYXIgcmVhc29uIGl0J3Mgbm90IHlldCBpbXBsZW1lbnRlZD8pPGJy PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+QW55d2F5LCBJIGhhdmUgaW1wbGVtZW50ZWQgaXQs IGJ1dCBJIGhhdmUgdHJvdWJsZSB3aXRoIGNvbXBpbGluZy4gLi9jb25maWd1cmUgc2F5cyBndGtt bSBuZWVkcyBzaWdjKystMy4wLCBhcyB3cml0dGVuIGJlbG93Ojxicj48L2Rpdj48ZGl2Pjxicj48 L2Rpdj48ZGl2PmNvbmZpZ3VyZTogZXJyb3I6IFBhY2thZ2UgcmVxdWlyZW1lbnRzIChzaWdjKyst My4wICZndDs9IDIuOTkuNSBnbGliLTIuMCAmZ3Q7PSAyLjUwLjAgZ29iamVjdC0yLjAgJmd0Oz0g Mi41MC4wIGdtb2R1bGUtMi4wICZndDs9IDIuNTAuMCkgd2VyZSBub3QgbWV0Ojxicj48L2Rpdj48 ZGl2Pk5vIHBhY2thZ2UgJ3NpZ2MrKy0zLjAnIGZvdW5kPGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2 PjxkaXY+SSBsb29rZWQgZm9yIHNpZ2MrKy0zLjAgYW5kIGZvdW5kIG91dCB0aGF0IHRoZXJlIGlz IG5vIHN0YWJsZSByZWxlYXNlIG9mIGl0IChzZWUgbGluayBiZWxvdyk8YnI+PC9kaXY+PGRpdj48 YSByZWw9Im5vcmVmZXJyZXIgbm9mb2xsb3cgbm9vcGVuZXIiIGhyZWY9Imh0dHBzOi8vZ2l0aHVi LmNvbS9HTk9NRS9saWJzaWdjcGx1c3BsdXMvYmxvYi9tYXN0ZXIvTkVXUyI+aHR0cHM6Ly9naXRo dWIuY29tL0dOT01FLzx3YnI+bGlic2lnY3BsdXNwbHVzL2Jsb2IvbWFzdGVyLzx3YnI+TkVXUzwv YT48YnI+PC9kaXY+PGRpdj5BbSBJIGNvcnJlY3QgdGhhdCB3ZSBhcmUgdXNpbmcgbm9uLXN0YWJs ZSBsaWJyYXJ5PyBJZiBzbywgd2hpY2ggdmVyc2lvbiBvZiBhIGxpYnJhcnkgaXMgYmVzdCB0byB1 c2U/PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+WW91cnMsPGJyPjwvZGl2PjxkaXY+Q2hy aXM8YnI+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGRpdj48YnI+PC9kaXY+PC9kaXY+PGRpdj48 ZGl2PnNpZ2MrKyAzIGlzIHRoZSBjdXJyZW50IHVuc3RhYmxlIGRldiB2ZXJzaW9uLCBpbiBicmFu Y2ggbWFzdGVyLiBJdCBpcyBub3QgcmVsZWFzZWQgeWV0LiBUaGUgc2FtZSBpcyB0cnVlIGZvciB0 aGUgbWFzdGVyIGJyYW5jaGVzIG9mIGdsaWJtbSBhbmQgZ3RrbW0uPGJyPjwvZGl2PjwvZGl2Pjxk aXY+PGRpdj5Ib3cgYXJlIHlvdSBjb21waWxpbmcgZ2xpYm1tL2d0a21tPyBJZiB5b3Ugd2FudCBz dGFibGUsIHlvdSBzaG91bGQgYmUgY29tcGlsaW5nIGJyYW5jaGVzIGdsaWJtbS0yLTUwIGFuZCBn dGttbS0zLTIyIHJlc3BlY3RpdmVseSAtIG5vdCBtYXN0ZXIuIEluIGpoYnVpbGQsIHRoZXNlIGFy ZSBjYWxsZWQgZ2xpYm1tLTIuMCBhbmQgZ3RrbW0tMywgb3Igc2ltaWxhcjsgdGhlIHVuc3VmZml4 ZWQgbW9kdWxlcyByZXByZXNlbnQgdGhlIG1hc3RlciBicmFuY2hlcy48YnI+PC9kaXY+PGRpdj48 YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9ibG9ja3F1 b3RlPjxkaXY+PGJyPjwvZGl2Pg== --b1_4fea971d1a7a15309707d8dd35cd9cc5-- From dboles.src@gmail.com Fri Mar 10 12:54:08 2017 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 smtp.gnome.org (Postfix) with ESMTP id 696F7764A6 for ; Fri, 10 Mar 2017 12:54:08 +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 smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x_zYIiBmk9VI for ; Fri, 10 Mar 2017 12:54:07 +0000 (UTC) Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com [209.85.215.54]) by smtp.gnome.org (Postfix) with ESMTPS id 0E73D76232 for ; Fri, 10 Mar 2017 12:54:06 +0000 (UTC) Received: by mail-lf0-f54.google.com with SMTP id y193so40453658lfd.3 for ; Fri, 10 Mar 2017 04:54:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=J47VLnrB5T5QNXxAAVvP4gt2hrAEgzMb7vxXPKGyEbw=; b=Estpzt/xUau+ewAokdsUF/2rd9m5wKYQ+PdllInELItRoTLPWQFXgoYAtvkjbQ2bBI sbxglph0jq9z9PxnWxM9Jzhq8eIy4d119gundhDuY5QX96C3qe5VUjZ4N/gFAqd/hEPc zO8q62C1YLnT1+p/xo4j20aA9uHk1etazkbOeZOsov21fqueZpAaTA6q2KEtBjjikCh5 vtJ6wBxVtTc0CJy1Gdt1THFQRrkAkJLe6pWwCg8umm6XXvVwU2Z97Lv9ts5oRJsYAz9j FiiesSozNSIC5q2KtJJ8mYyeFndZVff0ppU58vi3Egl5PZO+ymcI0DyBhCddY8HP38YS 14jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=J47VLnrB5T5QNXxAAVvP4gt2hrAEgzMb7vxXPKGyEbw=; b=aUAtf+0T7Agkxwb/3my4hJsOY2s2lgF+pKOtqB4oJap1XNV114RDzgiysHQl5at/fq CNFNpP2xWLrD71EZ7lnJCMaaGXdA0yrMUyypS9dMP+23WwiekU+SSL7LLcokiy/iMB+N SXqgcvsMuPEW3D6KQ6xJ/peMWunLr700bEN2y1lgSC7q495JiI89Ao2mNm/ocFIyXuUb 14+8auRQ9QqbnpuWbWjElxhFCZbVUJG84UAuP0bL7sSdIXOrG0qruhbwHdi2aQBN2Rrz NxO1ICyA8Mo/LyfX3PMSmE3OYK37K/Z1NtGyf20VxBInEXXAK49T/gCUJEtqRvY+Bt0V Z8Zg== X-Gm-Message-State: AMke39kbPRAwDgCAxXpBGQV/mYGYopqktu6d55lzdXaJhDVgjkoOr07Vxeiv/p4UtAfCZhTQgHkJKndKh2ia2g== X-Received: by 10.46.33.158 with SMTP id h30mr6024513lji.53.1489150444104; Fri, 10 Mar 2017 04:54:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.18.222 with HTTP; Fri, 10 Mar 2017 04:54:03 -0800 (PST) In-Reply-To: References: From: Daniel Boles Date: Fri, 10 Mar 2017 12:54:03 +0000 Message-ID: Subject: Re: Compiling gtkmm To: Krzysztof Piecuch Cc: "gtkmm-list@gnome.org" Content-Type: multipart/alternative; boundary=001a1142c8c23cf131054a5fdbd8 X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 12:54:08 -0000 --001a1142c8c23cf131054a5fdbd8 Content-Type: text/plain; charset=UTF-8 On 10 March 2017 at 12:47, Krzysztof Piecuch via gtkmm-list < gtkmm-list@gnome.org> wrote: > Thank you for you answer, I'm trying to compile it with ./autogen.sh. > I don't really know which I want - I *think* I should contribute to master > if I want to introduce new stuff to the library, but I couldn't find > anything on that topic on the website. > Indeed, the default is to base patches on master, unless the patch is only applicable to stable - and especially if you are adding new API, which I now realise you are. In that case, then of course, you simply need to compile and install sigc++ master (3) first. I tend to find jhbuild an easier way to do this nowadays, but sigc++ is small enough that it's not much hassle to do manually. Once the package is installed on your system, the .pc file will be available for pkg-config to find, and configure for gtkmm will succeed. (assuming no other missing deps, etc.) --001a1142c8c23cf131054a5fdbd8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 0 March 2017 at 12:47, Krzysztof Piecuch via gtkmm-list &= lt;gtkmm-list@gno= me.org> wrote:
Thank y= ou for you answer, I'm trying to compile it with ./autogen.sh.
I don't really know which I want - I *think* I should contribute= to master if I want to introduce new stuff to the library, but I couldn= 9;t find anything on that topic on the website.
=
Indeed, the default is to base patches on master, unless the= patch is only applicable to stable - and especially if you are adding new = API, which I now realise you are.

In that case, then of c= ourse, you simply need to compile and install sigc++ master (3) first. I te= nd to find jhbuild an easier way to do this nowadays, but sigc++ is small e= nough that it's not much hassle to do manually.

Once = the package is installed on your system, the .pc file will be available for= pkg-config to find, and configure for gtkmm will succeed. (assuming no oth= er missing deps, etc.)

--001a1142c8c23cf131054a5fdbd8-- From piecuch@protonmail.com Fri Mar 10 13:16:55 2017 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 smtp.gnome.org (Postfix) with ESMTP id 09FA2763D8 for ; Fri, 10 Mar 2017 13:16:55 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 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, MIME_BASE64_BLANKS=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezKN9cKtbUA8 for ; Fri, 10 Mar 2017 13:16:53 +0000 (UTC) Received: from mail3.protonmail.ch (mail3.protonmail.ch [185.70.40.25]) by smtp.gnome.org (Postfix) with ESMTPS id 1962A76222 for ; Fri, 10 Mar 2017 13:16:52 +0000 (UTC) Date: Fri, 10 Mar 2017 07:56:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1489151808; bh=p2CcBk0e/8K0buJnXn0KbXVcqOTP/ibIg9rr9KXgxT4=; h=From:Cc:Reply-To:Subject:In-Reply-To:References:Feedback-ID:From; b=Cq876bJHJmrqlOWgYQZ98L4OJc/mwz8lbZCy9iy+kGLOE10EZwy5X2Ao9YpXjk6Ie yHaAsxMFaEUQMgXzl/CrAtNFoxDsGUIGy9XYSeo1oGydWgLMwAiGAAtolYKJ54tJQv 0GZGdPbuaRBkZTiBAsjSFo9nfqEMCi1J+4Euz3/M= From: Krzysztof Piecuch Cc: "gtkmm-list@gnome.org" Reply-To: Krzysztof Piecuch Subject: Re: Compiling gtkmm Message-ID: <7BLXdvL8NOp-sZd037fs78if_nz68tDF0mo27y2xyEj9edz24D9gZuN2fGqnNq6dhtbyK8UDAOmqXIoV4i0b7KcKwo9MY73Qcn1_RJWOueE=@protonmail.com> In-Reply-To: References: Feedback-ID: krphKiiPlx_XKIryTSpdJ_XtBwogkHXWA-Us-PsTeaBSrzOTAKWxwbFkseT4Z85b_7PMRvSnq3Ah7f9INXrOMw==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_e044bd125937b80f2dd312e9ccd0c3ff" X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 13:16:55 -0000 This is a multi-part message in MIME format. --b1_e044bd125937b80f2dd312e9ccd0c3ff Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 VGhhbmsgeW91IGZvciBjbGVhcmluZyBhd2F5IG15IHByb2JsZW1zLiBJJ20gZ2V0dGluZyBiYWNr IHRvIHdvcmsgbm93LgoKCgpTZW50IHdpdGggW1Byb3Rvbk1haWxdKGh0dHBzOi8vcHJvdG9ubWFp bC5jb20pIFNlY3VyZSBFbWFpbC4KCgotLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0t ClN1YmplY3Q6IFJlOiBDb21waWxpbmcgZ3RrbW0KTG9jYWwgVGltZTogMTAgbWFyY2EgMjAxNyAx OjU0IFBNClVUQyBUaW1lOiAxMCBtYXJjYSAyMDE3IDEyOjU0CkZyb206IGRib2xlcy5zcmNAZ21h aWwuY29tClRvOiBLcnp5c3p0b2YgUGllY3VjaCA8cGllY3VjaEBwcm90b25tYWlsLmNvbT4KZ3Rr bW0tbGlzdEBnbm9tZS5vcmcgPGd0a21tLWxpc3RAZ25vbWUub3JnPgoKCgoKT24gMTAgTWFyY2gg MjAxNyBhdCAxMjo0NywgS3J6eXN6dG9mIFBpZWN1Y2ggdmlhIGd0a21tLWxpc3QgPGd0a21tLWxp c3RAZ25vbWUub3JnPiB3cm90ZToKClRoYW5rIHlvdSBmb3IgeW91IGFuc3dlciwgSSdtIHRyeWlu ZyB0byBjb21waWxlIGl0IHdpdGggLi9hdXRvZ2VuLnNoLgpJIGRvbid0IHJlYWxseSBrbm93IHdo aWNoIEkgd2FudCAtIEkgKnRoaW5rKiBJIHNob3VsZCBjb250cmlidXRlIHRvIG1hc3RlciBpZiBJ IHdhbnQgdG8gaW50cm9kdWNlIG5ldyBzdHVmZiB0byB0aGUgbGlicmFyeSwgYnV0IEkgY291bGRu J3QgZmluZCBhbnl0aGluZyBvbiB0aGF0IHRvcGljIG9uIHRoZSB3ZWJzaXRlLgoKCkluZGVlZCwg dGhlIGRlZmF1bHQgaXMgdG8gYmFzZSBwYXRjaGVzIG9uIG1hc3RlciwgdW5sZXNzIHRoZSBwYXRj aCBpcyBvbmx5IGFwcGxpY2FibGUgdG8gc3RhYmxlIC0gYW5kIGVzcGVjaWFsbHkgaWYgeW91IGFy ZSBhZGRpbmcgbmV3IEFQSSwgd2hpY2ggSSBub3cgcmVhbGlzZSB5b3UgYXJlLgoKSW4gdGhhdCBj YXNlLCB0aGVuIG9mIGNvdXJzZSwgeW91IHNpbXBseSBuZWVkIHRvIGNvbXBpbGUgYW5kIGluc3Rh bGwgc2lnYysrIG1hc3RlciAoMykgZmlyc3QuIEkgdGVuZCB0byBmaW5kIGpoYnVpbGQgYW4gZWFz aWVyIHdheSB0byBkbyB0aGlzIG5vd2FkYXlzLCBidXQgc2lnYysrIGlzIHNtYWxsIGVub3VnaCB0 aGF0IGl0J3Mgbm90IG11Y2ggaGFzc2xlIHRvIGRvIG1hbnVhbGx5LgoKT25jZSB0aGUgcGFja2Fn ZSBpcyBpbnN0YWxsZWQgb24geW91ciBzeXN0ZW0sIHRoZSAucGMgZmlsZSB3aWxsIGJlIGF2YWls YWJsZSBmb3IgcGtnLWNvbmZpZyB0byBmaW5kLCBhbmQgY29uZmlndXJlIGZvciBndGttbSB3aWxs IHN1Y2NlZWQuIChhc3N1bWluZyBubyBvdGhlciBtaXNzaW5nIGRlcHMsIGV0Yy4p --b1_e044bd125937b80f2dd312e9ccd0c3ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdj5UaGFuayB5b3UgZm9yIGNsZWFyaW5nIGF3YXkgbXkgcHJvYmxlbXMuIEknbSBnZXR0aW5n IGJhY2sgdG8gd29yayBub3cuPGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgY2xhc3M9InBy b3Rvbm1haWxfc2lnbmF0dXJlX2Jsb2NrICI+PGRpdiBjbGFzcz0icHJvdG9ubWFpbF9zaWduYXR1 cmVfYmxvY2stdXNlciBwcm90b25tYWlsX3NpZ25hdHVyZV9ibG9jay1lbXB0eSI+PGJyPjwvZGl2 PjxkaXYgY2xhc3M9InByb3Rvbm1haWxfc2lnbmF0dXJlX2Jsb2NrLXByb3RvbiAiPlNlbnQgd2l0 aCA8YSBocmVmPSJodHRwczovL3Byb3Rvbm1haWwuY29tIj5Qcm90b25NYWlsPC9hPiBTZWN1cmUg RW1haWwuPGJyPjwvZGl2PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSJwcm90b25tYWlsX3F1b3RlIj48ZGl2Pi0tLS0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0tLS08YnI+PC9kaXY+PGRpdj5TdWJqZWN0OiBSZTogQ29tcGlsaW5nIGd0a21tPGJy PjwvZGl2PjxkaXY+TG9jYWwgVGltZTogMTAgbWFyY2EgMjAxNyAxOjU0IFBNPGJyPjwvZGl2Pjxk aXY+VVRDIFRpbWU6IDEwIG1hcmNhIDIwMTcgMTI6NTQ8YnI+PC9kaXY+PGRpdj5Gcm9tOiBkYm9s ZXMuc3JjQGdtYWlsLmNvbTxicj48L2Rpdj48ZGl2PlRvOiBLcnp5c3p0b2YgUGllY3VjaCAmbHQ7 cGllY3VjaEBwcm90b25tYWlsLmNvbSZndDs8YnI+PC9kaXY+PGRpdj5ndGttbS1saXN0QGdub21l Lm9yZyAmbHQ7Z3RrbW0tbGlzdEBnbm9tZS5vcmcmZ3Q7PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2 PjxkaXYgZGlyPSJsdHIiPjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48ZGl2IGNsYXNzPSJnbWFp bF9xdW90ZSI+PGRpdj5PbiAxMCBNYXJjaCAyMDE3IGF0IDEyOjQ3LCBLcnp5c3p0b2YgUGllY3Vj aCB2aWEgZ3RrbW0tbGlzdCA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIHJlbD0ibm9yZWZlcnJlciBu b2ZvbGxvdyBub29wZW5lciIgaHJlZj0ibWFpbHRvOmd0a21tLWxpc3RAZ25vbWUub3JnIj5ndGtt bS1saXN0QGdub21lLm9yZzwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+PC9kaXY+PGJsb2NrcXVv dGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxl ZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PGRpdj5UaGFuayB5b3UgZm9yIHlv dSBhbnN3ZXIsIEknbSB0cnlpbmcgdG8gY29tcGlsZSBpdCB3aXRoIC4vYXV0b2dlbi5zaC4gPGJy PjwvZGl2PjxkaXY+SSBkb24ndCByZWFsbHkga25vdyB3aGljaCBJIHdhbnQgLSBJICp0aGluayog SSBzaG91bGQgY29udHJpYnV0ZSB0byBtYXN0ZXIgaWYgSSB3YW50IHRvIGludHJvZHVjZSBuZXcg c3R1ZmYgdG8gdGhlIGxpYnJhcnksIGJ1dCBJIGNvdWxkbid0IGZpbmQgYW55dGhpbmcgb24gdGhh dCB0b3BpYyBvbiB0aGUgd2Vic2l0ZS48YnI+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwv ZGl2PjxkaXY+PGRpdj5JbmRlZWQsIHRoZSBkZWZhdWx0IGlzIHRvIGJhc2UgcGF0Y2hlcyBvbiBt YXN0ZXIsIHVubGVzcyB0aGUgcGF0Y2ggaXMgb25seSBhcHBsaWNhYmxlIHRvIHN0YWJsZSAtIGFu ZCBlc3BlY2lhbGx5IGlmIHlvdSBhcmUgYWRkaW5nIG5ldyBBUEksIHdoaWNoIEkgbm93IHJlYWxp c2UgeW91IGFyZS48YnI+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PkluIHRoYXQgY2FzZSwgdGhlbiBv ZiBjb3Vyc2UsIHlvdSBzaW1wbHkgbmVlZCB0byBjb21waWxlIGFuZCBpbnN0YWxsIHNpZ2MrKyBt YXN0ZXIgKDMpIGZpcnN0LiBJIHRlbmQgdG8gZmluZCBqaGJ1aWxkIGFuIGVhc2llciB3YXkgdG8g ZG8gdGhpcyBub3dhZGF5cywgYnV0IHNpZ2MrKyBpcyBzbWFsbCBlbm91Z2ggdGhhdCBpdCdzIG5v dCBtdWNoIGhhc3NsZSB0byBkbyBtYW51YWxseS48YnI+PC9kaXY+PC9kaXY+PGRpdj48ZGl2Pk9u Y2UgdGhlIHBhY2thZ2UgaXMgaW5zdGFsbGVkIG9uIHlvdXIgc3lzdGVtLCB0aGUgLnBjIGZpbGUg d2lsbCBiZSBhdmFpbGFibGUgZm9yIHBrZy1jb25maWcgdG8gZmluZCwgYW5kIGNvbmZpZ3VyZSBm b3IgZ3RrbW0gd2lsbCBzdWNjZWVkLiAoYXNzdW1pbmcgbm8gb3RoZXIgbWlzc2luZyBkZXBzLCBl dGMuKTxicj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48 YnI+PC9kaXY+ --b1_e044bd125937b80f2dd312e9ccd0c3ff-- From dboles.src@gmail.com Fri Mar 10 15:10:08 2017 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 smtp.gnome.org (Postfix) with ESMTP id 7970F763D8 for ; Fri, 10 Mar 2017 15:10:08 +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 smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AH1BWT4tpF2P for ; Fri, 10 Mar 2017 15:10:05 +0000 (UTC) Received: from mail-lf0-f41.google.com (mail-lf0-f41.google.com [209.85.215.41]) by smtp.gnome.org (Postfix) with ESMTPS id 4C78B76202 for ; Fri, 10 Mar 2017 15:10:04 +0000 (UTC) Received: by mail-lf0-f41.google.com with SMTP id z15so20036065lfd.1 for ; Fri, 10 Mar 2017 07:10:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YDKQT9uIihfcOnI1w0IvifqmgMJkGDhPF1qVLWBHQiM=; b=O/HdHmQdLtiq5yh1FVU+uh6tG37SEXU484ikigceNuFuCKEJ6UhM3lTWXInk61nrna lOAp/t1Ish1n3ZUzKrHymrT6R4Uirr6mGkAAccDBz/esIljvDG4QhOvfOWWMQbfNj6Lh qDvIqqnODwlWNdCZQTfVJx8LHPvojZ5fypqkJQi6LrOxlXu/ERRN7PNVrf5vz8VmxTdd CVhlcoe76pmglsVpf06TMlZohfu3vDbSBiKmVXdhj89IQ3LZCxwjwXiSBCqV0xZJCYA1 IfJA9CXatwjjZubKBwudGWhUQxfwiq+sdboTuelXWG2lCUW7dduN/+beLyO6ZsyIr7fU yZKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YDKQT9uIihfcOnI1w0IvifqmgMJkGDhPF1qVLWBHQiM=; b=svf9rtPM+OZEM72tw795opsw/eiYL9Daz6CNVEedCzMpMVs+hBrfLom1ZeAfz9lQPh P5Nk+9hatJ4VQRw+JuoMz79/UoiOn5x5CCQE6BpHgmViKSyNjUBxWt4kMrgak88bYJH+ QP27RXrpj6gInh42j/rK6UKsI9pAwvxWfB6DiTZh4lAizd/DPg/j/ySHiEU//I5FEeZY fSSaqQVpWnBmbHU/L2XC6tt5oOsVT23kO8AVFEw64tSuyNO7a7mPfKt7yt3BNBiZiyW5 ilFghWVV3xvz6yCu6mKnOKdhsyaKvY6dJk9vG3YWEdXomNTVtb8+X1o4utcyA/qUVmsS JSNQ== X-Gm-Message-State: AMke39luFeY+0Csu77Di/7j+zGDj0piRN2A+bH37/5lNNt/ZgCpS4DYtyboVZGpa7cbqN8ZcM5SmmPLs9o/XFQ== X-Received: by 10.25.125.213 with SMTP id y204mr5198912lfc.161.1489158601703; Fri, 10 Mar 2017 07:10:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.18.222 with HTTP; Fri, 10 Mar 2017 07:10:01 -0800 (PST) In-Reply-To: <8d428e58-d877-5b32-4636-61cc3ca0fbcc@bredband.net> References: <8d428e58-d877-5b32-4636-61cc3ca0fbcc@bredband.net> From: Daniel Boles Date: Fri, 10 Mar 2017 15:10:01 +0000 Message-ID: Subject: Re: Give multi-child containers a convenience Container::add(std::initializer_list) [and maybe ctor] ? To: Kjell Ahlstedt Cc: gtkmm-list@gnome.org Content-Type: multipart/alternative; boundary=001a114b017c78078f054a61c10b X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 15:10:08 -0000 --001a114b017c78078f054a61c10b Content-Type: text/plain; charset=UTF-8 On 10 March 2017 at 14:58, Kjell Ahlstedt wrote: > I don't think it has been considered, and certainly not rejected. It's a > good idea. > Cool! > A lot of details can be discussed. There could be > > Gtk::Container::add(std::initializer_list widgets); > Gtk::Box::pack_start(std::initializer_list widgets, > PackOptions options); > Gtk::Box::pack_end(std::initializer_list widgets, > PackOptions options); > etc. > > Indeed. I just didn't want to suggest too many variations at first, in case even the most basic ones weren't an option. :D > It would be even better with a list of references: > std::initializer_list. Is that possible, or would the > compiler try to copy the widgets? > Containers of references aren't possible in C++. The closest thing to this, I guess, is std::reference_wrapper - i.e. a utility class that wraps a pointer and gives it reference-like semantics (plus a few extras). This might (I dunno) mean some extra boilerplate or compromise, but it would probably be worth it to ensure none of the passed elements are nullptr. So, that's a good point. We might want to guard against that. Alternatively, we could just tell users that passing a nullptr is UB and trust them to do it right. I guess this is one to debate. Even then, yes, initializer_list is still restricted to having implicitly const elements, so the reference_wrappers would be copied, but again, since they too are just pointers really, that's fine. (but IMO movable-from initializer_lists are sorely needed for other cases, though) --001a114b017c78078f054a61c10b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 0 March 2017 at 14:58, Kjell Ahlstedt <kjell.ahlstedt@bredband.n= et> wrote:
=20 =20 =20 I don't think it has been considered, and cer= tainly not rejected. It's a good idea.

Cool!

=
=C2=A0
A lot of details can be discussed. There could be
Gtk::Container::add(std::initializer_list<Gtk::Widg= et*> widgets);
Gtk::Box::pack_start(std::initializer_list<Gtk::Widget*> widgets, PackOptions options);
Gtk::Box::pack_end(std::initializer_list<Gtk::Widget*> widgets, PackOptions options);
etc.
Indeed. I just didn'= t want to suggest too many variations at first, in case even the most basic= ones weren't an option. :D

=C2=A0
It would be even better with a list of references: std::initializer_list<Gtk::Widget&>. Is that possible, o= r would the compiler try to copy the widgets?

Containers of refer= ences aren't possible in C++. The closest thing to this, I guess, is std::reference_wrapper<Gtk= ::Widget> - i.e. a utility class that wraps a pointer and gives i= t reference-like semantics (plus a few extras).

This might (I dunno)= mean some extra boilerplate or compromise, but it would probably be worth = it to ensure none of the passed elements are nullptr. So, that's a good point. We might wan= t to guard against that. Alternatively, we could just tell users that passi= ng a nullptr is UB and trust them to do it right. I guess this is one to = debate.

Even then, ye= s, initializer_list = is still restricted to having implicitly const elements, so the reference_wrappers would be cop= ied, but again, since they too are just pointers really, that's fine. (= but IMO movable-from initia= lizer_lists are sorely needed for other cases, though)
--001a114b017c78078f054a61c10b-- From dboles.src@gmail.com Fri Mar 10 15:19:53 2017 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 smtp.gnome.org (Postfix) with ESMTP id 50BD776222 for ; Fri, 10 Mar 2017 15:19:53 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 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, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxFLsy-2X9zy for ; Fri, 10 Mar 2017 15:19:52 +0000 (UTC) Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com [209.85.215.54]) by smtp.gnome.org (Postfix) with ESMTPS id AE45E76202 for ; Fri, 10 Mar 2017 15:19:52 +0000 (UTC) Received: by mail-lf0-f54.google.com with SMTP id z15so20152536lfd.1 for ; Fri, 10 Mar 2017 07:19:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=apK4kLm3mg2cjkvrW8tzU+vQZbp/O/WDVqaHn5oEmUM=; b=PRjtyoxvnjElIw9kiH7Q+kXNwf3tJeEf6VAD/+dR+4auDMbWJkCmkBCX0PSvVpwywP aPoH7Jr22qEYjE9b/iJ2saRO2JADFd5xBb3w0EA2jlqSlXYgf+OM/uz2Yw+fwA/VQPej e5UqMQQnyRTQ5se7rjOUeIzG2wLagsTQu5euOQiUbpeTSEJfPiSRsYt5QCctzpi7t+ta Pv+TpV117TUxV/OuJ/HeqgBM7xLjVIitvR1+bEqn4J9ku5XHEcpbvaz8kgQRNWFI5daJ OwtSx9WfMEnV8TxXHZLcgz27pHiVSXiG79VcnflkKPfmvfT3Dto5QQmL3tCQbtk+M1iO 33fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc; bh=apK4kLm3mg2cjkvrW8tzU+vQZbp/O/WDVqaHn5oEmUM=; b=jxt8m5424otXY3B8lobxW0D3iIuA4WTzZrIG79OGQP81CA1+Mi0MA4Z2uXv/VlSN37 e/QjX0GxPN9xxeVEPo0g/srn4b2msjBa6ebSWmwUJ8cz8fERMejlMTHpdCV0ttGl6odx GiWgxBnvg5w1TlbSbcx6SI9VOwwSrYlYtTPHGatXssxGyRxCHGJxtrBPisG+J6KmVTmO tzrF7mqQEgJWhmwGgZ/ut65x7p3NfNkLxaZdfaLzDWy3GThPPKo5sdkr05QshsL4EoBr QbSwq+SsiwfasOrf0tmEsz+pPCwEKNr5v85kUjJgxwR1b/4Qcf/jwftA3/9kPS4fWSA/ uTiw== X-Gm-Message-State: AMke39mhaW18V0bRbYdGHOaRbYh8qWU5M9L8+eeVVZXVhCdvhR2+SEIatgvSlbnqX7i94UApdBh4GXcURMbopQ== X-Received: by 10.46.84.78 with SMTP id y14mr6053408ljd.63.1489159189739; Fri, 10 Mar 2017 07:19:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.18.222 with HTTP; Fri, 10 Mar 2017 07:19:49 -0800 (PST) In-Reply-To: References: <8d428e58-d877-5b32-4636-61cc3ca0fbcc@bredband.net> From: Daniel Boles Date: Fri, 10 Mar 2017 15:19:49 +0000 Message-ID: Subject: Re: Give multi-child containers a convenience Container::add(std::initializer_list) [and maybe ctor] ? Cc: gtkmm-list@gnome.org Content-Type: multipart/alternative; boundary=f403045fbc5884d386054a61e495 X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 15:19:53 -0000 --f403045fbc5884d386054a61e495 Content-Type: text/plain; charset=UTF-8 Another idea for the pile: struct GridAttachItem { Gtk::Widget& widget; int x; int y; int w; int h; }; void Grid::attach( std::initializer_list ); This illustrates another point, that the inability to have containers of references is subverted if the reference is part of a struct/class (since then there is a way to disambiguate by name, whether you want the element itself, or what it refers to) --f403045fbc5884d386054a61e495 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Another idea for the pile:
struct GridAttachItem {
<= /font>
=C2=A0 Gtk::Widget& widg= et;
=C2=A0 int x;
=C2=A0 int y;
= =C2=A0 int w;
=C2=A0 int h;
<= div>};

void Grid::attach( std::initializer_list<Grid= AttachItem> );
<= br>
This illustra= tes another point, that the inability to have containers of references is s= ubverted if the reference is part of a struct/class (since then there is a way to disambiguate by name, = whether you want the element itself, or what it refers to)
--f403045fbc5884d386054a61e495-- From kjell.ahlstedt@bredband.net Fri Mar 10 15:23:38 2017 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 smtp.gnome.org (Postfix) with ESMTP id 59B6476222 for ; Fri, 10 Mar 2017 15:23:38 +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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2wDMnRMzJ0t for ; Fri, 10 Mar 2017 15:23:37 +0000 (UTC) X-Greylist: delayed 1504 seconds by postgrey-1.34 at restaurant.gnome.org; Fri, 10 Mar 2017 15:23:36 UTC Received: from smtprelay-h21.telenor.se (smtprelay-h21.telenor.se [195.54.99.196]) by smtp.gnome.org (Postfix) with ESMTPS id AA34B76202 for ; Fri, 10 Mar 2017 15:23:36 +0000 (UTC) Received: from ipb5.telenor.se (ipb5.telenor.se [195.54.127.168]) by smtprelay-h21.telenor.se (Postfix) with ESMTP id 792BECA6A for ; Fri, 10 Mar 2017 15:58:28 +0100 (CET) X-SMTPAUTH-B2: [kjell.ahlstedt@bredband.net] X-SENDER-IP: [85.229.147.206] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2ChAgAevsJYAM6T5VUNUBsBAQEDAQEBCQEBAYRch2uYFB+QC1mGYoYiAoMBFAECAQEBAQEBAQ8BNIVlAgEDeRALBAEJLQtXBg0IAQG6U4MOK4o/AQEBAQYBAQEBAQEihk6CBQiBWYEJijkFiSuHeIsXggOhV0iSeDaBJDgqSYULgUuLDgEBAQ X-IPAS-Result: A2ChAgAevsJYAM6T5VUNUBsBAQEDAQEBCQEBAYRch2uYFB+QC1mGYoYiAoMBFAECAQEBAQEBAQ8BNIVlAgEDeRALBAEJLQtXBg0IAQG6U4MOK4o/AQEBAQYBAQEBAQEihk6CBQiBWYEJijkFiSuHeIsXggOhV0iSeDaBJDgqSYULgUuLDgEBAQ X-IronPort-AV: E=Sophos;i="5.36,141,1486422000"; d="scan'208,217";a="690840013" Received: from c-ce93e555.06-203-73746f44.cust.bredbandsbolaget.se (HELO [192.168.1.64]) ([85.229.147.206]) by ipb5.telenor.se with ESMTP; 10 Mar 2017 15:58:27 +0100 Subject: Re: Give multi-child containers a convenience Container::add(std::initializer_list) [and maybe ctor] ? To: Daniel Boles References: Cc: gtkmm-list@gnome.org From: Kjell Ahlstedt Message-ID: <8d428e58-d877-5b32-4636-61cc3ca0fbcc@bredband.net> Date: Fri, 10 Mar 2017 15:58:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E95C35535E78C0207131FE8B" X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 15:23:38 -0000 This is a multi-part message in MIME format. --------------E95C35535E78C0207131FE8B Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Den 2017-03-10 kl. 10:40, skrev Daniel Boles: > Assuming it's not been discounted already, it would be great if this > is the kind of overload of add(), and maybe also construction, that > could be added to gtkmm. > > Has this been considered and rejected anywhere already? If not, I can > add it as an RFE on Bugzilla. > I don't think it has been considered, and certainly not rejected. It's a good idea. A lot of details can be discussed. There could be Gtk::Container::add(std::initializer_list widgets); Gtk::Box::pack_start(std::initializer_list widgets, PackOptions options); Gtk::Box::pack_end(std::initializer_list widgets, PackOptions options); etc. It would be even better with a list of references: std::initializer_list. Is that possible, or would the compiler try to copy the widgets? --------------E95C35535E78C0207131FE8B Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Den 2017-03-10 kl. 10:40, skrev Daniel Boles:
Assuming it's not been discounted already, it would be great if this is the kind of overload of add(), and maybe also construction, that could be added to gtkmm.

Has this been considered and rejected anywhere already? If not, I can add it as an RFE on Bugzilla.

I don't think it has been considered, and certainly not rejected. It's a good idea.
A lot of details can be discussed. There could be
Gtk::Container::add(std::initializer_list<Gtk::Widget*> widgets);
Gtk::Box::pack_start(std::initializer_list<Gtk::Widget*> widgets, PackOptions options);
Gtk::Box::pack_end(std::initializer_list<Gtk::Widget*> widgets, PackOptions options);
etc.
It would be even better with a list of references: std::initializer_list<Gtk::Widget&>. Is that possible, or would the compiler try to copy the widgets?
--------------E95C35535E78C0207131FE8B-- From gtglus@gmail.com Sun Mar 12 12:28:46 2017 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 smtp.gnome.org (Postfix) with ESMTP id C1CF17622B for ; Sun, 12 Mar 2017 12:28:46 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MagooPYjiXCf for ; Sun, 12 Mar 2017 12:28:45 +0000 (UTC) Received: from mail-ua0-f179.google.com (mail-ua0-f179.google.com [209.85.217.179]) by smtp.gnome.org (Postfix) with ESMTPS id 91234760A9 for ; Sun, 12 Mar 2017 12:28:45 +0000 (UTC) Received: by mail-ua0-f179.google.com with SMTP id f54so135728012uaa.1 for ; Sun, 12 Mar 2017 05:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=PwMmO/sN80DbZ4cNpsArcDF7E58xVyu3gicogOna6HY=; b=LMe/Zd6nowiEJcBeUjNfZG9v46h4Bjy6EOuLaPB6c2DxW8wt/QPP1njSHghv8toCG0 2UoLCHCv97DVMwTO3HQze65t7q17wn1ttK8PBsOqBNWPHMPxpP9oRMd1i4WfDnZfyzMZ umkz0qIJA19GvWFlgiyHF3AgwTQgIUhekONKtSngRLh6YwGdlxLCwvAEIbJ9bvUCef08 H1gSOomuk5mj8CKZzFMq7fZMtBRX1zPGxEr9GKbaezMMst3kWMF6XpUy/J1dWjiOn/wH IJfQSAZd5/0HYV6QE1xhUyI8gi1Q72K7hNJ9ydtgAXi+YE5HaC7fI1XnDMdLhX6Z1GKa Oktg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=PwMmO/sN80DbZ4cNpsArcDF7E58xVyu3gicogOna6HY=; b=gE0x3/IERE06z5Skydo8DT/yMsN1JM+/E6zMeht8T44+FVrI+dmPVVfw3WHGKiiVUj F6HRTY+WBS6FMEYHXXVJdrTw7dQw47H7txMaojrdUf9tVK0x2Kohi2C953h3AVoccIrk tDAhMYGRQVTwBY5tmwTzKE0KVbqUolhLErWe8OEd3ZF3VuqfgoS1INX2OjLfXZOQ29vf j4JpcHJWKzPow+I6HFJ/lrCSPNohEZlCJ3KhDGPBYw3jfOP/a27CcNF5jYtqPI7/CMCw AcahSx+YRcIeZbuDq+8AOV+F5RvaZ8xP0SiPNq7jucvuJn1g5ptxmtA2bNxAY1L2bwfs 391w== X-Gm-Message-State: AMke39nAtazRWKR+egut8eK9iU250YlqK/yo00EGobs/sfHF3VgL0PTCc3gv1LykuI3jN3nFk/b8TI8OoLzZLg== X-Received: by 10.159.35.175 with SMTP id 44mr11766914uao.28.1489321723227; Sun, 12 Mar 2017 05:28:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.90.134 with HTTP; Sun, 12 Mar 2017 05:28:42 -0700 (PDT) From: Glus Xof Date: Sun, 12 Mar 2017 13:28:42 +0100 Message-ID: Subject: How to produce a 'New Line' in GtkTextView ? To: "gtkmm-list@gnome.org" Content-Type: multipart/alternative; boundary=94eb2c04036244f3af054a87bcb1 X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 12:28:46 -0000 --94eb2c04036244f3af054a87bcb1 Content-Type: text/plain; charset=UTF-8 Hi guys, Just in trouble trying to find why GtkTextView doesn't show a new line in this kind of code, Glib::RefPtr refTextBuffer = Gtk::TextBuffer::create(); refTextBuffer->insert_with_tag (refTextBuffer->end(), ".\n", refTag...); Notice that the 2nd parameter of "insert_with_tag" is ".\n"... so why "\n" doesn't produce a new line here (instead of writing ".\n") ? Glus --94eb2c04036244f3af054a87bcb1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi guys,

Just in trouble trying to find why Gt= kTextView doesn't show a new line in this kind of code,

Glib::Re= fPtr<Gtk::TextBuffer> refTextBuffer =3D Gtk::TextBuffer::create();refTextBuffer->insert_with_tag (refTextBuffer->end(), ".\n"= ;, refTag...);

Notice that the 2nd parameter of "insert_with_ta= g" is ".\n"... so why "\n" doesn't produce a n= ew line here (instead of writing ".\n") ?

Glus
--94eb2c04036244f3af054a87bcb1-- From dboles.src@gmail.com Sun Mar 12 14:57:54 2017 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 smtp.gnome.org (Postfix) with ESMTP id A19D97622B for ; Sun, 12 Mar 2017 14:57:54 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WuGpu1raOO_I for ; Sun, 12 Mar 2017 14:57:53 +0000 (UTC) Received: from mail-lf0-f45.google.com (mail-lf0-f45.google.com [209.85.215.45]) by smtp.gnome.org (Postfix) with ESMTPS id 1B18D760A9 for ; Sun, 12 Mar 2017 14:57:52 +0000 (UTC) Received: by mail-lf0-f45.google.com with SMTP id j90so55416591lfk.2 for ; Sun, 12 Mar 2017 07:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=/becZVxO04rHpgDNWv86yU/PtceNEM0yekwkhtjwLjM=; b=Cn1OK9LKOQij/jO5dNwMKKQ29jDPeqIpaBA/lAo1EUmoxwOucIGULh3D8Y1IPBCQUl mXGlqoq4AV5r17HrmMUXtQCymUimrPZpGyYYUvntKu1XMLBoNjrDEe6AQxRYVGlYanRM fjbdm7pTMmgBl9RoxBZknmyy+ByHnaclglvfRIbiDwLm0FcGGcs/rg9b2aN+rUbYK5wS 4R2jK7Iz7gPkGqeSMAjfJAN/c4EVDG25t6eqqCP6U8vNsh8kFjEWw71MkxEL/51O71F4 A1d/L98nKTkS4PmwVvNLM52UcUkHCXxyk8h5bnA+XcRrM5qv3dM7sHMSBbeQKuyBUXj1 R79w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=/becZVxO04rHpgDNWv86yU/PtceNEM0yekwkhtjwLjM=; b=MkPFgoOYDbfMmU24mnJOUr10YkudsVzXEpt4c7/qY9qchJhevP0ieSrniWlNOAz59i GZq0U4lJkC/sAa6CdIh3GN0/czyc3YSzxpOIyO6av22pJTUx17QrP6T+pvKEZxhiWobP T6HDb4j0PQhA+Avmg8JIsycO1IjtcF/V/idzOko1bL5pEr3gNGLXsiWkgpTNayP7jYhe K0NputthmTtaiRlWvU5mBl7f14kqfqAZ12Or/2wJzi0HbjzIxVoxhr3JiQ5X/pWBeeYb KohZI51rsKR0QsbYYcBWnlLnKGax/g1808u6XCgM58Ngu3k9nJxrmBLDLGqvGvzsCbIl +M6g== X-Gm-Message-State: AMke39n0TnEopbxYp5N9Vgh1oOnibPDwRg13CvEWvW/rSmm+GUbt2flx1YUdyjEQ9cvqt/CRd4eFMg4PY4B+FQ== X-Received: by 10.46.76.2 with SMTP id z2mr8677722lja.59.1489330669854; Sun, 12 Mar 2017 07:57:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.18.222 with HTTP; Sun, 12 Mar 2017 07:57:49 -0700 (PDT) In-Reply-To: References: From: Daniel Boles Date: Sun, 12 Mar 2017 14:57:49 +0000 Message-ID: Subject: Re: How to produce a 'New Line' in GtkTextView ? To: gtkmm-list@gnome.org Content-Type: multipart/alternative; boundary=f403045ea6ce87ad2d054a89d1ea X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 14:57:55 -0000 --f403045ea6ce87ad2d054a89d1ea Content-Type: text/plain; charset=UTF-8 I suspect this not being parsed as an escape sequence for a newline is to do to with Glib::ustring (and perhaps the underlying C GLib methods) using Unicode, and not parsing that sequence as an escape in a Unicode context. This speculation is mostly based on http://stackoverflow.com/questions/22895212/display-string-with-newline-characters-in-gtktextview Also fwiw, I found some indications that C++ raw string literals would work, if you type actual line breaks in them. I don't know whether this is the ideal solution, either on a language level or for you personally, but seems worth mentioning. --f403045ea6ce87ad2d054a89d1ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I suspect this not being parsed= as an escape sequence for a newline is to do to with Glib::ustring (and pe= rhaps the underlying C GLib methods) using Unicode, and not parsing that se= quence as an escape in a Unicode context. This speculation is mostly based = on=C2=A0http://stackoverflow.com/questio= ns/22895212/display-string-with-newline-characters-in-gtktextview

Also fw= iw, I found some indications that C++ raw string literals would work, if yo= u type actual line breaks in them. I don't know whether this is the ide= al solution, either on a language level or for you personally, but seems wo= rth mentioning.

--f403045ea6ce87ad2d054a89d1ea-- From kjell.ahlstedt@bredband.net Mon Mar 13 09:25:38 2017 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 smtp.gnome.org (Postfix) with ESMTP id 15EA8762F9 for ; Mon, 13 Mar 2017 09:25:38 +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 smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hGsY3u7CyJA for ; Mon, 13 Mar 2017 09:25:36 +0000 (UTC) Received: from smtprelay-b11.telenor.se (smtprelay-b11.telenor.se [62.127.194.20]) by smtp.gnome.org (Postfix) with ESMTPS id 6F1BB76214 for ; Mon, 13 Mar 2017 09:25:35 +0000 (UTC) Received: from ipb3.telenor.se (ipb3.telenor.se [195.54.127.166]) by smtprelay-b11.telenor.se (Postfix) with ESMTP id A2E36EA7A4 for ; Mon, 13 Mar 2017 10:25:32 +0100 (CET) X-SMTPAUTH-B2: [kjell.ahlstedt@bredband.net] X-SENDER-IP: [85.229.147.206] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DLAgAHZcZYAM6T5VUNUBwBAQQBAQoBAYQyKmCfPpAOhS2CDiyFdgKDChYBAgEBAQEBAQEPATSFZQIBAydSEAsEAQk4VwYNCAEBigquQIJUOiuKKwEBAQEBBQEBAQEBAQEcBYIxhB2CBQiCYoJ2h0MFnEGCA4Rzhk2EeIIRjxKTQyUBgTU5KocjdAGJUgEBAQ X-IPAS-Result: A2DLAgAHZcZYAM6T5VUNUBwBAQQBAQoBAYQyKmCfPpAOhS2CDiyFdgKDChYBAgEBAQEBAQEPATSFZQIBAydSEAsEAQk4VwYNCAEBigquQIJUOiuKKwEBAQEBBQEBAQEBAQEcBYIxhB2CBQiCYoJ2h0MFnEGCA4Rzhk2EeIIRjxKTQyUBgTU5KocjdAGJUgEBAQ X-IronPort-AV: E=Sophos;i="5.36,158,1486422000"; d="scan'208,217";a="1597057321" Received: from c-ce93e555.06-203-73746f44.cust.bredbandsbolaget.se (HELO [192.168.1.64]) ([85.229.147.206]) by ipb3.telenor.se with ESMTP; 13 Mar 2017 10:23:30 +0100 Subject: Re: How to produce a 'New Line' in GtkTextView ? To: Glus Xof References: Cc: "gtkmm-list@gnome.org" From: Kjell Ahlstedt Message-ID: <06260606-f554-0d87-41e0-df4ab0ce6f8e@bredband.net> Date: Mon, 13 Mar 2017 10:23:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5F89FBA0EB0BAA2716AFC24D" X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 09:25:38 -0000 This is a multi-part message in MIME format. --------------5F89FBA0EB0BAA2716AFC24D Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Den 2017-03-12 kl. 13:28, skrev Glus Xof: > Hi guys, > > Just in trouble trying to find why GtkTextView doesn't show a new line > in this kind of code, > > Glib::RefPtr refTextBuffer = Gtk::TextBuffer::create(); > refTextBuffer->insert_with_tag (refTextBuffer->end(), ".\n", refTag...); > > Notice that the 2nd parameter of "insert_with_tag" is ".\n"... so why > "\n" doesn't produce a new line here (instead of writing ".\n") ? > > Glus > This is strange. Gtkmm's demo program, https://git.gnome.org/browse/gtkmm/tree/demos/gtk-demo/example_textview.cc, contains many lines like iter = refBuffer->insert_with_tag(iter, "Blah blah\n", "char_wrap"); In the Gtk::TextView such lines end with a new line, not with "\n". --------------5F89FBA0EB0BAA2716AFC24D Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Den 2017-03-12 kl. 13:28, skrev Glus Xof:
Hi guys,

Just in trouble trying to find why GtkTextView doesn't show a new line in this kind of code,

Glib::RefPtr<Gtk::TextBuffer> refTextBuffer = Gtk::TextBuffer::create();
refTextBuffer->insert_with_tag (refTextBuffer->end(), ".\n", refTag...);

Notice that the 2nd parameter of "insert_with_tag" is ".\n"... so why "\n" doesn't produce a new line here (instead of writing ".\n") ?

Glus

This is strange. Gtkmm's demo program, https://git.gnome.org/browse/gtkmm/tree/demos/gtk-demo/example_textview.cc, contains many lines like
iter = refBuffer->insert_with_tag(iter, "Blah blah\n", "char_wrap");
In the Gtk::TextView such lines end with a new line, not with "\n".
--------------5F89FBA0EB0BAA2716AFC24D-- From gtglus@gmail.com Mon Mar 13 10:23:57 2017 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 smtp.gnome.org (Postfix) with ESMTP id 5206E762C3 for ; Mon, 13 Mar 2017 10:23:57 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2keaQa_6fkjK for ; Mon, 13 Mar 2017 10:23:56 +0000 (UTC) Received: from mail-ua0-f169.google.com (mail-ua0-f169.google.com [209.85.217.169]) by smtp.gnome.org (Postfix) with ESMTPS id 2727B76214 for ; Mon, 13 Mar 2017 10:23:56 +0000 (UTC) Received: by mail-ua0-f169.google.com with SMTP id u30so151023174uau.0 for ; Mon, 13 Mar 2017 03:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HQ0bl4aKz2z/l10iCgiSqysiblZHD8nT8/ePLwoTBSE=; b=RcYCgfjJDpYcuiUtc8xk53w61mQBDSWcwSFBbj5itA4cnst1uLsw5UQony9o5n3QcE CQyIXXkLKZA4BZ1+uGZYHY/lIK7OWnv0lx7tAVUkHxTnfh3YRPFxFPMIXlUMURqBYjrY 3DsHSIw9bRylIp48aYLjevOXK6BQpA/e4+m3dv/WPSG0dQOD6sUiR4rS3n2NrE3Oa3wu 6tN0GRr3lfgdrj9hiIOIv04d0XpqQqr0BdPcpMRZtm4eFlBaj44tNhx5b/Ta3v36uL02 9xIcZzA9Eug/KNm07rrevn5ScSEyFEZyek485Gt+CFs7zUI+VzlByir6nenT6uid82VX ypLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HQ0bl4aKz2z/l10iCgiSqysiblZHD8nT8/ePLwoTBSE=; b=gSnSQ/xdPH8Ko87YZ2tvwEoInz7WRqThiAhOsSmYjy7xvQNXu391xXl2Xl8vXKAzZA 1rP51U4ewDvFX4iAr0TKo+PrOzYESVU9dPe/ZJz5VmDgywQLhjLs3Bjgw1IGWn/FDbID XKej/cODw2yLfstxYW/mik8p37sN0f2IIT2UEuxMeIlrYsKAy1goOb0PkI+bcvk2FkIF aukJgXX7dkv0GOy/mPHR5OxgPUXR7Z/3aJi4jVzkyGwMRvsWCusHP5XEvfhdZqYUrKhl ou+yNSVxg3sCh550tED2Lf9Nd2BwsEoo4Gaq/ULzM54/jlBTANv/CZXJSCKXQ3SzahmK jTGA== X-Gm-Message-State: AMke39kKqXstcsmHe3p5z06Ley0VQtxwmO4SzcujMy4esNeP+LY60tNh9IxZ7lv8NELxHWLBqnV5lCso+pmGnA== X-Received: by 10.176.6.170 with SMTP id g39mr16017000uag.34.1489400633983; Mon, 13 Mar 2017 03:23:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.90.134 with HTTP; Mon, 13 Mar 2017 03:23:53 -0700 (PDT) In-Reply-To: <06260606-f554-0d87-41e0-df4ab0ce6f8e@bredband.net> References: <06260606-f554-0d87-41e0-df4ab0ce6f8e@bredband.net> From: Glus Xof Date: Mon, 13 Mar 2017 11:23:53 +0100 Message-ID: Subject: Re: How to produce a 'New Line' in GtkTextView ? To: Kjell Ahlstedt Cc: "gtkmm-list@gnome.org" Content-Type: multipart/alternative; boundary=94eb2c0458a8b788d6054a9a1bd2 X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 10:23:57 -0000 --94eb2c0458a8b788d6054a9a1bd2 Content-Type: text/plain; charset=UTF-8 Thanks Mr. Boles & Mr. Ahlstedt, Sorry and thanks for the patience... Indeed (and just for simplifying) what I put as 2nd parameter was a Glib::ustring object. Now, after some additional conversions (of kind of "search & replace") before inserting... the problem seems solved. Glus 2017-03-13 10:23 GMT+01:00 Kjell Ahlstedt : > Den 2017-03-12 kl. 13:28, skrev Glus Xof: > > Hi guys, > > Just in trouble trying to find why GtkTextView doesn't show a new line in > this kind of code, > > Glib::RefPtr refTextBuffer = Gtk::TextBuffer::create(); > refTextBuffer->insert_with_tag (refTextBuffer->end(), ".\n", refTag...); > > Notice that the 2nd parameter of "insert_with_tag" is ".\n"... so why "\n" > doesn't produce a new line here (instead of writing ".\n") ? > > Glus > > This is strange. Gtkmm's demo program, https://git.gnome.org/browse/ > gtkmm/tree/demos/gtk-demo/example_textview.cc, contains many lines like > > iter = refBuffer->insert_with_tag(iter, "Blah blah\n", "char_wrap"); > > In the Gtk::TextView such lines end with a new line, not with "\n". > --94eb2c0458a8b788d6054a9a1bd2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Mr. Boles & Mr. Ahlstedt,

Sorry and thanks for the patience... Indeed (and just for simplifying) wh= at I put as 2nd parameter was a Glib::ustring object. Now, after some addit= ional conversions (of kind of "search & replace") before inse= rting... the problem seems solved.

Glus


2017-03-13 10:2= 3 GMT+01:00 Kjell Ahlstedt <kjell.ahlstedt@bredband.net><= /span>:
=20 =20 =20
Den 2017-03-12 kl. 13:28, skrev Glus Xof:
Hi guys,

Just in trouble trying to find why GtkTextView doesn't show a new line in this kind of code,

Glib::RefPtr<Gtk::TextBuffer> refTextBuffer =3D Gtk::TextBuffer::create();
refTextBuffer->insert_with_tag (refTextBuffer->end(), ".\n", refTag...);

Notice that the 2nd parameter of "insert_with_tag" is &= quot;.\n"... so why "\n" doesn't produce a new line here (instea= d of writing ".\n") ?

Glus

This is strange. Gtkmm's demo program, https://git.gnome.org/browse/gtkmm/tree/demos/gtk-demo/e= xample_textview.cc, contains many lines like
iter =3D refBuffer->insert_with_tag(iter, "Bla= h blah\n", "char_wrap");
In the Gtk::TextView such lines end with a new line, not with "\n&= quot;.

--94eb2c0458a8b788d6054a9a1bd2-- From mike.fleetwood@googlemail.com Mon Mar 13 20:56:06 2017 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 smtp.gnome.org (Postfix) with ESMTP id D558A764B3 for ; Mon, 13 Mar 2017 20:56:06 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-CVB_NE1wQu for ; Mon, 13 Mar 2017 20:56:02 +0000 (UTC) Received: from mail-ot0-f175.google.com (mail-ot0-f175.google.com [74.125.82.175]) by smtp.gnome.org (Postfix) with ESMTPS id BA0F87624D for ; Mon, 13 Mar 2017 20:56:02 +0000 (UTC) Received: by mail-ot0-f175.google.com with SMTP id 19so121451895oti.0 for ; Mon, 13 Mar 2017 13:56:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=JwFVAgoAO4ynHsX3Eu4tDLaD9xGZAfVaXD5J5eswcGE=; b=s4nRUqofrEQdI+nk+DQUuVLgShT1BdQVEjir/4qXdZ/o2TrzN/Bbi/NlNqDXJL+FMR 8n20Cl+6aFxaUCTAWfI59d7niQgfhNhpaCkjxFKkaaAsf5Wu+Hu3Sz4oQYJA7j7hJJCi dG4hWtglSmMkstv3hoC57gC8UIeBXUGjJCA59Ns4m3l5xtVHB5ValKwaivM2b2woKIxH joYnzrEP7T8P3FECwnhngdSIpPrDGInRzCNOwNa5I1pm3NJFzd0d2a4PNlddLcCrqpkQ UG6JohuleLzMRDKY71+KB62N7gPezq80UfSnMAEwFR524ZyyjdsN77iRlKkz/Rm9j59y RX+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JwFVAgoAO4ynHsX3Eu4tDLaD9xGZAfVaXD5J5eswcGE=; b=IItjhnD3HmUA12b/4+wPJGZCpI4B2h37ybI+d/IP95iSoVJLa6QVREiz8zmbPNdCcT 9K6yScyQXkZf6J2FxIiZaxWk0KqN2uiaP2pHg9AeiZMQPnZlS6gBtt0ERxsUNR4HpIDD 4pScbtZ3lanP6KRrFXbREw0BR4XcRmoZg+mJIcq+SEJExkqpn2Y009QTDDBbkoUJRK7x xH46bQ6XPrz5qDNMtxbJic6ODa5jsIP6rMKynHX2o5Ca9VLchegoROaQG14gAoT7HeLN raswGGT20RELbkdleBX8QnB+xzczIUiVy+7RkNhMYmZfhuVTqgFiXgxJrJBF66hagl8R /5Jw== X-Gm-Message-State: AFeK/H2/qyVRHcvkgS8dLzGg+Boj5bCyc56s7tXHcDUDn/RXpNLY/JTHpTSEg2AUQ0T2U2PPnwb5q5amqXS9kw== X-Received: by 10.157.45.19 with SMTP id v19mr17375358ota.102.1489438560685; Mon, 13 Mar 2017 13:56:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.141 with HTTP; Mon, 13 Mar 2017 13:56:00 -0700 (PDT) From: Mike Fleetwood Date: Mon, 13 Mar 2017 20:56:00 +0000 Message-ID: Subject: Should an iterator be valid after appending to a Glib::ustring? To: gtkmm list Content-Type: text/plain; charset=UTF-8 X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 20:56:06 -0000 Are iterators into a Glib::ustring still valid after the string is modified? Specifically appended to or modified at or beyond where the iterator points. Especially if appending to the string causes the underlying bytes to be relocated to a larger allocation. I didn't obviously see this mentioned in the documentation. I though it might be valid because the iterator appears to be implemented using a pointer difference type. However the following small test program fails with: ** ERROR:test.cc:28:int main(): assertion failed: (linestart <= cursor) Aborted Thanks, Mike --8<-- test.cc --8<-- #include #include int main() { Glib::ustring buf; Glib::ustring::iterator linestart = buf.begin(); Glib::ustring::iterator cursor = buf.begin(); gunichar uc = 'u'; buf.append(1, uc); cursor = buf.end(); g_assert(buf.begin() <= linestart); g_assert(linestart <= cursor); g_assert(cursor <= buf.end()); return 0; } From murrayc@murrayc.com Mon Mar 13 21:44:54 2017 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 smtp.gnome.org (Postfix) with ESMTP id B5E54764B5 for ; Mon, 13 Mar 2017 21:44:54 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RINuBXMbi-I6 for ; Mon, 13 Mar 2017 21:44:54 +0000 (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by smtp.gnome.org (Postfix) with ESMTPS id 0AC387648E for ; Mon, 13 Mar 2017 21:44:53 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 2CD8120A59; Mon, 13 Mar 2017 17:44:52 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 13 Mar 2017 17:44:52 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=murrayc.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=Mxgk2JqNDsXyNw1 +GTT+FA8QT2Q=; b=CKTve1EnqAbZC+WeZ/Vu8SYSJGoiv7CiyQfceE2DLIWQOD5 TUQqQtz5/4VZrNJJPMMNV2R4he5OXDA3cgx1hg3d5QEhb/eK7oZQWh9qEl1ps1u9 fSYIDH6SRCG4lsrv0IiYWjvLtdjhXUVUat0vAdZvyjRlI3jgMK4g3VxFLBMI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=Mxgk2JqNDsXyNw1+GTT+FA8QT2Q=; b=WDkoSdSjsOvXbb5Aoz60 j9jsoCOhOejsS8+iS1Cwggwyd/xkXnNNNN2u5LPMD2p6TVxpW+Nvk12xAUUhqicL tnaFZWFvMCFw6RdcyzrBqyCcVDqtjuIFdjOqHHP2zoPDg+VtTeE+Y0A9Ybivy3gu boyu51o1cnBaK8N1OX5kXmg= X-ME-Sender: X-Sasl-enc: Dn5Cv40J3BNO15LwHtLDLVRHnQJ8cMw9bBAfYdjed56j 1489441491 Received: from murrayc-ThinkPad-X220 (aftr-185-17-205-92.dynamic.mnet-online.de [185.17.205.92]) by mail.messagingengine.com (Postfix) with ESMTPA id 8144E7E033; Mon, 13 Mar 2017 17:44:51 -0400 (EDT) Message-ID: <1489441489.30069.1.camel@murrayc.com> Subject: Re: Glibmm-2.52: Shall StreamIOChannel and IOChannel vfuncs be undeprecated? From: Murray Cumming To: Kjell Ahlstedt , "gtkmm-list@gnome.org" Date: Mon, 13 Mar 2017 22:44:49 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.3-0ubuntu0.1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 21:44:54 -0000 On Fri, 2017-03-03 at 13:46 +0100, Kjell Ahlstedt wrote: > This concerns glibmm-2.52, the future API/ABI-breaking release. > The whole StreamIOChannel class is deprecated. So are all virtual > functions in IOChannel. A now removed comment explained why: > This feature of being able to implement a custom Glib::IOChannel is > deprecated in glibmm 2.2.  The vfunc interface has not yet stabilized > enough to allow that -- the C++ wrapper went in by pure accident. > Is "not yet stabilized enough" still true? The latest ABI change in > the vfuncs was made in February 2002. I can certainly remove > StreamIOChannel and the vfuncs in glibmm 2.52, but wouldn't it be at > least as good to keep them and undeprecate them? IMO the comment > about not yet stabilized vfuncs is obsolete. Thanks for investigating. Would it be useful? Could we even create a test case showing how to use this feature? -- Murray Cumming murrayc@murrayc.com www.murrayc.com From dboles.src@gmail.com Mon Mar 13 21:46:06 2017 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 smtp.gnome.org (Postfix) with ESMTP id BD8CD7648E for ; Mon, 13 Mar 2017 21:46:06 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kg4gkKSrSPf2 for ; Mon, 13 Mar 2017 21:46:05 +0000 (UTC) Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com [209.85.215.48]) by smtp.gnome.org (Postfix) with ESMTPS id 8DC93764B5 for ; Mon, 13 Mar 2017 21:46:05 +0000 (UTC) Received: by mail-lf0-f48.google.com with SMTP id z15so47227497lfd.1 for ; Mon, 13 Mar 2017 14:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=54hgiNwg9bgHjyBHmkphnEtIAQ6mPzorRpyY6SfrozU=; b=dcBQYNWzXypKJ5pMlQXWa5Y/KJw28/dagr2RuFvekuFv/FvmwmynW7tFcFM+QUU/FS WEW/TkcXpxVgrVQzTaHbdFjefTShZgmtRoHxmb5YsW59pg4ix08s0bYiynPWzKcVYssy Qq94qDbyYXV5n2Wld/fuEcyX5BEedsfYZ5ttUm2DTF3r5P/A//HiaJhRGQ/dG1B1OC6m 8/txnwxybLJaXqofJBE4UIOMlxjyXIdocPswKMLOWCOMZFq+dxyMkhJtkTjX2ef4eqZO pld4Put7FN7Vi/SbGH+j5hl0rynIZoPVP7K9DF2gb9X802pcSe5BQB2eAsZIto3ALMDp 1WLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=54hgiNwg9bgHjyBHmkphnEtIAQ6mPzorRpyY6SfrozU=; b=oILuj/MzeopkA9A0RWYzB8rYZOoEKrxxqh3vVSekEgBDcLaRtUCKfS4bgaPhnltEeQ P3ImnTg8KmRKm+ch/ljJcnWeYjFcQGzafBn11wIfIubyExZsnWI5ss1/cp5K9WD7vDkL yKg1FXRzqJrGVOeoJ9dlhz6SUa6bNl5SiQ/ZPVmt0MTptJPNsJa+nyuvb8tbnrz20UDa 81kz7Bl9mwomYPLOzI0inj7cX//u5fuqiQwxW/huxUMLor987v0rIjv9EBzUXL+4nBpU c0yoXUzPf2/YANwOkotp+0apuTIS2jTgcutqbEz3Br8Jx2Bp3oyyC1Tc1iF2KZxgIyDa 6IKw== X-Gm-Message-State: AMke39kIZF0oPj28SqAiFcAPCntUoFE3ABI6saVC8HsomfHpnKyk9Y5K09Mvt3oXHJXVWkkW/ESTvZGQxxoblA== X-Received: by 10.25.198.146 with SMTP id w140mr7984541lff.145.1489441562401; Mon, 13 Mar 2017 14:46:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.18.222 with HTTP; Mon, 13 Mar 2017 14:46:01 -0700 (PDT) In-Reply-To: References: From: Daniel Boles Date: Mon, 13 Mar 2017 21:46:01 +0000 Message-ID: Subject: Re: Should an iterator be valid after appending to a Glib::ustring? To: gtkmm-list@gnome.org Content-Type: multipart/alternative; boundary=94eb2c1a08e03da638054aa3a3d8 X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 21:46:06 -0000 --94eb2c1a08e03da638054aa3a3d8 Content-Type: text/plain; charset=UTF-8 It is a general concept of C++ that iterators are invalidated by various modifying operations, and the API should usually specify which operations do and do not invalidate iterators. In this case, if ustring itself does not stipulate, you should check the Standard C++ documentation for std::string - as ustring is mostly a thin wrapper around that giving Unicode semantics. However, Specifically appended to or modified at or beyond where the > iterator points. Especially if appending to the string causes the > underlying bytes to be relocated to a larger allocation. I didn't > obviously see this mentioned in the documentation. > This is a pretty obvious "no". If the operation can cause a reallocation, that's a very strong hint, so if the container does not explicitly state that it does NOT invalidate iterators.... then it does. Again, ustring will follow std::string here, where I know this not to be valid. I though it might be valid because the iterator appears to be > implemented using a pointer difference type. However the following > small test program fails with: Well, it's a difference _from a particular base address_, isn't it? If reallocation occurs, that address changes, so the iterator now offsets into memory that no longer belongs to its instance. --94eb2c1a08e03da638054aa3a3d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It is a general concept of C++ that iterators are inv= alidated by various modifying operations, and the API should usually specif= y which operations do and do not invalidate iterators.


In = this case, if ustring itself does not stipulate, you should check the Stand= ard C++ documentation for std::string - as ustring is mostly a thin wrapper= around that giving Unicode semantics. However,

Specifically appended to or modified at = or beyond where the
iterator points.=C2=A0 Especially if appending to the string causes the
underlying bytes to be relocated to a larger allocation.=C2=A0 I didn't=
obviously see this mentioned in the documentation.

This= is a pretty obvious "no". If the operation can cause a reallocat= ion, that's a very strong hint, so if the container does not explicitly= state that it does NOT invalidate iterators.... then it does. Again, ustri= ng will follow std::string here, where I know this not to be valid.

=

I though it might be valid because the iterator appears to be
implemented using a pointer difference type.=C2=A0 However the following small test program fails with:

Well, it'= ;s a difference _from a particular base address_, isn't it? If realloca= tion occurs, that address changes, so the iterator now offsets into memory = that no longer belongs to its instance.

--94eb2c1a08e03da638054aa3a3d8-- From dboles.src@gmail.com Mon Mar 13 21:50:38 2017 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 smtp.gnome.org (Postfix) with ESMTP id AEB9C7648E for ; Mon, 13 Mar 2017 21:50:38 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iiH604-qHMb for ; Mon, 13 Mar 2017 21:50:37 +0000 (UTC) Received: from mail-lf0-f50.google.com (mail-lf0-f50.google.com [209.85.215.50]) by smtp.gnome.org (Postfix) with ESMTPS id 3FFD57624D for ; Mon, 13 Mar 2017 21:50:36 +0000 (UTC) Received: by mail-lf0-f50.google.com with SMTP id z15so47261183lfd.1 for ; Mon, 13 Mar 2017 14:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=lgpg+7RplVOKPuftS570xaZzFw0fsm/NfNYzY3uhBxw=; b=GQkDcuRTfnxIAvQ5Bv1FOHF0E+3yHEtntfswdTJdKmCsKgOSo/1y5fYf5MaV5ylVOe V20dPCIBj1AEE3z8OrDrDfejmToTpgxHRJsZjBHfgeO97kN31RezUNBTGy8g9dmXTv49 jU2fTrLXHyLSUoKWKNrSzcpHLZCFj/V/hrQwQ5tkhPVFOC9n/sf9u+2GsVB3bLc+1nCf mL76JzMSZzTzdXJGh7SzUzR4Z5P6cKfkaz201e2NtOu0MOedK67Ur041Aw1hmPqjcJU0 3g69ZahhX20MsoV0V947XVkxAgkW0ers2WWyEGgnuRjjddXtXm6vGNjrHhAP7F2beJ5Z LBww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=lgpg+7RplVOKPuftS570xaZzFw0fsm/NfNYzY3uhBxw=; b=AdVGQdNSV7+yDBu17L8fNy3PbVzsFDwgefjZrMDXPcQlCUoSGTN/v/WXbmnNfUtNGd vLwbwYYyIBwKFxlE6pO9UMCFNB/jOkkzfDA8utsxD1FreU9UOooQMqSYYScJGjY6Zthn lCqt2Jb8ogtM/8C3LQFvY+x3T8gtlhsOkUYXn8a44X9wsEXjJmYbjVSzH/odbXCvMnZv lLKSU3iAmSgJ0uuTTsvzAFVA9BEBYK+60t8C3O+krsW9Zh2tbf2YuI+qr1E6JKoLBSdJ dBkC/v6YIztlrn8IAqQIJakn205vJykEhuBszs/L350VwnRPN24F1jIuScKeAC046ipH hcEQ== X-Gm-Message-State: AMke39nvnx5SzSmnZdtOFqV0mIdt5QSNbZCErnjWZHRCTIMAcSIff/bH8EZXedGZZxcCwDhshWtLMfq9zy0CEg== X-Received: by 10.46.76.2 with SMTP id z2mr10709154lja.59.1489441834107; Mon, 13 Mar 2017 14:50:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.18.222 with HTTP; Mon, 13 Mar 2017 14:50:33 -0700 (PDT) In-Reply-To: References: From: Daniel Boles Date: Mon, 13 Mar 2017 21:50:33 +0000 Message-ID: Subject: Re: Should an iterator be valid after appending to a Glib::ustring? To: gtkmm-list@gnome.org Content-Type: multipart/alternative; boundary=f403045ea6ce6f8b24054aa3b321 X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 21:50:38 -0000 --f403045ea6ce6f8b24054aa3b321 Content-Type: text/plain; charset=UTF-8 On 13 March 2017 at 21:46, Daniel Boles wrote: > This is a pretty obvious "no". If the operation can cause a reallocation, > that's a very strong hint, so if the container does not explicitly state > that it does NOT invalidate iterators.... then it does > I really meant 'increase the capacity', not 'reallocation', if we use 'reallocation' in the sense of moving existing elements, not just allocating other memory for new ones. So reallocation in this sense should always invalidate iterators. And since ustring (and std::string) is a random-access container, it must have contiguous memory, so any increase in capacity must cause a reallocation. So, any insert/append or anything else that adds elements. but there's a point: if you had previously reserve()d enough capacity, beyond the current size, for the insert point and length, then as long as you stay within the capacity you had, your iterators should remain valid, as reallocation is guaranteed not to occur in such cases. --f403045ea6ce6f8b24054aa3b321 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 3 March 2017 at 21:46, Daniel Boles <dboles.src@gmail.com> wrote:
This is a = pretty obvious "no". If the operation can cause a reallocation, t= hat's a very strong hint, so if the container does not explicitly state= that it does NOT invalidate iterators.... then it does

I really meant 'increase the capacity'= , not 'reallocation', if we use 'reallocation' in the sense= of moving existing elements, not just allocating other memory for new ones= . So reallocation in this sense should always invalidate iterators. And sin= ce ustring (and std::string) is a random-access container, it must have con= tiguous memory, so any increase in capacity must cause a reallocation. So, = any insert/append or anything else that adds elements.

bu= t there's a point: if you had previously reserve()d enough capacity, be= yond the current size, for the insert point and length, then as long as you= stay within the capacity you had, your iterators should remain valid, as r= eallocation is guaranteed not to occur in such cases.

--f403045ea6ce6f8b24054aa3b321-- From piecuch@protonmail.com Tue Mar 14 14:29:10 2017 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 smtp.gnome.org (Postfix) with ESMTP id 43A7F7622C for ; Tue, 14 Mar 2017 14:29:10 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 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, MIME_BASE64_BLANKS=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaBKq-5c7BlE for ; Tue, 14 Mar 2017 14:29:08 +0000 (UTC) Received: from mail3.protonmail.ch (mail3.protonmail.ch [185.70.40.25]) by smtp.gnome.org (Postfix) with ESMTPS id 6734E76209 for ; Tue, 14 Mar 2017 14:29:08 +0000 (UTC) Date: Tue, 14 Mar 2017 10:29:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1489501744; bh=aJLtarmGjbujX6BTVuYxNOLxeIQOVQijkTFRXTXJCvg=; h=From:Cc:Reply-To:Subject:In-Reply-To:References:Feedback-ID:From; b=L63WOB83L1b4wU/CgV8SYcBKi+uuADSaddcD4WnwW70D1ZROhAOggAZ2BJz7/BUg3 XkYMT/VzKIxiSwuwWrAXNYBEJNyr/fJzm+5aib1iCq3yg3aY/gkqaMJD974cu6/5TU k2Q7UuhDU95/oNK/3V2Gp6rrI9k9hQyc31yAGw0o= From: Krzysztof Piecuch Cc: gtkmm-list@gnome.org Reply-To: Krzysztof Piecuch Subject: Re: Should an iterator be valid after appending to a Glib::ustring? Message-ID: <9fajqk-U627HPuyWw6pPgvNcWn2zp-lJ6cabYtxWl2EimXHQSJM6pu0muE22w5r8Vx0ThteLpKsBCk5hP5yXWeGBEzBmmxQH1r7hapFtzKM=@protonmail.com> In-Reply-To: References: Feedback-ID: krphKiiPlx_XKIryTSpdJ_XtBwogkHXWA-Us-PsTeaBSrzOTAKWxwbFkseT4Z85b_7PMRvSnq3Ah7f9INXrOMw==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_4a3adb53e040e6b1ac42d21c2e985a41" X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 14:29:10 -0000 This is a multi-part message in MIME format. --b1_4a3adb53e040e6b1ac42d21c2e985a41 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 V2hhdCBhYm91dCB1c3RyaW5nLmVuZCgpIGl0ZXJhdG9yPyBJIHRoaW5rIGl0J3Mgb2J2aW91cyB0 aGF0IGl0J3MgaW52YWxpZGF0ZWQgZWFjaCB0aW1lIHdlIGNoYW5nZSB0aGUgc3RyaW5nJ3MgbGVu Z3RoICh1bmxlc3MgaXQncyBkb25lIGluIHNvbWUgKnZlcnkgY2xldmVyKiB3YXkpLgpJdCdzIGEg dGhpbmcgbm8gcmVzZXJ2ZSgpLWF0aW9uIGNhbiBoZWxwLgoKLS0tLS0tLS0gT3JpZ2luYWwgTWVz c2FnZSAtLS0tLS0tLQoKU3ViamVjdDogUmU6IFNob3VsZCBhbiBpdGVyYXRvciBiZSB2YWxpZCBh ZnRlciBhcHBlbmRpbmcgdG8gYSBHbGliOjp1c3RyaW5nPwpMb2NhbCBUaW1lOiAxMyBtYXJjYSAy MDE3IDEwOjUwIFBNClVUQyBUaW1lOiAxMyBtYXJjYSAyMDE3IDIxOjUwCkZyb206IGRib2xlcy5z cmNAZ21haWwuY29tClRvOiBndGttbS1saXN0QGdub21lLm9yZwoKCgoKT24gMTMgTWFyY2ggMjAx NyBhdCAyMTo0NiwgRGFuaWVsIEJvbGVzIDxkYm9sZXMuc3JjQGdtYWlsLmNvbT4gd3JvdGU6CgoK VGhpcyBpcyBhIHByZXR0eSBvYnZpb3VzICJubyIuIElmIHRoZSBvcGVyYXRpb24gY2FuIGNhdXNl IGEgcmVhbGxvY2F0aW9uLCB0aGF0J3MgYSB2ZXJ5IHN0cm9uZyBoaW50LCBzbyBpZiB0aGUgY29u dGFpbmVyIGRvZXMgbm90IGV4cGxpY2l0bHkgc3RhdGUgdGhhdCBpdCBkb2VzIE5PVCBpbnZhbGlk YXRlIGl0ZXJhdG9ycy4uLi4gdGhlbiBpdCBkb2VzCgoKSSByZWFsbHkgbWVhbnQgJ2luY3JlYXNl IHRoZSBjYXBhY2l0eScsIG5vdCAncmVhbGxvY2F0aW9uJywgaWYgd2UgdXNlICdyZWFsbG9jYXRp b24nIGluIHRoZSBzZW5zZSBvZiBtb3ZpbmcgZXhpc3RpbmcgZWxlbWVudHMsIG5vdCBqdXN0IGFs bG9jYXRpbmcgb3RoZXIgbWVtb3J5IGZvciBuZXcgb25lcy4gU28gcmVhbGxvY2F0aW9uIGluIHRo aXMgc2Vuc2Ugc2hvdWxkIGFsd2F5cyBpbnZhbGlkYXRlIGl0ZXJhdG9ycy4gQW5kIHNpbmNlIHVz dHJpbmcgKGFuZCBzdGQ6OnN0cmluZykgaXMgYSByYW5kb20tYWNjZXNzIGNvbnRhaW5lciwgaXQg bXVzdCBoYXZlIGNvbnRpZ3VvdXMgbWVtb3J5LCBzbyBhbnkgaW5jcmVhc2UgaW4gY2FwYWNpdHkg bXVzdCBjYXVzZSBhIHJlYWxsb2NhdGlvbi4gU28sIGFueSBpbnNlcnQvYXBwZW5kIG9yIGFueXRo aW5nIGVsc2UgdGhhdCBhZGRzIGVsZW1lbnRzLgoKYnV0IHRoZXJlJ3MgYSBwb2ludDogaWYgeW91 IGhhZCBwcmV2aW91c2x5IHJlc2VydmUoKWQgZW5vdWdoIGNhcGFjaXR5LCBiZXlvbmQgdGhlIGN1 cnJlbnQgc2l6ZSwgZm9yIHRoZSBpbnNlcnQgcG9pbnQgYW5kIGxlbmd0aCwgdGhlbiBhcyBsb25n IGFzIHlvdSBzdGF5IHdpdGhpbiB0aGUgY2FwYWNpdHkgeW91IGhhZCwgeW91ciBpdGVyYXRvcnMg c2hvdWxkIHJlbWFpbiB2YWxpZCwgYXMgcmVhbGxvY2F0aW9uIGlzIGd1YXJhbnRlZWQgbm90IHRv IG9jY3VyIGluIHN1Y2ggY2FzZXMu --b1_4a3adb53e040e6b1ac42d21c2e985a41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdj5XaGF0IGFib3V0IHVzdHJpbmcuZW5kKCkgaXRlcmF0b3I/IEkgdGhpbmsgaXQncyBvYnZp b3VzIHRoYXQgaXQncyBpbnZhbGlkYXRlZCBlYWNoIHRpbWUgd2UgY2hhbmdlIHRoZSBzdHJpbmcn cyBsZW5ndGggKHVubGVzcyBpdCdzIGRvbmUgaW4gc29tZSAqdmVyeSBjbGV2ZXIqIHdheSkuPGJy PjwvZGl2PjxkaXY+SXQncyBhIHRoaW5nIG5vIHJlc2VydmUoKS1hdGlvbiBjYW4gaGVscC48YnI+ PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4tLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0t LS0tPGJyPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSJwcm90b25tYWlsX3F1 b3RlIj48ZGl2PlN1YmplY3Q6IFJlOiBTaG91bGQgYW4gaXRlcmF0b3IgYmUgdmFsaWQgYWZ0ZXIg YXBwZW5kaW5nIHRvIGEgR2xpYjo6dXN0cmluZz88YnI+PC9kaXY+PGRpdj5Mb2NhbCBUaW1lOiAx MyBtYXJjYSAyMDE3IDEwOjUwIFBNPGJyPjwvZGl2PjxkaXY+VVRDIFRpbWU6IDEzIG1hcmNhIDIw MTcgMjE6NTA8YnI+PC9kaXY+PGRpdj5Gcm9tOiBkYm9sZXMuc3JjQGdtYWlsLmNvbTxicj48L2Rp dj48ZGl2PlRvOiBndGttbS1saXN0QGdub21lLm9yZzxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48 ZGl2IGRpcj0ibHRyIj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGRpdiBjbGFzcz0iZ21haWxf cXVvdGUiPjxkaXY+T24gMTMgTWFyY2ggMjAxNyBhdCAyMTo0NiwgRGFuaWVsIEJvbGVzIDxzcGFu IGRpcj0ibHRyIj4mbHQ7PGEgcmVsPSJub3JlZmVycmVyIG5vZm9sbG93IG5vb3BlbmVyIiBocmVm PSJtYWlsdG86ZGJvbGVzLnNyY0BnbWFpbC5jb20iPmRib2xlcy5zcmNAZ21haWwuY29tPC9hPiZn dDs8L3NwYW4+IHdyb3RlOjxicj48L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUi IHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRk aW5nLWxlZnQ6MWV4Ij48ZGl2IGRpcj0ibHRyIj48ZGl2PlRoaXMgaXMgYSBwcmV0dHkgb2J2aW91 cyAibm8iLiBJZiB0aGUgb3BlcmF0aW9uIGNhbiBjYXVzZSBhIHJlYWxsb2NhdGlvbiwgdGhhdCdz IGEgdmVyeSBzdHJvbmcgaGludCwgc28gaWYgdGhlIGNvbnRhaW5lciBkb2VzIG5vdCBleHBsaWNp dGx5IHN0YXRlIHRoYXQgaXQgZG9lcyBOT1QgaW52YWxpZGF0ZSBpdGVyYXRvcnMuLi4uIHRoZW4g aXQgZG9lczxicj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj48 ZGl2PkkgcmVhbGx5IG1lYW50ICdpbmNyZWFzZSB0aGUgY2FwYWNpdHknLCBub3QgJ3JlYWxsb2Nh dGlvbicsIGlmIHdlIHVzZSAncmVhbGxvY2F0aW9uJyBpbiB0aGUgc2Vuc2Ugb2YgbW92aW5nIGV4 aXN0aW5nIGVsZW1lbnRzLCBub3QganVzdCBhbGxvY2F0aW5nIG90aGVyIG1lbW9yeSBmb3IgbmV3 IG9uZXMuIFNvIHJlYWxsb2NhdGlvbiBpbiB0aGlzIHNlbnNlIHNob3VsZCBhbHdheXMgaW52YWxp ZGF0ZSBpdGVyYXRvcnMuIEFuZCBzaW5jZSB1c3RyaW5nIChhbmQgc3RkOjpzdHJpbmcpIGlzIGEg cmFuZG9tLWFjY2VzcyBjb250YWluZXIsIGl0IG11c3QgaGF2ZSBjb250aWd1b3VzIG1lbW9yeSwg c28gYW55IGluY3JlYXNlIGluIGNhcGFjaXR5IG11c3QgY2F1c2UgYSByZWFsbG9jYXRpb24uIFNv LCBhbnkgaW5zZXJ0L2FwcGVuZCBvciBhbnl0aGluZyBlbHNlIHRoYXQgYWRkcyBlbGVtZW50cy48 YnI+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PmJ1dCB0aGVyZSdzIGEgcG9pbnQ6IGlmIHlvdSBoYWQg cHJldmlvdXNseSByZXNlcnZlKClkIGVub3VnaCBjYXBhY2l0eSwgYmV5b25kIHRoZSBjdXJyZW50 IHNpemUsIGZvciB0aGUgaW5zZXJ0IHBvaW50IGFuZCBsZW5ndGgsIHRoZW4gYXMgbG9uZyBhcyB5 b3Ugc3RheSB3aXRoaW4gdGhlIGNhcGFjaXR5IHlvdSBoYWQsIHlvdXIgaXRlcmF0b3JzIHNob3Vs ZCByZW1haW4gdmFsaWQsIGFzIHJlYWxsb2NhdGlvbiBpcyBndWFyYW50ZWVkIG5vdCB0byBvY2N1 ciBpbiBzdWNoIGNhc2VzLjxicj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2Nr cXVvdGU+PGRpdj48YnI+PC9kaXY+ --b1_4a3adb53e040e6b1ac42d21c2e985a41-- From dboles.src@gmail.com Tue Mar 14 14:39:13 2017 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 smtp.gnome.org (Postfix) with ESMTP id 373757623D for ; Tue, 14 Mar 2017 14:39:13 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPGPOf0IbkBG for ; Tue, 14 Mar 2017 14:39:11 +0000 (UTC) Received: from mail-lf0-f51.google.com (mail-lf0-f51.google.com [209.85.215.51]) by smtp.gnome.org (Postfix) with ESMTPS id 2A32476209 for ; Tue, 14 Mar 2017 14:39:10 +0000 (UTC) Received: by mail-lf0-f51.google.com with SMTP id z15so55349124lfd.1 for ; Tue, 14 Mar 2017 07:39:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=k7fGDiCppnjCKVyvunqlpQOyzNcZRuVuYrkG1K1RK9Q=; b=qeLw737yeJQFr+YMmp26aVf6IhuFzC0/VJWb9uLTnuYIzsIciiUP2glo6uQZJKNZfD WRiPYebL22VbQV8cVipvtjzzPbbJs1fqmHvq4XVZ1qeAgkG8lbu0yDdy4bOa1rusNZFI xH+D0Ul5zvYfuBQ17ChpbRAe8sHBribZSec02676oCB2PVVLyrUIOA9uFHSasJ+ex7n5 S0x75am90xw0AszEKgohw8iJm7xEYplTH54SvGSGNC2PYdicZdBjfzgys21FWnNoRb6W uC7ATrnATYw5QyYX/S5kZtvoPJizENMdPPt9ph8aXeDGzTDUOBmYq4/rySh7wkT0XfYD qtaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=k7fGDiCppnjCKVyvunqlpQOyzNcZRuVuYrkG1K1RK9Q=; b=WWSMz2BHv6b33U7i8hQPxvWEIgERPo3xddqODRbgsXL0SBiAh8kXSzJOxzScMs/zqv An2P0GJD0N/Jity0tIJ+3WGYC92MNoYwNmPkk0ykpruiOfT294iTlbaSoJmTNyQrsouE BjIP/Nde2jJ69pxcZwqaogOAWvAbfvhESJk9Iy9ora3nz0k89Q/kkYDtk1U234z7UfRP eZD4THAiWb4CfEOrdoiB0tRuwqQ7r5MhQ7KGTb3nwlhI4mU49hg2NXDVlYjir7+DaG0n 4f33w+gqEEhV1zligO5270hcdwJvjueUXNOmqEz7yn6cqZEHB7MKWWppIumkoWiDyNgL aODg== X-Gm-Message-State: AFeK/H3YGuuJ0zC9A5TBWgpHeWRfVYmKOpxzL0EszRXsxJTPejtZeLP52gZyhptQAmXNG2zMF3J1wqtEOwsjaQ== X-Received: by 10.46.71.193 with SMTP id u184mr4970841lja.97.1489502348011; Tue, 14 Mar 2017 07:39:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.18.222 with HTTP; Tue, 14 Mar 2017 07:39:07 -0700 (PDT) In-Reply-To: <9fajqk-U627HPuyWw6pPgvNcWn2zp-lJ6cabYtxWl2EimXHQSJM6pu0muE22w5r8Vx0ThteLpKsBCk5hP5yXWeGBEzBmmxQH1r7hapFtzKM=@protonmail.com> References: <9fajqk-U627HPuyWw6pPgvNcWn2zp-lJ6cabYtxWl2EimXHQSJM6pu0muE22w5r8Vx0ThteLpKsBCk5hP5yXWeGBEzBmmxQH1r7hapFtzKM=@protonmail.com> From: Daniel Boles Date: Tue, 14 Mar 2017 14:39:07 +0000 Message-ID: Subject: Re: Should an iterator be valid after appending to a Glib::ustring? To: gtkmm-list@gnome.org Content-Type: multipart/alternative; boundary=001a11407104587242054ab1ca1a X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 14:39:13 -0000 --001a11407104587242054ab1ca1a Content-Type: text/plain; charset=UTF-8 On 14 March 2017 at 14:29, Krzysztof Piecuch via gtkmm-list < gtkmm-list@gnome.org> wrote: > What about ustring.end() iterator? I think it's obvious that it's > invalidated each time we change the string's length (unless it's done in > some *very clever* way). > It's a thing no reserve()-ation can help. > Right, yeah. Whether an iterator can remain valid also depends on what it represents, and .end() is especially vulnerable. Good point! --001a11407104587242054ab1ca1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 4 March 2017 at 14:29, Krzysztof Piecuch via gtkmm-list &= lt;gtkmm-list@gno= me.org> wrote:
What ab= out ustring.end() iterator? I think it's obvious that it's invalida= ted each time we change the string's length (unless it's done in so= me *very clever* way).
It's a thing no reserve()-ation ca= n help.

Right, yeah. Whether an itera= tor can remain valid also depends on what it represents, and .end() is espe= cially vulnerable. Good point!

--001a11407104587242054ab1ca1a-- From hub@figuiere.net Tue Mar 14 15:08:59 2017 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 smtp.gnome.org (Postfix) with ESMTP id D8B2476287 for ; Tue, 14 Mar 2017 15:08:59 +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 smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVaRo_Qy9PKQ for ; Tue, 14 Mar 2017 15:08:58 +0000 (UTC) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by smtp.gnome.org (Postfix) with ESMTPS id C36397624D for ; Tue, 14 Mar 2017 15:08:58 +0000 (UTC) Received: from homiemail-a13.g.dreamhost.com (sub3.mail.dreamhost.com [69.163.253.7]) by hapkido.dreamhost.com (Postfix) with ESMTP id 26DA2AA4F0 for ; Tue, 14 Mar 2017 08:08:56 -0700 (PDT) Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 1DAB6334076; Tue, 14 Mar 2017 08:08:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=figuiere.net; h=subject:to :references:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; s=figuiere.net; bh=Agly clZBEkZyd9CGGcnnd0OJASE=; b=wyCFpp4SyBpmh7rTISRt/8cvWheSnsUHGtYW bZS0UJwhuSoRd2dpLoNdo9Xr74KZ+06ssaTexfYTkP8A6uPDADPoF/ZcrNHxgway s7yuBgxoZZRHpObU8lAnGDl587FDwLqaMIjjereQDsxltjx3x1n9QrM3bCgMEDgy nHHeOlo= Received: from [172.18.2.123] (198-48-204-18.cpe.pppoe.ca [198.48.204.18]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: hub@figuiere.net) by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id A502033406C; Tue, 14 Mar 2017 08:08:52 -0700 (PDT) Subject: Re: Should an iterator be valid after appending to a Glib::ustring? To: Daniel Boles , gtkmm-list@gnome.org References: <9fajqk-U627HPuyWw6pPgvNcWn2zp-lJ6cabYtxWl2EimXHQSJM6pu0muE22w5r8Vx0ThteLpKsBCk5hP5yXWeGBEzBmmxQH1r7hapFtzKM=@protonmail.com> From: =?UTF-8?Q?Hubert_Figui=c3=a8re?= Message-ID: <41db7fe5-d590-d4da-20fe-610cee5bd672@figuiere.net> Date: Tue, 14 Mar 2017 11:08:51 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 15:09:00 -0000 On 14/03/17 10:39 AM, Daniel Boles wrote: > On 14 March 2017 at 14:29, Krzysztof Piecuch via gtkmm-list < > gtkmm-list@gnome.org> wrote: > >> What about ustring.end() iterator? I think it's obvious that it's >> invalidated each time we change the string's length (unless it's >> done in some *very clever* way). It's a thing no reserve()-ation >> can help. >> > > Right, yeah. Whether an iterator can remain valid also depends on > what it represents, and .end() is especially vulnerable. Good point! The simple rule: mutating the container cause iterators to be invalidated, unless if explicitly said otherwise, like std::list<>. http://en.cppreference.com/w/cpp/container/list > Addition, removal and moving the elements within the list or across > several lists does not invalidate the iterators or references. An > iterator is invalidated only when the corresponding element is > deleted. Hub From mike.fleetwood@googlemail.com Mon Mar 6 18:22:04 2017 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 smtp.gnome.org (Postfix) with ESMTP id 697F0764B0 for ; Mon, 6 Mar 2017 18:22:04 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkCmKMmPEf6v for ; Mon, 6 Mar 2017 18:22:00 +0000 (UTC) Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) by smtp.gnome.org (Postfix) with ESMTPS id 5D8C176212 for ; Mon, 6 Mar 2017 18:22:00 +0000 (UTC) Received: by mail-oi0-f49.google.com with SMTP id m124so89754099oig.1 for ; Mon, 06 Mar 2017 10:22:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=bc/pNejjsUkGNFHi4wo/PPrdTzjBvlgATtaSyev40Bs=; b=dUO6Wbu8uyvytLCMi6oPn+3APaSTj/fIxqmR/+jbeLENN+gAcwSxoOggsloqsckNsp kSmyH3it6+TKH5WHiQjfCfm5B9NElloDazb2q9+tQKPt+fSmmaHAMsfzSNOo1+MIKQ8K M8HuA5w20mAJAB/akwMGD+/XPmS+aJwUVQ4vCxGNCKQXbHuekZJdKngJN/1AlUwG85y3 C1S9jcd31sftV8yu4ZnUL2hGGYM1VySd52aoS40yFVDxc91CjMledDgN/WaxhyGuYCPk mnk0p+0G8hUs2aswrYeApMuwovXip+dTFzv4Tt2hiAoCWrmsvQLz7KoKNkDQEhwMEUiO UjXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=bc/pNejjsUkGNFHi4wo/PPrdTzjBvlgATtaSyev40Bs=; b=BMxv1nNnQ0s9i7koFk+tIcW+spEknXNMczWqqy7DjB8mO+jLnMuqtBJcu/tDKJpALE kyRuCbk8STUGD2QEDQkpLk2/JzP+2sC72MSGtYVBffPIovKxO/J5kR+YpykxZtrh5/Or Q/mZkqR3dId3wDeXMRHJyO/rEu7jqMqegkMAErWv9owzHxWEDRYVNvsPSErJ7UTSwOUX avY7e7KtF/8vWWaNIhTO32OTr5g8qnTM9LO+n5fZTEbDlnwJhSP/pRgDESZR3ycIxLcF 1AiCphHrNzR1ioPITo5k8MnjPdAJrloAi5DKxMfxpM0pDKFQqWcI7r+pdxtdLmz2gESk fSxA== X-Gm-Message-State: AMke39mcyYhy4TsCEhVP2pV0GQOvfNPzvvN2d3ASXZKdHiyarh1L5ef1SiOcXkwSG++KO6rf9FSO97NMOLspFA== X-Received: by 10.202.48.84 with SMTP id w81mr4530283oiw.87.1488824518155; Mon, 06 Mar 2017 10:21:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.22.141 with HTTP; Mon, 6 Mar 2017 10:21:57 -0800 (PST) From: Mike Fleetwood Date: Mon, 6 Mar 2017 18:21:57 +0000 Message-ID: Subject: Should an iterator be valid after appending to a Glib::ustring? To: gtkmm list Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Thu, 16 Mar 2017 12:27:22 +0000 X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 18:22:04 -0000 Are iterators into a Glib::ustring still valid after the string is modified? Specifically appended to or modified at or beyond where the iterator points. I didn't obviously see this mentioned in the documentation. I though it might be valid because the iterator appears to be implemented using a pointer difference type. However the following small test program fails with: ** ERROR:test.cc:28:int main(): assertion failed: (linestart <= cursor) Aborted Thanks, Mike --8<-- test.cc --8<-- #include #include int main() { Glib::ustring buf; Glib::ustring::iterator linestart = buf.begin(); Glib::ustring::iterator cursor = buf.begin(); gunichar uc = 'u'; buf.append(1, uc); cursor = buf.end(); g_assert(buf.begin() <= linestart); g_assert(linestart <= cursor); g_assert(cursor <= buf.end()); return 0; } From dboles.src@gmail.com Thu Mar 16 12:35:42 2017 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 smtp.gnome.org (Postfix) with ESMTP id 152DA76227 for ; Thu, 16 Mar 2017 12:35:42 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGuQmkueW0Wh for ; Thu, 16 Mar 2017 12:35:41 +0000 (UTC) Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com [209.85.215.48]) by smtp.gnome.org (Postfix) with ESMTPS id EF0D7764A1 for ; Thu, 16 Mar 2017 12:35:40 +0000 (UTC) Received: by mail-lf0-f48.google.com with SMTP id y193so19538478lfd.3 for ; Thu, 16 Mar 2017 05:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=MH7puFuOh1g7azSryh4X7Wjo5a3h4tURzTwUVP6aGE0=; b=IYQCoVEh+d3VBudoLALv5eJBGCZvj5lSKSN8gay8qhEwmf54LK7xRPPiDSOXQDZ5Eg PBnOy4nDjQEwg9UlJ2W135ccm3LWUYf5XuVOo8XjV0rHsCQYVlR7cgbmA1BY3wmHaZN1 grXsAeZpDoIh+c+nBwycTGJhnz+IMMUfobbSNKbFKKFrOQkLeFG2RkB1jPcqR0+xacVc kqEPLkejWEj3cfJRft8pLoLznEZlHOu2NdyyGgEJIBKWJN9NEQWtFXSmEHDd4lSeRW6W lb7Un8bYMqGxSXD3AdCkb3Hm4/0cm0eQSW06v1dRgc3XY1RoAQj2aAATTGw4uoAoEEBS YaBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=MH7puFuOh1g7azSryh4X7Wjo5a3h4tURzTwUVP6aGE0=; b=XxvnR0ixe6ZMCkQLDG+oe0uI5bKXgX89UeC6UP4HXky03IpC5s0rM5/ppJ2nwdzxt7 L829QPAgF5fEu2szqzv2cyzsUkSeXfmQHZkf34Tk17CGqCl/Ow2iv0yOUWFLFRgrq0cI fSwaqryl7imZ3GvCtmXmWmwoJ1sKSusm9no6vutwue2083g1JmTmT5HpXk9Jw2wtWra6 OJJ7QiCwpw5gH5RIdPok0gIhDpG9bt0zV2TudRbgupD8vANKKOZAU7trioDJIl0oOeNu vXflq0yO5LrpHRAb1DYldHW3Qo9WhH/yIAQaOdDvAUgsS1f/WbkzWsReutagHxid248k qb/w== X-Gm-Message-State: AFeK/H0wfmicu/7cPUn/F+QLLBaAFg9DqckBgcJiiMrlpl/IjSErfYpILDU8qAtnhhSKP0+/GzPlGIAEJyaQ5w== X-Received: by 10.46.84.78 with SMTP id y14mr2837695ljd.63.1489667737636; Thu, 16 Mar 2017 05:35:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.18.222 with HTTP; Thu, 16 Mar 2017 05:35:37 -0700 (PDT) In-Reply-To: References: From: Daniel Boles Date: Thu, 16 Mar 2017 12:35:37 +0000 Message-ID: Subject: Re: GTKMM/C++11: How to create a custom composite widget out of other widgets? To: gtkmm-list@gnome.org Content-Type: multipart/alternative; boundary=f403045fbc5855d70a054ad84c8a X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 12:35:42 -0000 --f403045fbc5855d70a054ad84c8a Content-Type: text/plain; charset=UTF-8 On 22 January 2017 at 14:17, Bill William wrote: > > (Afterthoughts: I was wondering if C++ has a way to implicitly convert > from one class type, example a composite widget type, to another class, > example Gtk:Widget&, simply by placing the class object in the context of > needing a different class type, example Gtk::Widgets? I was doing this > above using functor operator. So far I can only find examples of doing > this with built in variable types like int or char*.) > > Of course. Use a conversion operator. operator Gtk::Widget&() { return m_whatever_widget; } --f403045fbc5855d70a054ad84c8a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 2= 2 January 2017 at 14:17, Bill William <wm2015email@gmail.com> wrote:

(= Afterthoughts: I was wondering if C++ has a way to implicitly convert from = one class type, example a composite widget type, to another class, example = Gtk:Widget&, simply by placing the class object in the context of needi= ng a different class type, example Gtk::Widgets?=C2=A0 I was doing this abo= ve using functor operator.=C2=A0 So far I can only find examples of doing t= his with built in variable types like int or char*.)


Of course. Use a conversion operator.


operator Gtk::Widget&(){
=C2= =A0=C2=A0 return m_whatever_widget;
}
=C2=A0
--f403045fbc5855d70a054ad84c8a-- From murrayc@murrayc.com Fri Mar 17 07:04:23 2017 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 smtp.gnome.org (Postfix) with ESMTP id BCA1B764BC for ; Fri, 17 Mar 2017 07:04:23 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46VXkYvmSALp for ; Fri, 17 Mar 2017 07:04:22 +0000 (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by smtp.gnome.org (Postfix) with ESMTPS id 7F29A762A8 for ; Fri, 17 Mar 2017 07:04:21 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id A707F20B5A; Fri, 17 Mar 2017 03:04:19 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 17 Mar 2017 03:04:19 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=murrayc.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=XG7BaqwxdOmooDl gf1JMFBlkUwU=; b=teiUo0giqDiWIX1gK21VVYX62M1qM49R0BEUGtDLeeTIhl9 J2vTfwTQL7aHZHKOUpCDJbaM5ZP1z+fbZIvS4DW8Qu8tihOIlHfhEqjKhGrUpjNu SS5q2lYpJ72jc36auhbEuwlk7SjYfzykXO1l+Mg0UKuiAxpg156Yk6le4LLA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=XG7BaqwxdOmooDlgf1JMFBlkUwU=; b=IbQk5wdThn0uGbC8bune10aa Pi32xmtwHIWDmK95fq43GHzjeoh7xoihZszJwtUAnaRzNj8RidM/JbLdHdjNe07A oOugMmLHmWj+ngKTpwJZdmt/CENy/SOlOSl4rtOM6Wyol0haXbnqVwIiLNMzDLVv 6+GNgp9BEUAuuJXXyO22Z/K7208NdWj2PiQK30Nj9TLbc/koVR3Vl6ICHrTVaAHz kMywaZ0vRAtxaTgzpw87kv+irckjev/Tf5JBcXAk9Wp09DCczOx5oHxj5ITyI2i/ DBliFk48C2m2Yzc5fnpEaXBuD5vn4aiWA2/xaYKMZgmwdKhVaYB6+ye8mpmBfg== X-ME-Sender: X-Sasl-enc: NcV0w0BFh9NJsAgveAW5nPLS8mHpB9z+SR+5w5ud4nNE 1489734259 Received: from murrayc-ThinkPad-X220 (aftr-185-17-205-103.dynamic.mnet-online.de [185.17.205.103]) by mail.messagingengine.com (Postfix) with ESMTPA id 03286240AE; Fri, 17 Mar 2017 03:04:18 -0400 (EDT) Message-ID: <1489734257.28263.1.camel@murrayc.com> Subject: Re: Glibmm-2.52: Shall StreamIOChannel and IOChannel vfuncs be undeprecated? From: Murray Cumming To: Kjell Ahlstedt Cc: gtkmm-list Date: Fri, 17 Mar 2017 08:04:17 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.3-0ubuntu0.1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 07:04:23 -0000 On Thu, 2017-03-16 at 14:32 +0100, Kjell Ahlstedt wrote: >  I don't know if it's useful. Then let's not have it unless we at least have a test case that uses it, please. > Anyway, if the vfuncs in IOChannel are removed, GlibmmIOChannel in > iochannel.ccg must also be removed. It uses the vfuncs. And the > default constructor, which uses GlibmmIOChannel, must be removed, I > suppose. That makes sense. Thanks. -- Murray Cumming murrayc@murrayc.com www.murrayc.com From murrayc@murrayc.com Fri Mar 17 07:05:51 2017 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 smtp.gnome.org (Postfix) with ESMTP id 97EC9764BC for ; Fri, 17 Mar 2017 07:05:51 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r42UcorTCqtB for ; Fri, 17 Mar 2017 07:05:51 +0000 (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by smtp.gnome.org (Postfix) with ESMTPS id F2C2C762A8 for ; Fri, 17 Mar 2017 07:05:50 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 6602F20B00; Fri, 17 Mar 2017 03:05:49 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 17 Mar 2017 03:05:49 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=murrayc.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=bZ1RuThBbfY9/Qg eoMAlCvkzXD4=; b=MOq67VZIijAMJkG41fU1XkpC0GBFPcQUJALW2ql0IZqDv8H z65uk7XOZLw1Y894tde4W05HG8/kUwRXgWroFtZR7WFPSEAIIXRpR2UGxDW17pZY v0dCN7rynm7VeZGafj9So7Oe19oJ21SquFxLvM3Fpt+Ju1jdl5N7Wj+X5sGs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=bZ1RuThBbfY9/QgeoMAlCvkzXD4=; b=LKX/CtvrPEjBontmvjaTEIvu RZM9pR7bggTsXPJn9F4sJgI08SGbCibvFqDesZzMNoPeP8hElRjzW8zmlgXkDGkk XLc+85MwXBeSRMAx4UDmPpqrHXvEClecOtd9YRFfoEQb6JyoPGMPp/m3PhQtzZze Kkcism8e/PVnWduKI0eDC7DlK9v744GR/3sVzFwRodbDYptREwosXE90yoD05JaD ZXkdXp6QxSNcKfvZSxKs6H34kTQ0t6Sbt00heQ6hFZciiHierVeoLNHuKrkpHz5C RbzQfeey4cL/aGf1CgN/HdXUD+rEyWAj+3ldd7Qfh34ojj+/3cp9pXWTlbX9ng== X-ME-Sender: X-Sasl-enc: RN0xpAC/vDtoreRUzEi8KpRtQegLp7SIbBFCsC8pC4lH 1489734348 Received: from murrayc-ThinkPad-X220 (aftr-185-17-205-103.dynamic.mnet-online.de [185.17.205.103]) by mail.messagingengine.com (Postfix) with ESMTPA id B51212428D; Fri, 17 Mar 2017 03:05:48 -0400 (EDT) Message-ID: <1489734347.28263.2.camel@murrayc.com> Subject: Re: gtkmm: PageSettings From: Murray Cumming To: Kjell Ahlstedt Cc: gtkmm-list Date: Fri, 17 Mar 2017 08:05:47 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.3-0ubuntu0.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 07:05:51 -0000 On Thu, 2017-03-16 at 14:35 +0100, Kjell Ahlstedt wrote: > You're probably right. I made a mistake by mixing up ArrayHandle and > ArrayHandler. ArrayHandle has a TODO comment, saying that it shall be > removed when we can break ABI. But PageSettings and PrintJob used > ArrayHandler, not ArrayHandle. I can change back to using > ArrayHandler, if you like. Yes, please. It seems cleaner. Thanks. > Den 2017-03-14 kl. 08:13, skrev Murray Cumming: > > Hi. > > > > In this commit: > > https://git.gnome.org/browse/gtkmm/commit/?id=fb1906febeec767d8463e > > c877 > > 2b6c845bf120455 > > > > If the 2 get_page_ranges() methods need different ownership logic, > > wouldn't that just be a matter of changing the Glib::OWNERSHIP_* > > value > > used? > > -- Murray Cumming murrayc@murrayc.com www.murrayc.com From murrayc@murrayc.com Fri Mar 17 07:25:13 2017 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 smtp.gnome.org (Postfix) with ESMTP id B23DB764BC for ; Fri, 17 Mar 2017 07:25:13 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBtuysxdQ5zC for ; Fri, 17 Mar 2017 07:25:13 +0000 (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by smtp.gnome.org (Postfix) with ESMTPS id 0FF28762A8 for ; Fri, 17 Mar 2017 07:25:12 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id E512620A4F; Fri, 17 Mar 2017 03:25:10 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 17 Mar 2017 03:25:10 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=murrayc.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=ebKaReFxNTIYmsS wqj3MySkaimU=; b=iHX+t6AoL+h4XhGEUb+ZlNMiYHCpMp4y/3R0A7a9o7DSVAI KzALOHRa76G7WFlJ08aOwmZNfs2gdPRgGNdLjhaJK8408+ZyVNnkmsLgks4Z9lly oOX8kZ2JXukqAShTPa8qNby2XA3t+RHPVaGywdVbG4dNLV5oSUWWVnvjPtU8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=ebKaReFxNTIYmsSwqj3MySkaimU=; b=obBmSLrKx+W5LyAkvuvS2vce dtArR6fPAYvlO3dsORkAMdhYXEHIFl5k/xXdmzvKOZVREJ43U7XI90jZ2byGFlJl tP74YlXVKc5WN8OvRRiSFgfoI+Rvl3I5EPLhh5WdHuuQXEusjwA7UU7/qJOauJva JTBGV3t25l3Io/NHlHh7SNiDdpSHOYpgi98sn4l0zalzQZzMR22lDN8GYpjxoKhr 1NwLyO+Ts7hLIz29krBrnuhBeqR7cQdroyJ+s91htIokcotB6fDGiNCukqaTUZo5 4sCr6YVh6LeuaF2bmB5Lh33ZEyGubh8Tm7EKO5d8UwjU8IjqXo4Mqx63DtY37g== X-ME-Sender: X-Sasl-enc: rsb+IxJr+Z9AEqvgdWzXMl1JiXuHbqdosvC70heIZUe0 1489735510 Received: from murrayc-ThinkPad-X220 (aftr-185-17-205-103.dynamic.mnet-online.de [185.17.205.103]) by mail.messagingengine.com (Postfix) with ESMTPA id 3FC1B24216; Fri, 17 Mar 2017 03:25:10 -0400 (EDT) Message-ID: <1489735508.28263.3.camel@murrayc.com> Subject: Re: gtkmm: Pixbuf::get_pixels() From: Murray Cumming To: Kjell Ahlstedt Cc: gtkmm-list Date: Fri, 17 Mar 2017 08:25:08 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.3-0ubuntu0.1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 07:25:13 -0000 On Thu, 2017-03-16 at 14:34 +0100, Kjell Ahlstedt wrote: > The const usage is wrong in both get_pixels() methods. Should be >   _WRAP_METHOD(guint8* get_pixels(), gdk_pixbuf_get_pixels) >   _WRAP_METHOD(guint8* get_pixels(guint& length), > gdk_pixbuf_get_pixels_with_length) > and perhaps >   _WRAP_METHOD(const guint8* get_pixels() const, > gdk_pixbuf_get_pixels, constversion) >   _WRAP_METHOD(const guint8* get_pixels(guint& length) const, > gdk_pixbuf_get_pixels_with_length, constversion) > > The documentation of gdk_pixbuf_get_pixels[_with_length]() says > "This function will cause an implicit copy of the pixbuf data if the > pixbuf was created from read-only data." > I take this to mean that it's alright for the caller to change the > pixel data. (The implicit copy is owned by the GdkPixbuf object. The > caller shall not delete it.) There is also the > gdk_pixbuf_read_pixels() function (not yet wrapped in Gdk::Pixbuf) > which returns a const guint8*. It's perhaps a better choice when you > don't want to change the pixels, because it does not make a copy of > read-only data. Thanks. I didn't know about that. I've changed it as you suggest: https://git.gnome.org/browse/gtkmm/commit/?id=422c202a31740d2d52c045e97 975b4b7a9f15be4 -- Murray Cumming murrayc@murrayc.com www.murrayc.com From dboles.src@gmail.com Fri Mar 17 07:55:15 2017 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 smtp.gnome.org (Postfix) with ESMTP id E9B1276AD0 for ; Fri, 17 Mar 2017 07:55:15 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvSYPNC8a35w for ; Fri, 17 Mar 2017 07:55:14 +0000 (UTC) Received: from mail-lf0-f43.google.com (mail-lf0-f43.google.com [209.85.215.43]) by smtp.gnome.org (Postfix) with ESMTPS id B5D5B762A8 for ; Fri, 17 Mar 2017 07:55:13 +0000 (UTC) Received: by mail-lf0-f43.google.com with SMTP id a6so29764638lfa.0 for ; Fri, 17 Mar 2017 00:55:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=zbY5p8/Zpmr4jYuwn6vrPhi0JTuxmsYyrTCmTEpUZSw=; b=jjvLsTBjHzjYSKa++GjL4Sl/kgVpfflwjnuU0HRMYajE4za2Dld1E0tVbpDiR8ZRxp KwfZ4EFlM+phtpvjussiJfHrOGS2OI/W7rnInjxYpCFNwLMLx51iL7k7oJORFZKHoR8X GKUP4GzX0ayomv8733Oj9Q5v0lMlNWT3PsZtpZe/rfBJqGzlx2u1H8v/q34qqjQ99GKo 5cMf5+LejHYWZakP4imW7nVI11LKn5riUJKqsNHns6+05rv1Pj2zFH3QamjYNbjocG+k IwFbtjVwqRZc+/NX5Mw8UU4uPOE94US1Ne64O1C+z89qjmSnNsHa9dkcRYhHTlR0KIO2 wcmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=zbY5p8/Zpmr4jYuwn6vrPhi0JTuxmsYyrTCmTEpUZSw=; b=OBo0TSYJlLiub0cmpYH3IpdRuTEjYpYCJjVlVwcsG2qb0k2MMUPnf9LbCW1e8vp5i8 YhevB05MOBBFxF5OIXVO8wSQOoD6zWAub5A2AWh+Yrt0jGhzOWSQ4sTdeOf2s5BrS3IH A6Vwb9Nf4NED4AsHhPa/Kkt/X33npwogHEYpnvruTN3Ix2eJ1gzftn56J84Ey+qkqtQd f1ttrDwKYyxGPmi7DTFJPH2qKJONgIewz1W20k8H76ejgoktRAteaWZonTndJgEiFiFf QiJM2DJHZA85g2qbTRHCY+H5vz8eCsBeZ0JMdWVTEl3vUHuSevWj+F8L0F4tjU49jDPM amJg== X-Gm-Message-State: AFeK/H1PmMYItMsEe1T/KllWEFIE2mgRO3fnNj5tjw6Rf6NEBwirDqsZgCHzdfdq1tYEcD0yLM1/GGx3FMa5JQ== X-Received: by 10.46.71.11 with SMTP id u11mr4370271lja.97.1489737310281; Fri, 17 Mar 2017 00:55:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.18.222 with HTTP; Fri, 17 Mar 2017 00:55:09 -0700 (PDT) In-Reply-To: <1489735508.28263.3.camel@murrayc.com> References: <1489735508.28263.3.camel@murrayc.com> From: Daniel Boles Date: Fri, 17 Mar 2017 07:55:09 +0000 Message-ID: Subject: Re: gtkmm: Pixbuf::get_pixels() To: gtkmm-list@gnome.org Content-Type: multipart/alternative; boundary=001a113db77430244e054ae87f11 X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 07:55:16 -0000 --001a113db77430244e054ae87f11 Content-Type: text/plain; charset=UTF-8 The copy is done as follows, to support copy-on-write: * This function will cause an implicit copy of the pixbuf data if the * pixbuf was created from read-only data. https://git.gnome.org/browse/gdk-pixbuf/tree/gdk-pixbuf/gdk-pixbuf.c#n674 I thought as long as the apparent functioning of the object is still the same to external users, then it is allowed to make internal changes even on a const instance? Using mutable members. If so, then maybe it would still be OK to wrap that as a const method. --001a113db77430244e054ae87f11 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The copy is done as follows, to= support copy-on-write:

 * This function will cause an implicit copy o=
f the pixbuf data if the
 * pixbuf was created from read-only data.

https://git.gnome.or=
g/browse/gdk-pixbuf/tree/gdk-pixbuf/gdk-pixbuf.c#n674
=

<=
br>

=

If so, t=
hen maybe it would still be OK to wrap that as a const method.
=
--001a113db77430244e054ae87f11-- From murrayc@murrayc.com Fri Mar 17 13:29:20 2017 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 smtp.gnome.org (Postfix) with ESMTP id 4B23876357 for ; Fri, 17 Mar 2017 13:29:20 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RO9GjybXPu6W for ; Fri, 17 Mar 2017 13:29:19 +0000 (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by smtp.gnome.org (Postfix) with ESMTPS id 39D377622D for ; Fri, 17 Mar 2017 13:29:19 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 9F2BB20AEB; Fri, 17 Mar 2017 09:29:17 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 17 Mar 2017 09:29:17 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=murrayc.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=b7JJUCYJneaarCx S3PCRSuVlFU0=; b=PbQq8iL7OL0LT04u3KhK8t/U8X8/F8ruus/efCvkZvVp0Xv 6BHJTZrapzl6s2imlgDwat+W95QpGbu4AmxBuTUuCLYKhfF8G8dKOtFsEmn14ewT vLGCDdW+PCC13HJ8BKTJwp2HDlCOVTevd4n8DdTz5tP4etOKrM2LXCyvWH2s= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=b7JJUCYJneaarCxS3PCRSuVlFU0=; b=pchNJdJfYp1PVARkFkt4361M R4OWGccckPVWUUU2dJR1AM9xrhI1rScRaSu0rP4v6QLW1elDeh/E/4DLcoWeI+Yj qetuDZdHOyRLwVwn8sMs0kBRvNJTfYnp4AggbjkgW8Ry0PuaH+dhLL5M2jIQm/Sx xFpv1D2CDVZ77FXZUsFS7rTud48FGjT5KMN3GxYmL2hjIaiDmS0VV9poDyTxFWtE XUcklyFarNP9i92lXCvbJIDk0RBW+5Z02g4eTrC0ZgEqkQ+yZ8BT/RUBK6F6teKp wkBQ5Nr+b8BpdgM8wqo9E3fqt4MNDpvnC0IRMXMY9hF5/ODmqGcnYkZ7Cv1WQw== X-ME-Sender: X-Sasl-enc: ByaonBX3/A8qer8N3ul1uRB4dWw2+J6qAOHcNeAvwe5X 1489757357 Received: from murrayc-ThinkPad-X220 (aftr-185-17-205-103.dynamic.mnet-online.de [185.17.205.103]) by mail.messagingengine.com (Postfix) with ESMTPA id E8A9B24545; Fri, 17 Mar 2017 09:29:16 -0400 (EDT) Message-ID: <1489757355.20912.3.camel@murrayc.com> Subject: Re: gtkmm: Pixbuf::get_pixels() From: Murray Cumming To: Daniel Boles , gtkmm-list@gnome.org Date: Fri, 17 Mar 2017 14:29:15 +0100 In-Reply-To: References: <1489735508.28263.3.camel@murrayc.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.3-0ubuntu0.1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 13:29:20 -0000 On Fri, 2017-03-17 at 07:55 +0000, Daniel Boles wrote: > The copy is done as follows, to support copy-on-write: > >  * This function will cause an implicit copy of the pixbuf data if > the >  * pixbuf was created from read-only data. > > https://git.gnome.org/browse/gdk-pixbuf/tree/gdk-pixbuf/gdk-pixbuf.c# > n674 > > I thought as long as the apparent functioning of the object is still > the same to external users, then it is allowed to make internal > changes even on a const instance? Using mutable members. > > If so, then maybe it would still be OK to wrap that as a const > method. We are wrapping that as a const method. But we don't need to make anything mutable. We just const_cast the GdkPixbuf*. C doesn't do full C++-like const, so this is often necessary. If I have misunderstood, maybe you could suggest a particular patch. Thanks. -- Murray Cumming murrayc@murrayc.com www.murrayc.com From john@creativepost.co.uk Fri Mar 17 17:57:32 2017 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 smtp.gnome.org (Postfix) with ESMTP id 48F7F76ADC for ; Fri, 17 Mar 2017 17:57:32 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cF-q6kVmlsQm for ; Fri, 17 Mar 2017 17:57:31 +0000 (UTC) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) by smtp.gnome.org (Postfix) with ESMTPS id E8B9276ACD for ; Fri, 17 Mar 2017 17:57:29 +0000 (UTC) Received: from [192.168.1.5] ([92.23.187.142]) by mrelayeu.kundenserver.de (mreue005 [212.227.15.167]) with ESMTPSA (Nemesis) id 0LxKXe-1c9suT1H7C-016zho for ; Fri, 17 Mar 2017 18:57:27 +0100 Message-ID: <58CC2386.9000805@creativepost.co.uk> Date: Fri, 17 Mar 2017 17:57:26 +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: Closing a Gtk::MessageDialog Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ioEbkmvyIBkLzAVTk4w8ACMst5N/+ev2h2++qBgCdb44eBfwSDp M4b1LaBk54kixTPFzNRftxG9LD1qeCm5n1egja3+kQX+WwU6e5iaD0V+JSeRm/j4O+r+4Og 7wPgy5QvBkpqCmCNZbSnlDeXtKsNB9+1E9S+hY2HsxLU9KLVuItri1C1cMbILskWwlg5ZNa 9afIyKyHlzHF34p9Vq7lw== X-UI-Out-Filterresults: notjunk:1;V01:K0:7QhMq1zljGM=:L9OoWh8FZ73v9b3DLdSgIm 5we48u2wjWgyktGPiCrheqpgSnEtbZjxrCqFLYLJ4QJXndToLrLwmnh4MvYgr5LO//IMrUetg bpc5KUKiVpcT+0w1R6ubBALD6huUgaXui74qj88wpLsCsiLpqbCb63Z8ZEGe93TWW9pZL6QDa Ri3EcHoLqfNOnGdciPG+s/UZVj4Fc0s1Ienw/s74it4vjIHe2zarbT1lq708meGjIuDyh7z4f DKpO0068LBQ7YA+pqU1m2zaNxkKF1+rSZxjDrd6niJnstnGGTiAhbpDKszejeDcrxDp4Y85T4 jLl+GNKEdpGm2ZlxTFAKQOUTwqInJMopVz2IU2pouxaYdYxqb0hi8M6mLiS6ZLGcClXISykb0 3+4b5MGTkziRGKD+r6pq8A+i4dU8bICVloSycNYScQXQ4W9fH7n4Uxyx3daR/9trTMbnrWpAx vRqg+dLUv6lXM5BXT8ccZpXqxve5K+xgfRfeSKowWVMCNYCJ0QkfB4P5JQLoA1Y8n2ntPmMpQ xFrQP99EhtMjsercKDz1c1pM/AhPzRIC7LRsnzSFVOANn7BWzYlmDI3IWdUr+dpsaYamN8M8V NENV6K8xp26/O577wZO6aS/1tTTy+IBziNGG409J4ChW7PwYSS0LPOtYgsIdDNw/I+Gz3EkRs KFVEqygZfAZa4e5Z4Ovk10/Eq/gBkDIuYibm8J+2eS9hZFTLCN0ffSpRxMgpPfB49fNiOURvM W5XbDIVU2gPYeW17 X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 17:57:32 -0000 Suppose I'm writing an app whose purpose is just to test if something exists and display an appropriate message box:- #include int main (int argc, char *argv[]) { Gtk::Main app ( &argc, &argv ); Glib::ustring message; if ( the_thing_exists () ) message = "Yes, it existed"; else message = "No, it didn't exist"; Gtk::MessageDialog mainWnd (message, false, Gtk::MESSAGE_INFO, Gtk::BUTTONS_CLOSE); app.run (mainWnd); return 0; } The above code does display a MessageDialog (with the correct text) but its CLOSE button doesn't close the dialog. I've tried other buttons (OK / CANCEL etc) but none of them seems to close the dialog (which I assumed would be the default action). What am I missing here..? John From john@creativepost.co.uk Fri Mar 17 18:17:12 2017 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 smtp.gnome.org (Postfix) with ESMTP id A265C76ACD for ; Fri, 17 Mar 2017 18:17:12 +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 smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxeWuc7FgG0B for ; Fri, 17 Mar 2017 18:17:11 +0000 (UTC) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) by smtp.gnome.org (Postfix) with ESMTPS id 2A479764AF for ; Fri, 17 Mar 2017 18:17:10 +0000 (UTC) Received: from [192.168.1.5] ([92.23.187.142]) by mrelayeu.kundenserver.de (mreue102 [212.227.15.183]) with ESMTPSA (Nemesis) id 0LlWdD-1cFc9M2P95-00bJSY for ; Fri, 17 Mar 2017 19:17:07 +0100 Message-ID: <58CC2822.7060404@creativepost.co.uk> Date: Fri, 17 Mar 2017 18:17:06 +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: Closing a Gtk::MessageDialog References: <58CC2386.9000805@creativepost.co.uk> In-Reply-To: <58CC2386.9000805@creativepost.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:+PbfOzcYhJCx3OLvWdFRK7MIV5Blp8+AWWILZnAKIWsKRU7UjVI DSd7tbeugFQ4DyeXYm2KTErlfhCo+AxCiNLzAJ7sxSY+XdcgAfoWPnuJtAZ8ZMGMTsyClk0 5ytXU+Ww/UNVt4BIAgPNX+6P67R8XjC+FTLAqDEl1cKdUah/sj/XeVnBBdW1y4cZamKjb4C AribO1tmXAVD6Veg1nKfQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:zDVCgU+BFhI=:2Mn8EdsVgQUbqm7edy/drU n4ETsQCWNWXjUn9GLSzf/Ije6fGgLr0XWBUXHpZCgdwISgFa/gs1rGMfpZmyT9vrxYt6nvXH/ 9GfbcwAcVGI1IQWz9QdJbf7RrxmB3D4BrDQNAQioUY9PC3DY4sWmAYce0PruZte3BWNyuwdNY Z7sY6HFR9NnzXOjsGidSoD4x6uqwlSnfgE8p6m6RbcfWckO6pj4f3LSXR7SCtmxTCgdwMf5S/ 3IUsyDt/7AWEpfEWu5aRXyMRovGq3YgmydQazYL+50HQ9Pz4TaTtx0+4Iw5Qomba6sx1tWycb gyPcqk9oADxPVOO2xrfgaNWSAlwVfqFKlRG1hYMXSgVtGmIWhnD94WgcY/YxkijyousiqLLVv KlUNAorh3WHLbaElS1JS2Sw1qNJYAYklVy9NKKFrM8Mvv3q4CvwgRXYvzuU19O7t361QFg5lK MQCkpZkJR50wViskeWcAhRCmFgY3YckwTrVnAw7xWY+VETvA4ui+gssTmW0cDWEhx9qlEegru ZeO45h4R9KmznosfXIXSfTq7Z4abpw26bSs54SvPVftqUV4FWD6oCfmZNwCvm+PH1mTahKF6W JlzKhe4QQOT5Qp3bDn++QsUVILHNOH56iAeCJ4NNL0B1jOJHQVWShhnO77uRg79FMjGNvep3w AF5bgnY28e1R5Yuk5h7j5uRT3qkAfp+jEgVh2Opf/j8xrsVB+zLduokFVa9wa/SbR0VF8DLTc 0/ST6CAePKEsD6lB X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 18:17:12 -0000 On 17/03/2017 17:57, John Emmas wrote: > > its CLOSE button doesn't close the dialog. I've tried other buttons > (OK / CANCEL etc) but none of them seems to close the dialog (which I > assumed would be the default action). What am I missing here..? > Sorry, I should have added that this is gtkmm 2.24 (rather than 3). John From dboles.src@gmail.com Fri Mar 17 19:20:51 2017 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 smtp.gnome.org (Postfix) with ESMTP id 8551B7654D for ; Fri, 17 Mar 2017 19:20:51 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGAVOK_Y4zUA for ; Fri, 17 Mar 2017 19:20:50 +0000 (UTC) Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com [209.85.215.46]) by smtp.gnome.org (Postfix) with ESMTPS id 730D5764C7 for ; Fri, 17 Mar 2017 19:20:50 +0000 (UTC) Received: by mail-lf0-f46.google.com with SMTP id a6so37018644lfa.0 for ; Fri, 17 Mar 2017 12:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=HVViwGntabu0PSGPFmQC1aOcMe15eVCQhjoxdRXTl3s=; b=u4JrFBUAPFMFtRF78/JdqGeIFhCkpJ/mSClm/oqDM3XxgQW3CcZ/WCanM3oxr45eei V1kuPJa6KUj2cEUg/vJ3hbtgIOVfS6Ip7I0MzHi66W3vhVwkm1FndJKbUlaNZH2Yj1rL r8/Sajgvg3UsaGXNk8CagSSSKUuc5lHK0FLA7PgGaHWee7MhCsl2uv6Ipi+HfDuicsXy +qoDLqfCIoATnEo7tjuXSnyxXUo5zAIJs3OZZenym1QsattDCT9SLCqzMVLJauMy+xaF BmMEr4kJZI+9s/y1DhVNyxijkDZTeDQq3cu+fyUfptNCPEl/tYQiPjvz9+zHLPiUsyA0 bBaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=HVViwGntabu0PSGPFmQC1aOcMe15eVCQhjoxdRXTl3s=; b=FPhfKKjSdkxgiKBF/64UnNe5wXozsxP6fxAO2w7N6IJXaPTFsgVt9Orc6L68OlHfbc HWY/gkBxCB0pYX6nRBQT/wY0L4cJZ90/U0mhh7yY2a+fFG/4/zYzXl48soZfXwFnsicb 4TLvs9qB4pTaX+kGvVKDsfsuIeSQh8dSvvvIS4EmzyA36o6bx6tpqA8nDspcTBPxbi8Y MPcYpyKslY7+YyIbsxmo9Oi7UUPom3Z/Btp+5PowUpE3lpwQIfHNaLRoxyf8xOh5fqOW DNMtTYLGRxefqs8U0A+0/lOSmp752ZXtNV6kzR/vza0syU1BBf3ZUP17/9n3SnQslXt4 g1XQ== X-Gm-Message-State: AFeK/H1umDyggR5yGIjTHQ4tNmlbNs4BuF2ruaV05J4jkPlB1hvY8UMXu644ZjFy2Tq+NPdwGhQjrrxmCR1uiQ== X-Received: by 10.46.19.25 with SMTP id 25mr5694304ljt.103.1489778447333; Fri, 17 Mar 2017 12:20:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.18.222 with HTTP; Fri, 17 Mar 2017 12:20:46 -0700 (PDT) In-Reply-To: <58CC2822.7060404@creativepost.co.uk> References: <58CC2386.9000805@creativepost.co.uk> <58CC2822.7060404@creativepost.co.uk> From: Daniel Boles Date: Fri, 17 Mar 2017 19:20:46 +0000 Message-ID: Subject: Re: Closing a Gtk::MessageDialog To: gtkmm-list@gnome.org Content-Type: multipart/alternative; boundary=f403043605c625bf98054af213c8 X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 19:20:51 -0000 --f403043605c625bf98054af213c8 Content-Type: text/plain; charset=UTF-8 You should be calling Dialog::run(), not using the Dialog as a main window. That is not how Dialogs are intended to be used. So I wouldn't be surprised if the close button does not have its intended effect without the nested main loop of Dialog::run() to process it. Though I've never tried what you did there. Also, Dialogs are supposed to be used with a main (non-dialog) window as parent; running them without a parent is discouraged. --f403043605c625bf98054af213c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You should be calling Dialog::run(), not using the Di= alog as a main window. That is not how Dialogs are intended to be used. So = I wouldn't be surprised if the close button does not have its intended = effect without the nested main loop of Dialog::run() to process it. Though = I've never tried what you did there.

Also, Dialogs are sup= posed to be used with a main (non-dialog) window as parent; running them wi= thout a parent is discouraged.

--f403043605c625bf98054af213c8-- From john@creativepost.co.uk Sat Mar 18 10:51:49 2017 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 smtp.gnome.org (Postfix) with ESMTP id 5F34A76269 for ; Sat, 18 Mar 2017 10:51:49 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTkLw-XLGjJj for ; Sat, 18 Mar 2017 10:51:48 +0000 (UTC) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.135]) by smtp.gnome.org (Postfix) with ESMTPS id D4C45761E3 for ; Sat, 18 Mar 2017 10:51:47 +0000 (UTC) Received: from [192.168.1.5] ([92.23.187.142]) by mrelayeu.kundenserver.de (mreue005 [212.227.15.167]) with ESMTPSA (Nemesis) id 0M0v2R-1bvahj0WcR-00v9pt for ; Sat, 18 Mar 2017 11:51:44 +0100 Message-ID: <58CD113F.7030904@creativepost.co.uk> Date: Sat, 18 Mar 2017 10:51:43 +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-list@gnome.org Subject: Re: Closing a Gtk::MessageDialog References: <58CC2386.9000805@creativepost.co.uk> <58CC2822.7060404@creativepost.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:o91IwPk+7o4xWQr29aGfcB4MELsG3ZD4ejdLcbp9I3ODlLg44BO If0t+AQqtIHC+Od6njb+belmfrVTkYZdFGzJaZdFq7Bjex+7cLjPoorTHC4JoJ5GtQITNkI FN9bk4wXzaQUxaOjK7q9JrMadOukvMB+sb756pr0CXOr+ybW7iTJ+iAPuZRz3BMHREB+8ge ddSYNf0jREAdWoPn2UIxw== X-UI-Out-Filterresults: notjunk:1;V01:K0:LYvdAgtdRuw=:7NwPrruNf1TrkUal5yNZ0p WNfJBOcHR3xbi0xukrjiJ/pTGR+JHZ8P1uk6GXZnOwqK1trQGlHp4cayVxZ7BAHVl2m8yDHhN 2gm0JFqz2QAfzkIxw9FjImWQKOplwdAoTf0NHRStmovDZsjniD/rNjKtDIxxDTsEqmTkQgfZo +IgXVMVMg5V5Fg6QCc4auS/nMHfOb2u1ATaBthHpN37JT+/Qg/N+Bf7n7KMNO3r+Qf2pZ1SM7 2CCTQW1iz81FeLtUf59Zeww+v7Ld4VXY/ytSjYULvKFjwG6Jhao+KiZHDQMNpyfwWkPV2QVEy UuQdU2Wt2LGrD4XZbFn4V+tTh9K3TZpOAC/oO+RbDI8x5icC7UkSp+cu1q7TRkrqSL1iW4rpR TlPijKf/LY6FGlOv120wyXgGeuXWkGwwAHqZFTYGn9peSs2jZ8KN3m2L4pQ/9nowVAG+ep2Hx Pwiym2raKlEc0oJ1QOwnreeE7PEANiWq3POMzywRryQTteBnG5fZIeXI5x2KicJxTk8om18I6 A9qX+kipYDg536hafaXRh9XPkzawponVUP8W6idwqNviXVAGMwRz7F8e4gr3kXlv0uk2heqix k78i9CZpJ58Y/Xk1fy7F0Ozu/VkpGF40NhwlvNcIB/07Qf/Vy3hjV3MBFa7yYj2kZwjdmkVVn GuF1GoYqKMd1uVQF11CR0txCw//Nzwf0wQBog2wZk7hcFsXfpZP11+ARoYDhTDOEWyJrJJo1T HmZK+omN0iE19WkY X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 10:51:49 -0000 On 17/03/2017 19:20, Daniel Boles wrote: > > Dialogs are supposed to be used with a main (non-dialog) window as > parent; running them without a parent is discouraged. > Thanks Daniel and Pavlo. I was getting mixed up with MSVC where dialog-based main windows are pretty common. I followed your advice and rearranged things so that the application will now launch Gtk::MessageDialog as a child dialog (rather than it actually 'being' a Gtk::MessageDialog) and it's now working as expected. John From murrayc@murrayc.com Tue Mar 21 16:23:04 2017 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 smtp.gnome.org (Postfix) with ESMTP id CF01B76492 for ; Tue, 21 Mar 2017 16:23:04 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1_r0RovkYF9 for ; Tue, 21 Mar 2017 16:23:03 +0000 (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by smtp.gnome.org (Postfix) with ESMTPS id 7BD2B76290 for ; Tue, 21 Mar 2017 16:23:03 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 5611320896; Tue, 21 Mar 2017 12:23:01 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 21 Mar 2017 12:23:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=murrayc.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=FgsTSmmhWYkCG/c 5QeiNrALs6CWsmHTGPohMrjeEyLY=; b=qLR6Ahjfcvskxdx7R2tYlYxem+qrLKA g8p+KND+rwbNkNXjDEw20ofFr0tsAXoEaZXPkJyVcqPTnejUe+iH/3zOCy8gz4a2 MLSgB6ZK9gbXxNdFvJNtyVPMBKNljSfF0+zoB+uzccyt313IKaUZ0YMQ64h5ydVb zSFeVFUvRKoY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=FgsTSmmhWYkCG/c5QeiNrALs6CWsmHTGPohMrjeEyLY=; b=c9D5Eebs ie98kfZLCefZlM14vrKnH/O12BlRzUDDgBLJAn0KpEGa93B/rY+ra4S5RbSZg2qn VwnooilW+bPL9UTulhEGar1R6vfimsgBqX21FT7pLmTz34QS8nKDCsfSOYetb5VD n9ITnix+x8Eedi+MoFXWE2Clc++wz4OeLrEsh15jdr2KEtccb8HxqV+RyOOorVAR JjYcdQ3tQea8ZZusDHVp5Ysw+cCOQlb86edLMHyrkx8BHgokf1l+aZHKEPSoitbz ZmAzE4RsRNmQLT0EvHNPmUMcTQJkpgAbItVIfuDbRxCvPGX9fHMBcV++/zFRv3Y5 hBbSMRM75WKG6Q== X-ME-Sender: X-Sasl-enc: qPPnr8sJlcBkbuGowDcHAFmO2DpuXtraBBaf31dhGOoZ 1490113380 Received: from murrayc-ThinkPad-X220 (aftr-185-17-205-202.dynamic.mnet-online.de [185.17.205.202]) by mail.messagingengine.com (Postfix) with ESMTPA id 59F212438A; Tue, 21 Mar 2017 12:23:00 -0400 (EDT) Message-ID: <1490113378.3190.1.camel@murrayc.com> Subject: Re: New versioning scheme in gtk+. And in gtkmm? From: Murray Cumming To: Kjell Ahlstedt , "gtkmm-list@gnome.org" Date: Tue, 21 Mar 2017 17:22:58 +0100 In-Reply-To: <1484403935.18178.5.camel@murrayc.com> References: <1477558296.995.0.camel@murrayc.com> <1478776532.26231.1.camel@murrayc.com> <1479117109.7019.2.camel@murrayc.com> <1479118089.3601.0.camel@murrayc.com> <1479300985.12470.3.camel@murrayc.com> <1484403935.18178.5.camel@murrayc.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.3-0ubuntu0.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 16:23:04 -0000 On Sat, 2017-01-14 at 15:25 +0100, Murray Cumming wrote: > We might choose to wait a bit longer, letting us do another stable > glibmm and gtkmm release, maybe then changing the glibmm-2.52 ABI > name > to glibmm-2.54, for instance. glibmm 2.52.0 has been released, but not GTK+ 4.0.0, so now is probably the time to do this. > I don't know when the GTK+ developers plan to call their GTK+-4.0 API > stable, but it's obviously not going to be ready for the next GNOME > release in March 2017. > > There's no sign of a gtk-3-24 branch yet for GTK+, but we might still > release 3.24.* versions of gtkmm-3.0. > > Let's see how things develop over the next few weeks. There's still no gtk+ 3.23/24, but we could still consider doing gtkmm 3.24/25. For now, I guess there is not a great demand for it. -- Murray Cumming murrayc@murrayc.com www.murrayc.com From john@creativepost.co.uk Wed Mar 22 08:52:36 2017 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 smtp.gnome.org (Postfix) with ESMTP id F413376BAC for ; Wed, 22 Mar 2017 08:52:35 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKgqsi92Cbho for ; Wed, 22 Mar 2017 08:52:32 +0000 (UTC) Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.73]) by smtp.gnome.org (Postfix) with ESMTPS id 7C04276B01 for ; Wed, 22 Mar 2017 08:52:30 +0000 (UTC) Received: from [192.168.1.5] ([79.76.110.111]) by mrelayeu.kundenserver.de (mreue102 [212.227.15.183]) with ESMTPSA (Nemesis) id 0M57wk-1byLf3367i-00zIKe for ; Wed, 22 Mar 2017 09:52:27 +0100 Message-ID: <58D23B4B.1070901@creativepost.co.uk> Date: Wed, 22 Mar 2017 08:52: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: utf8 and Glib::ustring Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:kA6JZVje86jT3CYRmEM1RfiyhTePJNlTMX5ZK6YdLIY2H2g79xt XW+MIk6tCUY3w0bKQZ4oN8Fofrg0wKat78EaXOGFFmRPJIl653ETOIvn7N4O9OaeGp7yU+J S1HYi81xZZiv0Lwj/ULKRt/HzeA2TckefcxXtjcPqUnb3DEKhunJMvOAhdjOdjLZv89R6uR TBR2tqPymgDHFmjWyrCoQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:wge1lxMMDis=:AfglGj7iqPIqLVMNR0fzhS Xl2B7gSj6Pu7c/sWXFgG8Arqo6zIGPEMarrsEGg12JEPFBtnTJpXlB7+8gTcbtC08Iiz05+g8 +M+Pv8nEpS2vdS3vhlppEflVntNp6/IcFM1YInu5Rp6lAh3S/TUbsQokd3+k4C1gWH5dzEEQ5 0OS2BVfEaLQNfDU5hb+nV+utqzEh+FPAXqVNGNKSoR1U2Ndu5nIK3iz1VSwPCBoU2k8Dhi/sQ aCXeQBZKKjRKtef8jDXDk5V9IUfkwC0MhQ3of+6sraEKQCNcDRoCvmyuf+jJXyIoIBd97iBN4 y1QXuhxfSHqH3TvETyvXZaYGQREnzEEJfsLKM4GN0UrHY4cUNF7LRrpCylYG5rYh3quElWaEi ffMjamxNrJ8nYlUVGIdGGNo3epdHK//f1V8gjmHkYXfv9XEEv0jIZhlk0sfY26GW1FzBAgcOQ VMlpH+SMy4ECV0Vb9Z2AwquZpfkroUpYFtg+Kg1SLP4w9vA/+6z5yfCdLsWjzjuneCW3+6kkn NnRl0k0wKXX11tnSmoJ1aX5m6fMNjafFynMCXzn4THUO5ej+QkT8PrEAF8c0Lfse50cucEMDb CgQzNojgpigRDXppc33HbjyfuLODOj8bATjxD0trxxax19X7Po9tFYTCKz2DiFDu4KoSp8U1K ZcOwT43WgIsqSzxAJHACxtq/X/kq3CVVFr2LD9t4TGh1YOM3E66VjIuSR4Qu/9j6jjfWOtrRH ocTnLzSjzPs/ABv4 X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 08:52:36 -0000 Forgive my ignorance - this'll probably be obvious to some of you... Suppose I've got a simple character string, like this:- const char* my_str = "Hello World"; I can assign it to a Glib::ustring very easily:- Glib::ustring ustr = my_str; BUT... instead of pointing to a 'normal' string (simple ASCII characters), let's suppose that 'my_str' was already pointing to a string in utf8 format. Will the same assignment still work - or is there some better way of assigning a utf8 string to a Glib::ustring? Thanks, John From chris@cvine.freeserve.co.uk Wed Mar 22 10:12:16 2017 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 smtp.gnome.org (Postfix) with ESMTP id 6C0A776317 for ; Wed, 22 Mar 2017 10:12:16 +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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWLtqd0OVqkl for ; Wed, 22 Mar 2017 10:12:15 +0000 (UTC) X-Greylist: delayed 458 seconds by postgrey-1.34 at restaurant.gnome.org; Wed, 22 Mar 2017 10:12:15 UTC Received: from avasout01.plus.net (avasout01.plus.net [84.93.230.227]) by smtp.gnome.org (Postfix) with ESMTPS id 63BD276212 for ; Wed, 22 Mar 2017 10:12:15 +0000 (UTC) Received: from bother.homenet ([87.113.146.222]) by avasout01 with smtp id yy4Y1u0024o7gtj01y4Z03; Wed, 22 Mar 2017 10:04:34 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.2 cv=BZKo6vl2 c=1 sm=1 tr=0 a=9jpyzeay8jPqJjMTTx4PlA==:117 a=9jpyzeay8jPqJjMTTx4PlA==:17 a=kj9zAlcOel0A:10 a=6Iz7jQTuP9IA:10 a=fmcxAVT0AAAA:8 a=1-vMJW6VkpmAf5pq4kcA:9 a=CjuIK1q_8ugA:10 a=eZylWqDJSdARo9tehK3V:22 Received: from dell.homenet (localhost [127.0.0.1]) by bother.homenet (Postfix) with ESMTP id F14FD442D05 for ; Wed, 22 Mar 2017 10:04:31 +0000 (GMT) Date: Wed, 22 Mar 2017 10:04:31 +0000 From: Chris Vine To: gtkmm-list@gnome.org Subject: Re: New versioning scheme in gtk+. And in gtkmm? Message-ID: <20170322100431.5659b912@dell.homenet> In-Reply-To: <1490113378.3190.1.camel@murrayc.com> References: <1477558296.995.0.camel@murrayc.com> <1478776532.26231.1.camel@murrayc.com> <1479117109.7019.2.camel@murrayc.com> <1479118089.3601.0.camel@murrayc.com> <1479300985.12470.3.camel@murrayc.com> <1484403935.18178.5.camel@murrayc.com> <1490113378.3190.1.camel@murrayc.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 10:12:16 -0000 On Tue, 21 Mar 2017 17:22:58 +0100 Murray Cumming wrote: > On Sat, 2017-01-14 at 15:25 +0100, Murray Cumming wrote: > > We might choose to wait a bit longer, letting us do another stable > > glibmm and gtkmm release, maybe then changing the glibmm-2.52 ABI > > name > > to glibmm-2.54, for instance. > > glibmm 2.52.0 has been released, but not GTK+ 4.0.0, so now is > probably the time to do this. > > > I don't know when the GTK+ developers plan to call their GTK+-4.0 > > API stable, but it's obviously not going to be ready for the next > > GNOME release in March 2017. > > > > There's no sign of a gtk-3-24 branch yet for GTK+, but we might > > still release 3.24.* versions of gtkmm-3.0. > > > > Let's see how things develop over the next few weeks. > > There's still no gtk+ 3.23/24, but we could still consider doing gtkmm > 3.24/25. For now, I guess there is not a great demand for it. It is possible I am wrong (the original naming proposals were changed and I may have missed something) but I do not think there is ever intended to be a 3.23/24. As I understand it, 3.22 has become like 2.24: it will be maintained for some time - as a minimum 2 years - but no new additions or changes of any kind (including CSS/theming and gobject-introspection changes) will be made in the future. I think it was intended to be 2 years before gtk+-4 comes out. In the meantime gtk+-3.89/3.9* (the development series for gtk+-4) is supposed to be in use by most gnome components during that period even though API/ABI might change in it. In fact nothing in gnome-3.23/3.24 uses it (apart from gtkmm-3.89). I can't say I am surprised. No one particularly likes to rewrite existing code and many gnome components use functions deprecated in later versions of gtk+3 and removed from gtk+-3.89. From dboles.src@gmail.com Wed Mar 22 10:22:29 2017 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 smtp.gnome.org (Postfix) with ESMTP id 5EADA76272 for ; Wed, 22 Mar 2017 10:22:29 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvdQyvpkmHkL for ; Wed, 22 Mar 2017 10:22:28 +0000 (UTC) Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by smtp.gnome.org (Postfix) with ESMTPS id 56B9B76212 for ; Wed, 22 Mar 2017 10:22:28 +0000 (UTC) Received: by mail-wm0-f52.google.com with SMTP id u132so32363653wmg.0 for ; Wed, 22 Mar 2017 03:22:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ABQdJKAJuRfURs8qyNEWECwL4pJz3O9FWc0WcCtfOtw=; b=MRh9DAkfFDD1LtNvPq8XTWPpbxxae+hnWpp4FmWDbQwyY1b4HjtTpXSAkAuUqNLLiC C72RaxhgENpfrVTKWBYX89haSeKswlkcjvywD9RLg73Y3Yf4hDrzK6+oiRXvQANFRSWO YJXvrx5B4S5PzfhqgN5e/9bnBMgdfnX1NpjZ8ZD5HRjs7WS9Jn3ny6Mh5UOYyRJCen5W 2f3rAxDfdhjIZUyDXQKsK3okXP1RHHmsPNZwOq1STBHg2qWKIwLCWwYVjy4FchOrb07J Arrq/9rHOxUaHOiTHvGmN+VFX/MV1eZ2p11WuR/V2+sNbBCOnlonXfYDQsBTntTxlMjb KyLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ABQdJKAJuRfURs8qyNEWECwL4pJz3O9FWc0WcCtfOtw=; b=aJzIrdUHq8AU0SDBWiMFPgWlulYpZPMMYFOkAtY/TF9aPhm6uPqDWE3k3N+OYBXF29 tdEJGpkJe4Y3uPf28ZY5USQ4/4EIvFD3t1ZenI8IFjJrDGhAG7RQTG1QghQL0+fDMkuG +Juet2yx1tQ8FlThZ3F+v3+WsARk1s69odxRIB6/lbIEgp9Kg74WoeQckuqqLtcXhYZY 7W5Oq1voaphVT0nXDvHcY/+c45rmibvxzLVllVXKpBXyFRjBDjY2StpHNWP/Tyx0pRcT UE5mLOLNWyGcSzRQQCBkUtmnc2WXAdAG8/NbQw5tzJMsaTXELP2AdsZodcIB4FDX13m0 2Eww== X-Gm-Message-State: AFeK/H0/esgK0OvU6JkElL2OoX24FP0KivHAQtAXrujTpCidzMUB6TJx/XPPMU10P7Phc24qRSis2yWCeUs8Vg== X-Received: by 10.25.21.229 with SMTP id 98mr6587009lfv.161.1490178145461; Wed, 22 Mar 2017 03:22:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.18.222 with HTTP; Wed, 22 Mar 2017 03:22:24 -0700 (PDT) In-Reply-To: <20170322100431.5659b912@dell.homenet> References: <1477558296.995.0.camel@murrayc.com> <1478776532.26231.1.camel@murrayc.com> <1479117109.7019.2.camel@murrayc.com> <1479118089.3601.0.camel@murrayc.com> <1479300985.12470.3.camel@murrayc.com> <1484403935.18178.5.camel@murrayc.com> <1490113378.3190.1.camel@murrayc.com> <20170322100431.5659b912@dell.homenet> From: Daniel Boles Date: Wed, 22 Mar 2017 10:22:24 +0000 Message-ID: Subject: Re: New versioning scheme in gtk+. And in gtkmm? To: gtkmm-list@gnome.org Content-Type: multipart/alternative; boundary=001a1140753203a4d0054b4f23d2 X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 10:22:29 -0000 --001a1140753203a4d0054b4f23d2 Content-Type: text/plain; charset=UTF-8 On 22 March 2017 at 10:04, Chris Vine wrote: > It is possible I am wrong (the original naming proposals were changed > and I may have missed something) but I do not think there is ever > intended to be a 3.23/24. As I understand it, 3.22 has become like > 2.24: it will be maintained for some time - as a minimum 2 years - but > no new additions or changes of any kind (including CSS/theming and > gobject-introspection changes) will be made in the future. > Yeah, but the question is different. It's whether gtkmm can have a 3.24 that will be able to add new API, e.g. for missing things or for new things that are shoehorned into GTK+ 3.22 when they probably shouldn't be. Alternatively we could just start shoehorning too. --001a1140753203a4d0054b4f23d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a1140753203a4d0054b4f23d2-- From murrayc@murrayc.com Thu Mar 23 10:51:08 2017 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 smtp.gnome.org (Postfix) with ESMTP id 6B6647630A for ; Thu, 23 Mar 2017 10:51:08 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DpKDNBIcH3u for ; Thu, 23 Mar 2017 10:51:05 +0000 (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by smtp.gnome.org (Postfix) with ESMTPS id 9359A762E4 for ; Thu, 23 Mar 2017 10:51:04 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 132482135B; Thu, 23 Mar 2017 06:51:03 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 23 Mar 2017 06:51:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=murrayc.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=9EtCsmQfdAiMLmn Rcn7UR29jZferOe9PtoENGd2qepc=; b=h4h7lUGWZaN1pj+108ghX0XWKcmyMOR YOQ/K7ZE9RTt7eytFeuHb+fAT0VsQQWTUI7PLpn0hg2RoOfbbWNIlZxIww2oBQFL /HVLz2No6FILGEPLHHBglSXGmLvEa6S+g5Svm4qGGbnQ9zNH10ADlhXlywbgXtHU CNXOpuoncFXo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=9EtCsmQfdAiMLmnRcn7UR29jZferOe9PtoENGd2qepc=; b=e0m9Rgpn d08tLWjRNaBH+CiWOW7SWRPwXmg7AIwajwkP9eUb1goLTEaY0HCLhYtelb3vlOm8 T6LIJ8aqWs7WbpbGUgE/1Z+gzH53KmoUeI+cvNAKPhP/1lRzIk8qoOB41XPStcyk DdPa+1PI6BeSHG5/SK/6lGIzXCexkCTq0sozf/fiFXiKH5EcMyYJI3q7nMuC1UNu +khDD4S85rlfpHeofKhGaWv/qxP5nZR3TzMlSXzsyHI+/oFvci1ps03YX6KQQq63 RydOcnDEclq3t8/1r2LuAgITS+DtEp2v5o59uMFPFczj1u8yD6ThJJz6VDE0D3Bg Wl7YydyDDgbOdw== X-ME-Sender: X-Sasl-enc: BxmwYjAHkAoyLu998CW1kYkX9r0ZgOI2zg3hvKDhgQSi 1490266262 Received: from murrayc-ThinkPad-X220 (aftr-88-217-181-50.dynamic.mnet-online.de [88.217.181.50]) by mail.messagingengine.com (Postfix) with ESMTPA id 3DCCE7E766; Thu, 23 Mar 2017 06:51:02 -0400 (EDT) Message-ID: <1490266260.31087.0.camel@murrayc.com> Subject: Re: New versioning scheme in gtk+. And in gtkmm? From: Murray Cumming To: Chris Vine , gtkmm-list@gnome.org Date: Thu, 23 Mar 2017 11:51:00 +0100 In-Reply-To: <20170322100431.5659b912@dell.homenet> References: <1477558296.995.0.camel@murrayc.com> <1478776532.26231.1.camel@murrayc.com> <1479117109.7019.2.camel@murrayc.com> <1479118089.3601.0.camel@murrayc.com> <1479300985.12470.3.camel@murrayc.com> <1484403935.18178.5.camel@murrayc.com> <1490113378.3190.1.camel@murrayc.com> <20170322100431.5659b912@dell.homenet> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.3-0ubuntu0.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 10:51:08 -0000 On Wed, 2017-03-22 at 10:04 +0000, Chris Vine wrote: > I think it was intended to be 2 years before gtk+-4 That sounds about right. Do you happen to have a link to where someone states that officially? -- Murray Cumming murrayc@murrayc.com www.murrayc.com From chris@cvine.freeserve.co.uk Thu Mar 23 15:17:18 2017 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 smtp.gnome.org (Postfix) with ESMTP id CF94576BC0 for ; Thu, 23 Mar 2017 15:17:18 +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 smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKBGqEXsFwZC for ; Thu, 23 Mar 2017 15:17:16 +0000 (UTC) X-Greylist: delayed 451 seconds by postgrey-1.34 at restaurant.gnome.org; Thu, 23 Mar 2017 15:17:16 UTC Received: from smtpout.wanadoo.co.uk (smtpout3.wanadoo.co.uk [80.12.242.59]) by smtp.gnome.org (Postfix) with ESMTP id 014DF764CF for ; Thu, 23 Mar 2017 15:17:15 +0000 (UTC) Received: from bother.homenet ([2.27.184.143]) by mwinf5d31 with ME id zT9g1u00L362zqS03T9gRo; Thu, 23 Mar 2017 16:09:41 +0100 X-ME-Helo: bother.homenet X-ME-Date: Thu, 23 Mar 2017 16:09:41 +0100 X-ME-IP: 2.27.184.143 Received: from bother.homenet (localhost [IPv6:::1]) by bother.homenet (Postfix) with ESMTP id 2CD39120C3F; Thu, 23 Mar 2017 15:09:40 +0000 (GMT) Date: Thu, 23 Mar 2017 15:09:40 +0000 From: Chris Vine To: Murray Cumming Cc: gtkmm-list@gnome.org Subject: Re: New versioning scheme in gtk+. And in gtkmm? Message-ID: <20170323150940.2f5a6bda@bother.homenet> In-Reply-To: <1490266260.31087.0.camel@murrayc.com> References: <1477558296.995.0.camel@murrayc.com> <1478776532.26231.1.camel@murrayc.com> <1479117109.7019.2.camel@murrayc.com> <1479118089.3601.0.camel@murrayc.com> <1479300985.12470.3.camel@murrayc.com> <1484403935.18178.5.camel@murrayc.com> <1490113378.3190.1.camel@murrayc.com> <20170322100431.5659b912@dell.homenet> <1490266260.31087.0.camel@murrayc.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 15:17:19 -0000 On Thu, 23 Mar 2017 11:51:00 +0100 Murray Cumming wrote: > On Wed, 2017-03-22 at 10:04 +0000, Chris Vine wrote: > > I think it was intended to be 2 years before gtk+-4 > > That sounds about right. Do you happen to have a link to where someone > states that officially? This seems the most current one, as far as I can tell: https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/ One point is that version 3.90 has still not been reached. gtk+ still seems stuck on gtk+-3.89, notwithstanding that gnome-3.24 has now come out. Chris From dboles.src@gmail.com Thu Mar 23 15:19:57 2017 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 smtp.gnome.org (Postfix) with ESMTP id 31D67764CF for ; Thu, 23 Mar 2017 15:19:57 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kq6OFSrAR03C for ; Thu, 23 Mar 2017 15:19:56 +0000 (UTC) Received: from mail-lf0-f50.google.com (mail-lf0-f50.google.com [209.85.215.50]) by smtp.gnome.org (Postfix) with ESMTPS id AEF5576269 for ; Thu, 23 Mar 2017 15:19:55 +0000 (UTC) Received: by mail-lf0-f50.google.com with SMTP id y193so83031215lfd.3 for ; Thu, 23 Mar 2017 08:19:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=iCkbngSDtt4u3h7WI992fp+mRw+7X2SzmQlp6VNg/lI=; b=BtZBbU6mm19w2VBTbPv3iFaMJLxgQRWKsgtMRG0ZYOxlkG6lh7S3Qg2eIx8pOuT69J VHWXUGbHVP2iLtCfw989QhSbNfgqrMrhl3xe0CvRGHSMQR258+iWlqDltajypkZrcAf3 9VGcWpCajvz4F1EbyH5YpTHJ7WjRPMXo8wRss0YaE0cOz1HhD4hqeqhAMnU2+OJQVIX6 UAflbA7HKOwlusYG0MKH+FeC0XOlteU+dte+lV3pXkVGC7UMukUAJ/bOyZGLhrVfEdcJ h4KiBHo0czTw2h5KlLUSdsr52nFWPnD6TzBMey+vhohe3ck+7JVp5z9wqP3tSbaEHMdJ xLGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=iCkbngSDtt4u3h7WI992fp+mRw+7X2SzmQlp6VNg/lI=; b=EdBdvXqSBeV3W1FsdGX/YuYGZWBWje5wYGmy77ueHVGsbergQ+tcvoXHeAo3mnE2Bh FNqvBWcQFS0RlD/fJlH6VhxLpHNlQKpRKijdgaEUJpJoyiHe1578iB/h7JST1S4KlaU2 S9i/y8X1b8Csb5oeo3NA4vJoANZu8R/hTcK/86RusHtsfW4O8FLRM13AhnYRChEkixH9 Xwi/rTXoNwSczwpO/S6p1ilHt+khj+XRT4d5bxt/RocluowWp5QW2ih1EcEp8I0X5gmw o1NjKMW5DbAMp+RvPZMDUpaQjIf+iU8aynrCgzlx9lv2JC3MKWLqGuUvmZYYPAnt25fi q2cQ== X-Gm-Message-State: AFeK/H0XhLPn5EkwrCk20Tjle5gdCds1w5qhoEabODgPWBFZKMiaA9mbOqu7RL5yrW3aPmKnr7YTMa/jJsnAkQ== X-Received: by 10.25.17.100 with SMTP id g97mr1707596lfi.10.1490282392479; Thu, 23 Mar 2017 08:19:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.18.222 with HTTP; Thu, 23 Mar 2017 08:19:51 -0700 (PDT) In-Reply-To: References: <1477558296.995.0.camel@murrayc.com> <1478776532.26231.1.camel@murrayc.com> <1479117109.7019.2.camel@murrayc.com> <1479118089.3601.0.camel@murrayc.com> <1479300985.12470.3.camel@murrayc.com> <1484403935.18178.5.camel@murrayc.com> <1490113378.3190.1.camel@murrayc.com> <20170322100431.5659b912@dell.homenet> <1490266260.31087.0.camel@murrayc.com> <20170323150940.2f5a6bda@bother.homenet> From: Daniel Boles Date: Thu, 23 Mar 2017 15:19:51 +0000 Message-ID: Subject: Fwd: New versioning scheme in gtk+. And in gtkmm? To: gtkmm-list@gnome.org Content-Type: multipart/alternative; boundary=001a113fc35e9e6cb1054b676840 X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 15:19:57 -0000 --001a113fc35e9e6cb1054b676840 Content-Type: text/plain; charset=UTF-8 On 23 March 2017 at 15:09, Chris Vine wrote: > One point is that version 3.90 has still not been reached. gtk+ still > seems stuck on gtk+-3.89, notwithstanding that gnome-3.24 has now come > out. > I don't think there is any relation between GNOME releases and the development of GTK+ 4. As far as I know, version 3.89 is really v4 alpha and will remain at that number until it's beta-worthy, at which point it will become 3.90 and so on. --001a113fc35e9e6cb1054b676840 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 23 March 20= 17 at 15:09, Chris Vine <chris@cvine.freeserve.co.uk> wrote:
One point is that version 3.90 has still not been reached.=C2=A0 gtk+ still=
seems stuck on gtk+-3.89, notwithstanding that gnome-3.24 has now come
out.

I don't think there is = any relation between GNOME releases and the development of GTK+ 4. As far a= s I know, version 3.89 is really v4 alpha and will remain at that number un= til it's beta-worthy, at which point it will become 3.90 and so on.
=


--001a113fc35e9e6cb1054b676840-- From chris@cvine.freeserve.co.uk Thu Mar 23 20:31:36 2017 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 smtp.gnome.org (Postfix) with ESMTP id 2DE5C762C3 for ; Thu, 23 Mar 2017 20:31:36 +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 smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 396n5pXKr9NS for ; Thu, 23 Mar 2017 20:31:35 +0000 (UTC) Received: from smtpout.wanadoo.co.uk (smtpout3.wanadoo.co.uk [80.12.242.59]) by smtp.gnome.org (Postfix) with ESMTP id CF44E761F1 for ; Thu, 23 Mar 2017 20:31:34 +0000 (UTC) Received: from bother.homenet ([2.27.184.143]) by mwinf5d33 with ME id zYXX1u00E362zqS03YXXMr; Thu, 23 Mar 2017 21:31:32 +0100 X-ME-Helo: bother.homenet X-ME-Date: Thu, 23 Mar 2017 21:31:32 +0100 X-ME-IP: 2.27.184.143 Received: from bother.homenet (localhost [IPv6:::1]) by bother.homenet (Postfix) with ESMTP id 1D0CC120C3F for ; Thu, 23 Mar 2017 20:31:31 +0000 (GMT) Date: Thu, 23 Mar 2017 20:31:31 +0000 From: Chris Vine To: gtkmm-list@gnome.org Subject: Re: New versioning scheme in gtk+. And in gtkmm? Message-ID: <20170323203131.19034e49@bother.homenet> In-Reply-To: References: <1477558296.995.0.camel@murrayc.com> <1478776532.26231.1.camel@murrayc.com> <1479117109.7019.2.camel@murrayc.com> <1479118089.3601.0.camel@murrayc.com> <1479300985.12470.3.camel@murrayc.com> <1484403935.18178.5.camel@murrayc.com> <1490113378.3190.1.camel@murrayc.com> <20170322100431.5659b912@dell.homenet> <1490266260.31087.0.camel@murrayc.com> <20170323150940.2f5a6bda@bother.homenet> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 20:31:36 -0000 On Thu, 23 Mar 2017 15:19:51 +0000 Daniel Boles wrote: > On 23 March 2017 at 15:09, Chris Vine > wrote: > > > One point is that version 3.90 has still not been reached. gtk+ > > still seems stuck on gtk+-3.89, notwithstanding that gnome-3.24 has > > now come out. > > > > I don't think there is any relation between GNOME releases and the > development of GTK+ 4. As far as I know, version 3.89 is really v4 > alpha and will remain at that number until it's beta-worthy, at which > point it will become 3.90 and so on. I think you think incorrectly. There is a relation: gnome components will be encouraged to transition to gtk+-3.9* when it is out. Whether they do or not is another matter. The rest of what you said seems OK. From dboles.src@gmail.com Sun Mar 26 20:11:56 2017 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 smtp.gnome.org (Postfix) with ESMTP id 243CB76233 for ; Sun, 26 Mar 2017 20:11:56 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zeD6PT7nf6I for ; Sun, 26 Mar 2017 20:11:55 +0000 (UTC) Received: from mail-lf0-f47.google.com (mail-lf0-f47.google.com [209.85.215.47]) by smtp.gnome.org (Postfix) with ESMTPS id A0A5276202 for ; Sun, 26 Mar 2017 20:11:54 +0000 (UTC) Received: by mail-lf0-f47.google.com with SMTP id j90so11951097lfk.2 for ; Sun, 26 Mar 2017 13:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ah9d1ijKV7dbJli4FbkfiahCwtF05VnIUym5c743Uao=; b=DSRrZZhPOnwtL7zc33M0hmfJLHFjQiYB2HKi2aXmatE28xq6k/OmnPKDZjTLJmx+c9 taOqrvn8V8dpY0ux8OuX//OPkJp/42li3SBTSL3lCBqWgOVZ5kH3NeTuT0NK8NOCja4z 5OJnK2t5N+fFQd3TeVUPK90kUa3mIIFRoAPhZy8YOHbmYNrkVViDuRyAoVimy7xF/ISx kfagNv4pcdqfwcMjLEQUrgXiNUFvPFT+djK3JTnr9uf4Y8QULOstuQaRGnbZk4MQY8p1 yRqCJO+KNXp4S1sefWlPrRlG1a8NWmt0lvYByzy6QsoMqdjIAYMubvgk5YtIcT85yTi7 Ld9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ah9d1ijKV7dbJli4FbkfiahCwtF05VnIUym5c743Uao=; b=XrPwvyJ+lNaqgm7nMhSI5d2X7+IjDvvBWCIl2vy8hoBFv2qg9SM6+ptFzdYsPc3wXj 7U9R+5mPHROI43s+shFQNH1PWmIBLKZh59VqDPlpt9ZIrvZCAdp5Gd3uBeHLBCH/aScT wc5knVAwQZtrNiz7cria7LHkrkf2mGJpkNEq0AUch5u+83yeJE+4/moCsAQdsnizvLN3 bK7bGUboKeE6ZcGdY8eVskek2MYw1I2s2A+D3oxvgbRhoBoZZEO7xmhKjtmNvrNysBYe RP/1z7SLQDryuQDqR9NSLubHs7v7nBb0UFihFCYPua/lqM5Ch7sPNiKwP/tWKEcHlbA/ XbnQ== X-Gm-Message-State: AFeK/H30DBmrbr1ht/GcYDFO8KaOqEkgTfOO8LCn5jR5zu/fb67JAsZVmN54E6R6Y+h2BcHloEEGakhwr+O/vQ== X-Received: by 10.25.217.153 with SMTP id s25mr8021108lfi.8.1490559111251; Sun, 26 Mar 2017 13:11:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.195.80 with HTTP; Sun, 26 Mar 2017 13:11:50 -0700 (PDT) In-Reply-To: <58D23B4B.1070901@creativepost.co.uk> References: <58D23B4B.1070901@creativepost.co.uk> From: Daniel Boles Date: Sun, 26 Mar 2017 21:11:50 +0100 Message-ID: Subject: Re: utf8 and Glib::ustring To: gtkmm-list@gnome.org Content-Type: multipart/alternative; boundary=94eb2c0638f057cf42054ba7d6b9 X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 20:11:56 -0000 --94eb2c0638f057cf42054ba7d6b9 Content-Type: text/plain; charset=UTF-8 On 22 March 2017 at 08:52, John Emmas wrote: > Forgive my ignorance - this'll probably be obvious to some of you... > > Suppose I've got a simple character string, like this:- > > const char* my_str = "Hello World"; > > I can assign it to a Glib::ustring very easily:- > > Glib::ustring ustr = my_str; > > BUT... instead of pointing to a 'normal' string (simple ASCII characters), > let's suppose that 'my_str' was already pointing to a string in utf8 > format. Will the same assignment still work - or is there some better way > of assigning a utf8 string to a Glib::ustring? Thanks, > > John > UTF-8 is backwards compatible with ASCII. If bit 7 of any given byte in a string is 0, then that byte is treated as ASCII. Only if bit 7 is 1 do UTF-8-compatible tools start interpreting the lower bits and the following bytes differently. In the same way, to Glib::ustring, any char* is just a block of bytes for it to interpret as ASCII or as the extended set of characters supported by UTF-8. (This typically manifests as different behaviour when getting the string length, indexing, etc.: there is no longer a 1:1 correspondence between size in bytes and length in characters when UTF-8 encoding is in play.) IOW, the answer to the question is yes, the same assignment will/must work, and no, there is no better way: construct the Glib::ustring from the char* and let it handle the rest. --94eb2c0638f057cf42054ba7d6b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 2= 2 March 2017 at 08:52, John Emmas <john@creativepost.co.uk> wrote:
Forgive m= y ignorance - this'll probably be obvious to some of you...

Suppose I've got a simple character string, like this:-

=C2=A0 =C2=A0 =C2=A0 const char* my_str =3D "Hello World";

I can assign it to a Glib::ustring very easily:-

=C2=A0 =C2=A0 =C2=A0 Glib::ustring ustr =3D my_str;

BUT... instead of pointing to a 'normal' string (simple ASCII chara= cters), let's suppose that 'my_str' was already pointing to a s= tring in utf8 format.=C2=A0 Will the same assignment still work - or is the= re some better way of assigning a utf8 string to a Glib::ustring?=C2=A0 Tha= nks,

John


UTF-8 is backwards compatible with ASCII.= If bit 7 of any given byte in a string is 0, then that byte is treated as = ASCII. Only if bit 7 is 1 do UTF-8-compatible tools start interpreting the = lower bits and the following bytes differently.

In the same way, to = Glib::ustring, any char* is just a block of bytes for it to interpret as AS= CII or as the extended set of characters supported by UTF-8. (This typicall= y manifests as different behaviour when getting the string length, indexing= , etc.: there is no longer a 1:1 correspondence between size in bytes and l= ength in characters when UTF-8 encoding is in play.)

IOW, the answer= to the question is yes, the same assignment will/must work, and no, there = is no better way: construct the Glib::ustring from the char* and let it han= dle the rest.

--94eb2c0638f057cf42054ba7d6b9-- From dboles.src@gmail.com Sun Mar 26 21:15:15 2017 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 smtp.gnome.org (Postfix) with ESMTP id 3850C76233 for ; Sun, 26 Mar 2017 21:15:15 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 675yzWaxq2vk for ; Sun, 26 Mar 2017 21:15:14 +0000 (UTC) Received: from mail-lf0-f42.google.com (mail-lf0-f42.google.com [209.85.215.42]) by smtp.gnome.org (Postfix) with ESMTPS id 0B8EB76202 for ; Sun, 26 Mar 2017 21:15:13 +0000 (UTC) Received: by mail-lf0-f42.google.com with SMTP id z15so12257381lfd.1 for ; Sun, 26 Mar 2017 14:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=LAI7dKkHgswMherTeFtgoXPvSR/SgZrVBWO8kwdHGJU=; b=krs+NzlkkEyK+S7faQ79e4eNS5wZXv7dy3mmFdi+rdPBZCxLHkAqcr1aw3792r3XtT //+VepiN76nnvKNLOpoBQBt+stcIfRs+AiILcIa0tNiYC5DlYVk3KkGYQ0eFJjn80kfP qkYExS4u6nTm6/ettyvIGIl35724QJiY4g/7+79oWua+vZJ+ulvQW/8SFk8Hmi/sQ4Zp CBEXGnzib5V5+s7qI0U7FcfMte8DXXB+1BU3YZq+lCWMCehtCjA+JMUXynONFFgl5nGe LmJdFpGRv0C4geV1E/hUghnPC0T+lZ/IdFGvtSvDoNR25eCTqrcPPHn7gDWu0Rdcb11d K6Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=LAI7dKkHgswMherTeFtgoXPvSR/SgZrVBWO8kwdHGJU=; b=JMjU8uaWaCqsmwo9wHWecbIL2v57K/nSWMZOz9kk80J8y2E1JJZ33bPzvZ7d6urR9/ 9UfTORtZl9AkSp1ilJd9/Dkdq1c0Ir3rZSJfVtVJptT2CpF/XUMbCk22IkU/TGF5oox6 sEkyO33dCMpcDZEKitpmy0oIu/TJttidf4XYp/HDj+z1m+DMNWjixNhOaTln91v81jKB GGPOxfFLtk3FhYN2zabN/cUg9396i9puEtL6vY3/M61FEAcnZMiCOA6QDk63JYp3U/He zFDGPq/9U6ep0zdVOGQiwlPxyyifZHcsYQs+0kDffd81zDJ8hJa7TlJssTcDKpeKg4oa VZlA== X-Gm-Message-State: AFeK/H2DZMyDnLiofJ+Z9m5i+AX3pD4ssPtQwHyh3q2/nVqrcpJ3RizgEq9TKJDfQx0lR5IOLCfJ/SExIxlPfA== X-Received: by 10.25.21.74 with SMTP id l71mr9279496lfi.93.1490562911000; Sun, 26 Mar 2017 14:15:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.195.80 with HTTP; Sun, 26 Mar 2017 14:15:10 -0700 (PDT) From: Daniel Boles Date: Sun, 26 Mar 2017 22:15:10 +0100 Message-ID: Subject: FileChooserDialog constructors taking backend argument To: gtkmm-list@gnome.org Content-Type: multipart/alternative; boundary=001a11403c4cd35b42054ba8b831 X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 21:15:15 -0000 --001a11403c4cd35b42054ba8b831 Content-Type: text/plain; charset=UTF-8 Hello, About this commit: https://git.gnome.org/browse/gtkmm/commit/?id=bd97e557771cdce23bdc815288db2ffdd8c083c9 Clearly these constructors could not actually achieve their stated purpose in GTK+ 3, as the backend functionality was removed already then. In case anyone was trying to use these in gtkmm-3, should deprecation warnings be added there, too? Clearly we don't want to just remove these ctors and break code that was using them, however ineffectively. --001a11403c4cd35b42054ba8b831 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Clearly these construc= tors could not actually achieve their stated purpose in GTK+ 3, as the back= end functionality was removed already then.

In case anyone was= trying to use these in gtkmm-3, should deprecation warnings be added there= , too? Clearly we don't want to just remove these ctors and break code = that was using them, however ineffectively.

--001a11403c4cd35b42054ba8b831-- From dboles.src@gmail.com Mon Mar 27 12:02:20 2017 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 smtp.gnome.org (Postfix) with ESMTP id B2F337621C for ; Mon, 27 Mar 2017 12:02:20 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dz8NNPvdFQKF for ; Mon, 27 Mar 2017 12:02:19 +0000 (UTC) Received: from mail-lf0-f43.google.com (mail-lf0-f43.google.com [209.85.215.43]) by smtp.gnome.org (Postfix) with ESMTPS id 91AEB76202 for ; Mon, 27 Mar 2017 12:02:19 +0000 (UTC) Received: by mail-lf0-f43.google.com with SMTP id h125so19431281lfe.0 for ; Mon, 27 Mar 2017 05:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=tA/ksrxtCiA7oAqg2OetuAprUpgl66cXf5902uE4ugI=; b=UKx6kaRsorGnMdc5pvnZN6Ny+Inxn8fxSh6Rb3XCupKZ2tLwt77sjHUO+ux5ssTFUQ Woh4cw9IGCCFbMsEp/k5fTAHmgbfdhLonXzsbd8G9jq8KBh3n4lNF/ZJFWwf1Kb4S/mg t0jg70JYNdpqV+lqCFaurVqf5QikCGTOs81u/E+UzcO2qpt1G7z3vD068cEIguU8Pc9Q ANvlZKR4+R9OW93agXOidbSgKoe7dLW78n85I/iJY2a9wcMnB1V1IQS3RAEVGEMHLU7N RKWVRKBPk9MepvM4R1K2s+XBFaqqf7m2jTW/VI/Odngp4I4UFic2wXtjPPQ2hRalZtoA Qw1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=tA/ksrxtCiA7oAqg2OetuAprUpgl66cXf5902uE4ugI=; b=iG/Y1vz7Rm8ES71M52Il72Hgdsdl8opUDbFMaFh6gy9gcVvcWoN708AAM2snZrPYnk ZXpKHPQOrNBQaM8oHZGSRgnO5kpcNYZY3ZpMdeef1oCO3Hx79Gf11hjXy9NHPSFdwN5m p6kteJnk7XOWESGxuHS8IR2u3MsuKWcClTR5BxD5HQP/I0oOM0A0wChQXMC0UUKopdP3 8WjdZPv0+9uBbHMGzTq7xsu0yoGdTLgFOZ/4WXlnU8z4HEGV4MN4wRi+q/MTp3ICHzW1 gAPUFGe/YSLq2Z6T5qMeczhcxXbAcdpjlV3AdaHYLUhczJCmJN/37QMzgsA027mxKIWS 20CA== X-Gm-Message-State: AFeK/H2sBk4UrOLj+EA9qv1GiwbGV9chu/RofKp7RJ8EptN+i1dlO8C0TwFxBf0xjyQcr102BBH5xom2xvqotA== X-Received: by 10.25.219.213 with SMTP id t82mr10034603lfi.75.1490616136526; Mon, 27 Mar 2017 05:02:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.195.80 with HTTP; Mon, 27 Mar 2017 05:02:16 -0700 (PDT) In-Reply-To: References: <8eb2cae3-27a9-715e-a905-42726b018ab9@bredband.net> From: Daniel Boles Date: Mon, 27 Mar 2017 13:02:16 +0100 Message-ID: Subject: Fwd: FileChooserDialog constructors taking backend argument To: gtkmm-list@gnome.org Content-Type: multipart/alternative; boundary=94eb2c184be050747f054bb51d6c X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 12:02:20 -0000 --94eb2c184be050747f054bb51d6c Content-Type: text/plain; charset=UTF-8 On 27 March 2017 at 12:50, Kjell Ahlstedt wrote: > Den 2017-03-26 kl. 23:15, skrev Daniel Boles: > >> Hello, >> >> About this commit: https://git.gnome.org/browse/g >> tkmm/commit/?id=bd97e557771cdce23bdc815288db2ffdd8c083c9 >> >> Clearly these constructors could not actually achieve their stated >> purpose in GTK+ 3, as the backend functionality was removed already then. >> >> In case anyone was trying to use these in gtkmm-3, should deprecation >> warnings be added there, too? Clearly we don't want to just remove these >> ctors and break code that was using them, however ineffectively. >> >> >> I have marked the FileChooserDialog constructors with backend parameters > deprecated in gtkmm-3. I suppose it's almost okay to do that in the > gtkmm-3-22 branch. We have been forced to deprecate other methods there > because of recent deprecations in gtk+. According to normal rules, new > deprecations would have to wait until gtkmm 3.24. > https://git.gnome.org/browse/gtkmm/commit/?h=gtkmm-3-22&id=d > b8310fc15108624c0d50bcbaf73312d59b297dc > Thanks! Indeed, even GTK+ 3.22 is not strictly enforcing API freeze; as well as deprecations, there has recently been some new API added. One in particular that comes to mind is gtk_flowbox_get_child_at_pos(): https://git.gnome.org/browse/gtk+/commit/gtk/gtkflowbox.h?h=gtk-3-22&id= 9679ef6b00cb087fecf772bb69ab9a2ad7429835 Shall we wrap such new methods when they arise? --94eb2c184be050747f054bb51d6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 27 March = 2017 at 12:50, Kjell Ahlstedt <kjell.ahlstedt@bredband.net&g= t; wrote:
Den 2017-03-26 kl. 23:15, skrev Daniel Boles:
Hello,

About this commit: https://git.gnome.org/browse/gtkmm/commit/?id=3Dbd97e557771cdc<= wbr>e23bdc815288db2ffdd8c083c9

Clearly these constructors could not actually achieve their stated purpose = in GTK+ 3, as the backend functionality was removed already then.

In case anyone was trying to use these in gtkmm-3, should deprecation warni= ngs be added there, too? Clearly we don't want to just remove these cto= rs and break code that was using them, however ineffectively.


I have marked the FileChooserDialog constructors with backend parameters de= precated in gtkmm-3. I suppose it's almost okay to do that in the gtkmm= -3-22 branch. We have been forced to deprecate other methods there because = of recent deprecations in gtk+. According to normal rules, new deprecations= would have to wait until gtkmm 3.24.
https://git.gnome.org/browse/gtkmm/commit/?h=3Dgtkmm-3-22&i= d=3Ddb8310fc15108624c0d50bcbaf73312d59b297dc


Tha= nks!

Indeed, even GTK+ 3.22 is not = strictly enforcing API freeze; as well as deprecations, there has recently = been some new API added. One in particular that comes to mind is gtk_flowbo= x_get_child_at_pos():
https://git.gnome.org/browse/gtk+/commi= t/gtk/gtkflowbox.h?h=3Dgtk-3-22&id=3D9679ef6b00cb087fecf772bb= 69ab9a2ad7429835
Shall we wrap= such new methods when they arise?


--94eb2c184be050747f054bb51d6c-- From kjell.ahlstedt@bredband.net Mon Mar 27 12:11:37 2017 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 smtp.gnome.org (Postfix) with ESMTP id 6B23F7621C for ; Mon, 27 Mar 2017 12:11:37 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsEsDQ5C2in8 for ; Mon, 27 Mar 2017 12:11:36 +0000 (UTC) X-Greylist: delayed 1261 seconds by postgrey-1.34 at restaurant.gnome.org; Mon, 27 Mar 2017 12:11:35 UTC Received: from smtprelay-h31.telenor.se (smtprelay-h31.telenor.se [213.150.131.4]) by smtp.gnome.org (Postfix) with ESMTPS id C9D4376202 for ; Mon, 27 Mar 2017 12:11:35 +0000 (UTC) Received: from ipb2.telenor.se (ipb2.telenor.se [195.54.127.165]) by smtprelay-h31.telenor.se (Postfix) with ESMTP id 92655D025 for ; Mon, 27 Mar 2017 13:50:30 +0200 (CEST) X-SMTPAUTH-B2: [kjell.ahlstedt@bredband.net] X-SENDER-IP: [85.229.147.206] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CPAABU+9hYAM6T5VUNTxsBAQEDAQEBCQEBAYQ1jnyiQYRXgg4shXYCg1MYAQIBAQEBAQEBDwE0hWUCAQM4QRALDjhXBg0IAQGKEao6gw6KNgEBAQEBAQEDAQEBAQEBHQWCMYQdggWCaoJ2IYcDHwWcW4IFhHadApNlH4E8OiqHJXiJMAEBAQ X-IPAS-Result: A2CPAABU+9hYAM6T5VUNTxsBAQEDAQEBCQEBAYQ1jnyiQYRXgg4shXYCg1MYAQIBAQEBAQEBDwE0hWUCAQM4QRALDjhXBg0IAQGKEao6gw6KNgEBAQEBAQEDAQEBAQEBHQWCMYQdggWCaoJ2IYcDHwWcW4IFhHadApNlH4E8OiqHJXiJMAEBAQ X-IronPort-AV: E=Sophos;i="5.36,231,1486422000"; d="scan'208";a="957342722" Received: from c-ce93e555.06-203-73746f44.cust.bredbandsbolaget.se (HELO [192.168.1.64]) ([85.229.147.206]) by ipb2.telenor.se with ESMTP; 27 Mar 2017 13:50:30 +0200 Subject: Re: FileChooserDialog constructors taking backend argument To: Daniel Boles References: Cc: gtkmm-list@gnome.org From: Kjell Ahlstedt Message-ID: <8eb2cae3-27a9-715e-a905-42726b018ab9@bredband.net> Date: Mon, 27 Mar 2017 13:50:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 12:11:37 -0000 Den 2017-03-26 kl. 23:15, skrev Daniel Boles: > Hello, > > About this commit: > https://git.gnome.org/browse/gtkmm/commit/?id=bd97e557771cdce23bdc815288db2ffdd8c083c9 > > Clearly these constructors could not actually achieve their stated > purpose in GTK+ 3, as the backend functionality was removed already then. > > In case anyone was trying to use these in gtkmm-3, should deprecation > warnings be added there, too? Clearly we don't want to just remove > these ctors and break code that was using them, however ineffectively. > > I have marked the FileChooserDialog constructors with backend parameters deprecated in gtkmm-3. I suppose it's almost okay to do that in the gtkmm-3-22 branch. We have been forced to deprecate other methods there because of recent deprecations in gtk+. According to normal rules, new deprecations would have to wait until gtkmm 3.24. https://git.gnome.org/browse/gtkmm/commit/?h=gtkmm-3-22&id=db8310fc15108624c0d50bcbaf73312d59b297dc From kjell.ahlstedt@bredband.net Mon Mar 27 12:40:07 2017 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 smtp.gnome.org (Postfix) with ESMTP id 3AECD7621C for ; Mon, 27 Mar 2017 12:40:07 +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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYcpTKnx7rmH for ; Mon, 27 Mar 2017 12:40:05 +0000 (UTC) Received: from smtprelay-b32.telenor.se (smtprelay-b32.telenor.se [213.150.131.21]) by smtp.gnome.org (Postfix) with ESMTPS id 9B8D676202 for ; Mon, 27 Mar 2017 12:40:04 +0000 (UTC) Received: from ipb5.telenor.se (ipb5.telenor.se [195.54.127.168]) by smtprelay-b32.telenor.se (Postfix) with ESMTP id C6EC987601 for ; Mon, 27 Mar 2017 14:40:01 +0200 (CEST) X-SMTPAUTH-B2: [kjell.ahlstedt@bredband.net] X-SENDER-IP: [85.229.147.206] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BqAQD/BtlYAM6T5VUNTxoBAQEBAgEBAQEIAQEBAYQ1gQufHx+QG1mEV4IOLoV0AoNYFgECAQEBAQEBAQ8BNIVlAQEBAgF5BQsLBAEJOFcGDQgBAYl7FqpLgw4rigwBAQEBAQEEAQEBAQEBHQWCMYQdggUIgmKCdiGHAx8FnFuCBYR2nQKTZSYOgSc6KoRqgjtzAQSJMAEBAQ X-IPAS-Result: A2BqAQD/BtlYAM6T5VUNTxoBAQEBAgEBAQEIAQEBAYQ1gQufHx+QG1mEV4IOLoV0AoNYFgECAQEBAQEBAQ8BNIVlAQEBAgF5BQsLBAEJOFcGDQgBAYl7FqpLgw4rigwBAQEBAQEEAQEBAQEBHQWCMYQdggUIgmKCdiGHAx8FnFuCBYR2nQKTZSYOgSc6KoRqgjtzAQSJMAEBAQ X-IronPort-AV: E=Sophos;i="5.36,231,1486422000"; d="scan'208,217";a="703764680" Received: from c-ce93e555.06-203-73746f44.cust.bredbandsbolaget.se (HELO [192.168.1.64]) ([85.229.147.206]) by ipb5.telenor.se with ESMTP; 27 Mar 2017 14:40:00 +0200 Subject: Re: FileChooserDialog constructors taking backend argument To: Daniel Boles References: <8eb2cae3-27a9-715e-a905-42726b018ab9@bredband.net> Cc: gtkmm-list@gnome.org From: Kjell Ahlstedt Message-ID: Date: Mon, 27 Mar 2017 14:40:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1AB167CAD2CF8705F913A059" X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 12:40:07 -0000 This is a multi-part message in MIME format. --------------1AB167CAD2CF8705F913A059 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit > Indeed, even GTK+ 3.22 is not strictly enforcing API freeze; as well > as deprecations, there has recently been some new API added. One in > particular that comes to mind is gtk_flowbox_get_child_at_pos(): > https://git.gnome.org/browse/gtk+/commit/gtk/gtkflowbox.h?h=gtk-3-22&id=9679ef6b00cb087fecf772bb69ab9a2ad7429835 > > Shall we wrap such new methods when they arise? > > I leave that for Murray to decide. I guess that if there will ever be a gtkmm 3.24 release, new API shall be added only there, and not in gtkmm 3.22. --------------1AB167CAD2CF8705F913A059 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
Indeed, even GTK+ 3.22 is not strictly enforcing API freeze; as well as deprecations, there has recently been some new API added. One in particular that comes to mind is gtk_flowbox_get_child_at_pos():
https://git.gnome.org/browse/gtk+/commit/gtk/gtkflowbox.h?h=gtk-3-22&id=9679ef6b00cb087fecf772bb69ab9a2ad7429835
Shall we wrap such new methods when they arise?


I leave that for Murray to decide. I guess that if there will ever be a gtkmm 3.24 release, new API shall be added only there, and not in gtkmm 3.22.
--------------1AB167CAD2CF8705F913A059-- From p_solntsev@meta.ua Thu Mar 30 21:37:45 2017 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 smtp.gnome.org (Postfix) with ESMTP id B35C57648E for ; Thu, 30 Mar 2017 21:37:45 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzDXSQuWxBHv for ; Thu, 30 Mar 2017 21:37:44 +0000 (UTC) X-Greylist: delayed 1369 seconds by postgrey-1.34 at restaurant.gnome.org; Thu, 30 Mar 2017 21:37:44 UTC Received: from smtp-out-1.meta.ua (smtp-out-1.meta.ua [194.0.131.45]) by smtp.gnome.org (Postfix) with ESMTPS id 3425C7625D for ; Thu, 30 Mar 2017 21:37:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=meta.ua; s=mail; h=Content-Transfer-Encoding:Mime-Version:Content-Type:Date:To:Reply-To:From:Subject:Message-ID; bh=lf/p996Eim2rdRHczGTJNKnhwwOZrMBi9GTAUAmJkV4=; b=u1Dqe/L6ASI1uPLEMd6KhFHwwDoLi39bJ8iJSI3o3bcZoW6AtMvajEa0XrKyVd0yN/R1pjLtGXJOiA7AVc4LSiZMPs90de7hf3Xx3pNYvCJuhILd4taW0umlfm91RLcFPOf1txCXT+9i5QuFM4F/WQfgwTdaVrM4qol+eQc8QUGxXllZe2XuyFmmbjY6379IS8JYyFdvJZkcC3Gp8xeVOkCMJbnFPzouL0HgZTNfLSGpnK8yaW7RMjkbzDB3loCCR4emWCfXUHpCnyLbFsNnhGv0PM3gpnvIeVCe/qE3qs+jjLM9Gr9T/0IHatLK2hnQT/dUFK7U5IOd8XjziO/1yw==; Received: from [209.63.187.136] (port=54060 helo=debian-pavlo.cortec.loc) by smtp.meta.ua with esmtpsa id 1cthP8-0008Sb-1j by authid for ; Fri, 31 Mar 2017 00:14:50 +0300 Message-ID: <1490908487.9243.1.camel@meta.ua> Subject: wrapping structure From: Pavlo Solntsev Reply-To: p_solntsev@meta.ua To: gtkmm-list@gnome.org Date: Thu, 30 Mar 2017 16:14:47 -0500 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.5-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Meta-MUA-SendURL: 1 X-MUA-GeoIP: US X-Body-Lines: 16 X-MetaSendRate: 1 X-Method-Of-Forwarding: AUTH X-ServSpool: SSPOOL X-Gen: fb1bfaf59677ebc256143755f1539b44 X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 21:37:45 -0000 Hi, What is the strategy to wrap C struct in mm versions? I Found that in libgdamm some struct's are totally C like. There is a comment there, that struct's should be wrapped. Do you have any idea how to approach this case? Thanks. -Pavlo. -- - Pavlo Solntsev --------------------------------------------- Sent from Evolution on GNU/Debian id="-x-evo- selection-start-marker"> From murrayc@murrayc.com Fri Mar 31 09:20:54 2017 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 smtp.gnome.org (Postfix) with ESMTP id ADC6C761F1 for ; Fri, 31 Mar 2017 09:20:54 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 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_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Zyd67UIncqf for ; Fri, 31 Mar 2017 09:20:53 +0000 (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by smtp.gnome.org (Postfix) with ESMTPS id D36F9761ED for ; Fri, 31 Mar 2017 09:20:53 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id BD67620BF8; Fri, 31 Mar 2017 05:20:51 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 31 Mar 2017 05:20:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=murrayc.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=uGW0RD98be8tjjC wEwjWFB78OzQoJM03tWLFprDnzvA=; b=qmkVOBwEvhbZlQo97k18UvTfhj0Sam0 aPRLr+KnBNnP6ciwAT4ct44twkde0fxHj1215cUp7CPTl4vFXMLb9NDR/7ixrAuk qi2CUuOqUDd5yOUHi4akq8MhpeV7Cf4Cu6piFWEUg7Yqtu5PbhxMlpTu66sCCLBy oOb7wpXOY2z4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=uGW0RD98be8tjjCwEwjWFB78OzQoJM03tWLFprDnzvA=; b=Qx2wfJXc S7jnUh0AsL2E0iezSlYAQgyWFvDkGjB+7Wt95x81uSwOPYWl1FmpK1vzRuzlaScN OVHZiLOgH7PIR3CUUTYjYZTJJ5sUga/39mU7DiuGr8i4yX/9LZkB278SggXYSMid utr5iUAkwyxJRy3hz1FGZjzqBZVwXfblhT+CxqVB4raXlub4DNb+8B2+NZrssKmY rH/Oq5bv9wHb+5hYTvSIcaJOKcE+pGXm3p+YPPpvd/lA6pHop2qHHkcmBdhPwQxg RAjzeeWAZaG4Nk7Yv4eqkAvkkXkuoiuT6NohDh61Xm49ZKKu8zcsgxOJ9TIYRa9e EfjNdU/1Kwg1fA== X-ME-Sender: X-Sasl-enc: t+O+L1qBZGhdvBw/dvDa6VmTKEoTsWpO6hiPSo7y8gzH 1490952051 Received: from murrayc-ThinkPad-X220 (aftr-185-17-205-96.dynamic.mnet-online.de [185.17.205.96]) by mail.messagingengine.com (Postfix) with ESMTPA id AD24D24370; Fri, 31 Mar 2017 05:20:50 -0400 (EDT) Message-ID: <1490952048.15975.2.camel@murrayc.com> Subject: gtkmm 3.24 or new API in gtkmm 3.22? From: Murray Cumming To: Kjell Ahlstedt , Daniel Boles Cc: gtkmm-list@gnome.org Date: Fri, 31 Mar 2017 11:20:48 +0200 In-Reply-To: References: <8eb2cae3-27a9-715e-a905-42726b018ab9@bredband.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.3-0ubuntu0.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 09:20:54 -0000 On Mon, 2017-03-27 at 14:40 +0200, Kjell Ahlstedt wrote: > I leave that for Murray to decide. I guess that if there will ever be > a gtkmm 3.24 release, new API shall be added only there, and not in > gtkmm 3.22. I still find this hard to decide. I am generally infuriated that GTK+ has added (and deprecated) API in a stable release cycle. I cannot understand why on earth they didn't just branch for GTK+ 3.24. I don't like breaking our promise, and confusing our API versions, just because they did, but I guess we have to do something. At least, it's not very much API, I suppose. What would you (plural) prefer, out of: 1. We add (and deprecate) API in gtkmm 3.22.x. 2. We release gtkmm 3.24 with the added (and deprecated) API, though there will (probably, but nobody really knows) be a GTK+ 3.24. -- Murray Cumming murrayc@murrayc.com www.murrayc.com From adiabat@centurylink.net Fri Mar 31 14:16:50 2017 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 smtp.gnome.org (Postfix) with ESMTP id 47CCD761F1 for ; Fri, 31 Mar 2017 14:16:50 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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] autolearn=ham Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1XpImsVCKrh for ; Fri, 31 Mar 2017 14:16:46 +0000 (UTC) X-Greylist: delayed 1203 seconds by postgrey-1.34 at restaurant.gnome.org; Fri, 31 Mar 2017 14:16:46 UTC Received: from mailrelay.embarq.synacor.com (smtp-fo.agate.dfw.synacor.com [205.219.233.7]) by smtp.gnome.org (Postfix) with ESMTPS id 1E8DB761ED for ; Fri, 31 Mar 2017 14:16:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; d=centurylink.net; s=ctl201402; c=relaxed/simple; q=dns/txt; i=@centurylink.net; t=1490968602; h=From:Subject:Date:To:MIME-Version:Content-Type; bh=zijPlLjN9lXkdaY2RMXZoYJm2Fc=; b=FL3/qIxDd9qEkHJ4o+120gieFBgCZlwjeYt89WcDEM8M6lJOo+M2GgfYKMIhAG9N YgT4agN1KVnS2tmIizougG0iSHnK+vHKaMjdnmJxKG/e+kpY57akbQbmDelGOFBs 1beIP9R4TYkoz4TZ1xhyiY2HAZiI3OAgW9is+BsxGlsrLLKBAWkMjfyYqTYaywoj EFjVWUNbYa9tj3tI9MMgVNIu7Cr3QzCcrm9RSyC79Hya7tgqRbZSyde7vF9F8VPE Avu6cCumJ+n+gJp9Dh9RkShbung1keEXLj32eUSsZmbNnnXoZNrPIAfQk4xe9kVe a0bCvz2V5jDxKk2b4fggJQ==; X_CMAE_Category: , , X-CNFS-Analysis: v=2.2 cv=Zf5fDYdA c=1 sm=1 tr=0 a=0vupPmswQCL4Gktzc0HZUA==:117 a=0vupPmswQCL4Gktzc0HZUA==:17 a=N659UExz7-8A:10 a=QK0KsxDMSQLMjmKmt1EA:9 a=pILNOxqGKmIA:10 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 [71.212.31.70] ([71.212.31.70:23432] 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 77/52-18135-9106ED85; Fri, 31 Mar 2017 09:56:42 -0400 From: Goatfather Subject: Detecting deprecated function usage To: "gtkmm-list@gnome.org" Message-ID: Date: Fri, 31 Mar 2017 06:56:41 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 14:16:50 -0000 What must I do to get g++ to complain when it encounters deprecated GTKMM function calls? int main ( int argc, char** argv ) { Glib::RefPtr refApp = Gtk::Application::create (); Gtk::Label label ( "label" ); label.set_alignment ( 1.0, 0.5 ); return ( 0 ); } // g++ -Wall test.cc `pkg-config gtkmm-3.0 --cflags --libs` g++ reports neither warning nor error on the set_alignment reference. I'm using GTKMM 3.20.1 and set_alignment was deprecated in 3.14. -- Saying what we think gives us a wider conversational range than saying what we know. — Cullen Hightower From dboles.src@gmail.com Fri Mar 31 14:35:26 2017 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 smtp.gnome.org (Postfix) with ESMTP id 1AAD07623D for ; Fri, 31 Mar 2017 14:35:26 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPW0lrJZz3ya for ; Fri, 31 Mar 2017 14:35:25 +0000 (UTC) Received: from mail-lf0-f42.google.com (mail-lf0-f42.google.com [209.85.215.42]) by smtp.gnome.org (Postfix) with ESMTPS id E21AA761F1 for ; Fri, 31 Mar 2017 14:35:24 +0000 (UTC) Received: by mail-lf0-f42.google.com with SMTP id x137so45460184lff.3 for ; Fri, 31 Mar 2017 07:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=YNzBG3Uzh4ypXiIkuN2TgKbqYr/VV9XoMEy4ChkIIA8=; b=QTDjSlylH2ymxuyzEg219XfuJeE4Fnsm9t5yCkzP0/FMffNdLMAIiT1wEX8/u9s2aZ mp4rbOnFvpV9EvZcy/RIHEBcRfqeU8oIZ4TGien+GuERHR0Kc2wUNeyc8KEU8sJyGuI+ g8cll5s8hbFSWR2p5NaWwpG0nEdrjathSEZsd39qJe2OJHoQvwIFiRSfYXtgniQ95+x4 7evmgatMp6aSEXhVubio+QqrgbXwvzElR0l+dd+eZBLQRWj5dW4RBnkReMY/N5Gr/h0M GUEGwJjzcnbP5nabZ9zGsLNZ5NJ/CRvM88Y/8p6YC6yvhGWdgBR4uycMp263LLnxyVmu v9Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=YNzBG3Uzh4ypXiIkuN2TgKbqYr/VV9XoMEy4ChkIIA8=; b=qukClu1YSV7IoIcFtJPydc3L1GPnHPRpWo3pWjkQOAnCrqzxJpqY3YlMfLFIjA7grP Q1yefvoaUvCUKERoSHMAAVdtYJpbictyNSBXnW1YAL704BYDl7fNBrjLcvtMdWd9RV3v FSAmSdUHFPHjKnKGr5r8NdBe1Dvgrr+ri1iDbc6m66Pag8y3ZBzy6ai/l18kFDY5efAA fz5zid2JjEbxb6FOMGpPnEkjkh7bY3/9tk8rZFnMAcO2RE4uT4NDM3Z6crBCm4P8rHOv zKRjbRlKVIS6twAouWnTMcL7coaBubN1suYKyQAo0JgfLJfseDL0PAQ7oS4rgbBhambt Ru6Q== X-Gm-Message-State: AFeK/H1noZeTHPCwD0GKJfLXT3Kf3bBuzREWJN1xnp1vjpNpkDAPgpwglBGKgrsmqUtSKLkyDlmE21j+YxzlEA== X-Received: by 10.46.75.2 with SMTP id y2mr1315170lja.103.1490970921755; Fri, 31 Mar 2017 07:35:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.195.80 with HTTP; Fri, 31 Mar 2017 07:35:21 -0700 (PDT) In-Reply-To: References: From: Daniel Boles Date: Fri, 31 Mar 2017 15:35:21 +0100 Message-ID: Subject: Re: Detecting deprecated function usage To: gtkmm-list@gnome.org Content-Type: multipart/alternative; boundary=f403045ea6e8296c0f054c07b8c6 X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 14:35:26 -0000 --f403045ea6e8296c0f054c07b8c6 Content-Type: text/plain; charset=UTF-8 not sure right now about warnings, but I know you can outright remove marked deprecated features - and hence convert them to errors - at the preprocessor stage by defining GTKMM_DISABLE_DEPRECATED --f403045ea6e8296c0f054c07b8c6 Content-Type: text/html; charset=UTF-8
not sure right now about warnings, but I know you can outright remove marked deprecated features - and hence convert them to errors - at the preprocessor stage by defining GTKMM_DISABLE_DEPRECATED

--f403045ea6e8296c0f054c07b8c6-- From adiabat@centurylink.net Fri Mar 31 14:38:05 2017 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 smtp.gnome.org (Postfix) with ESMTP id 821C1761F1 for ; Fri, 31 Mar 2017 14:38:05 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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] autolearn=ham Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJiUVcLsM_wq for ; Fri, 31 Mar 2017 14:38:04 +0000 (UTC) Received: from mailrelay.embarq.synacor.com (smtp-fo.agate.dfw.synacor.com [205.219.233.7]) by smtp.gnome.org (Postfix) with ESMTPS id 64EDF761ED for ; Fri, 31 Mar 2017 14:38:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; d=centurylink.net; s=ctl201402; c=relaxed/simple; q=dns/txt; i=@centurylink.net; t=1490971082; h=From:Subject:Date:To:MIME-Version:Content-Type; bh=3z4etNzLcmrr2yfMk7FmBq43G6Q=; b=HjP/hAsxpZik5T/AynfrOKoPhGxjrz1hlnpd9Vs2pDIxNIwdMUINX9k2jbr2GbLJ T6v/2duusfUgLNe07igEJn7dGgTfOqDx+UB28AkeJ8vRGVnFbETTnBW+hcEEcBoY EQBe8aVfOsy6T20euyuaMCSHjgjkFRCJw4hEAy6pQZBEIALoQsc+hdFHHiq1Zxai 3TndSaMCpket0kAQ9h3HGCzUGugrK+DQNVS4M9PDfXAgvssWiy+q/QchTcOJVsad qXuL9UoAy6+9FXLR3Jpw2Ckr4DF+mkwW07owUsX3ZqQHtuWGmVuK9J7+hBjQa5X3 jyRvMSMIr3VFCYfAzk2eJw==; X_CMAE_Category: , , X-CNFS-Analysis: v=2.2 cv=RZ/SMBlv c=1 sm=1 tr=0 a=0vupPmswQCL4Gktzc0HZUA==:117 a=0vupPmswQCL4Gktzc0HZUA==:17 a=N659UExz7-8A:10 a=aiIX5UjjAAAA:8 a=HfcbfE0iTqJUR_AwvpEA:9 a=pILNOxqGKmIA:10 a=K4UmP72BP_XnEf30ZnvK:22 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: YWRpYWJhdEBjZW50dXJ5bGluay5uZXQ= Authentication-Results: smtp01.agate.dfw.synacor.com smtp.user=adiabat@centurylink.net; auth=pass (LOGIN) Received: from [71.212.31.70] ([71.212.31.70:63124] 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 0F/AA-19884-9C96ED85; Fri, 31 Mar 2017 10:38:01 -0400 Subject: Re: Detecting deprecated function usage To: gtkmm-list@gnome.org References: From: Phil Wolff Message-ID: <9f409df1-4709-9e2b-2c3e-5e09baf72a7d@centurylink.net> Date: Fri, 31 Mar 2017 07:38:00 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 14:38:05 -0000 Thanks — that's exactly what I need. On 03/31/2017 07:35 AM, Daniel Boles wrote: > not sure right now about warnings, but I know you can outright remove > marked deprecated features - and hence convert them to errors - at the > preprocessor stage by defining GTKMM_DISABLE_DEPRECATED > > > > _______________________________________________ > gtkmm-list mailing list > gtkmm-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtkmm-list -- Saying what we think gives us a wider conversational range than saying what we know. — Cullen Hightower From sally@fortetrinity.com Fri Mar 31 15:51:53 2017 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 smtp.gnome.org (Postfix) with ESMTP id 5E5BE761F1 for ; Fri, 31 Mar 2017 15:51:53 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpIy8niJ5tl0 for ; Fri, 31 Mar 2017 15:51:52 +0000 (UTC) Received: from mailer.forteweb.co.uk (mailer.forteweb.co.uk [195.10.252.21]) by smtp.gnome.org (Postfix) with ESMTPS id 91177761ED for ; Fri, 31 Mar 2017 15:51:51 +0000 (UTC) Received: from FORTEWEB02 (web02.forteweb.co.uk [195.10.225.121]) by mailer.forteweb.co.uk with ESMTPA ; Fri, 31 Mar 2017 14:46:46 +0100 Thread-Topic: Your website - Tips thread-index: AdKqJT5eBPstUTuWSTeULVKdQ1l1gw== From: "Sally Webster - Forte Trinity" To: "Gtkmm List Gnome.org" Subject: Your website - Tips Date: Fri, 31 Mar 2017 14:46:48 +0100 Message-ID: <41F0B4F3F12E43BB9FA6BF91F1220B26@FORTEWEB02> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_11BC0_01D2AA2D.A023B2B0" X-Mailer: Microsoft CDO for Windows 2000 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.2.9200.17356 X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 15:51:53 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_11BC0_01D2AA2D.A023B2B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Having problems viewing this email? Click Here to view in a web browser. Forte Trinity Logo and Strap Tech Support Bulletin Briefing Free Advice/Web Analysis for Business 3 Tips For Successful Websites/Top Google Rankings - 1) Look and feel - Is your website a modern cutting edge attractive design? Is it tablet/mobile responsive? Google Warning: If your website has not been updated to latest standards, it may be obsolete, and lose ranking positions 2) Your Home Page - Does it say precisely and concisely what your product or service is? Critical for Search Engine rankings - The text needs to be carefully constructed to maximise keyword/search term relevance 3) Search on Google and Yahoo for your product or service? If you are not highly ranked you are losing over 85% of potential enquires or sales.. Is your website optimised professionally for Search Engines? Call us or complete the online contact form for a free design quality check and/or a Search Engine Optimisation analysis - This service is being offered at no cost A question of design or Search Engine success? We have the answers.... Need help? - Call us for FREE ADVICE/ANALYSIS We will give a no obligation professional opinion Tel: 01942 684040 or or Click Here for contact? Need Proof??? - Try the search test below! Does your Website Enjoy Premium Search Engine Rankings? CASE PROVEN!!! Contact us - You may have nothing to lose except more sales/enquiries..... Wishing you success online, Sally Sally Webster Media Services sally@fortetrinity.co.uk Forte Trinity Limited Features and Benefits Tel: Fax: Email: Web: +44 (0)1942 68 40 40 +44 (0)1942 68 14 21 info@fortetrinity.co.uk www.fortetrinity.co.uk Partners and Technologies This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed and is not intended to be relied upon by any other person without subsequent written confirmation of its contents. As the recipient of this email you are responsible for running a virus check on the content or on any attachments thereto as Forte Trinity cannot be held liable for the misuse of our email address or the malicious attaching of virus files without our knowledge to email appearing to emanate from our domain name. Forte Trinity Ltd accepts no responsibility for information, errors or omissions in this e-mail nor for its use or misuse nor for any act committed or omitted in connection with this communication. If you have received this email in error please notify us immediately by telephone on +44 (0)1942 684040 and ask for Tech Support. Forte Trinity Ltd. | Registered in England and Wales No: 3345091 | VAT No: 704 0794 51 Office Address: The Cyber Suite, Triangle House, The Avenue, Leigh, Lancashire, United Kingdom, WN7 1ES Registered Address: As office Not Interested? Unsubscribe instantly ------=_NextPart_000_11BC0_01D2AA2D.A023B2B0 Content-Type: text/html Content-Transfer-Encoding: 7bit
Having problems viewing this email? Click Here to view in a web browser.

Forte Trinity Logo and Strap

Tech Support Bulletin Briefing

Free Advice/Web Analysis for Business

3 Tips For Successful Websites/Top Google Rankings -

1) Look and feel - Is your website a modern cutting edge attractive design?
Is it tablet/mobile responsive?

Google Warning: If your website has not been updated to latest standards, it may be obsolete, and lose ranking positions

2) Your Home Page - Does it say precisely and concisely what your product or service is?

Critical for Search Engine rankings - The text needs to be carefully constructed to maximise keyword/search term relevance

3) Search on Google and Yahoo for your product or service?

If you are not highly ranked you are losing over 85% of potential enquires or sales..
Is your website optimised professionally for Search Engines?

Call us or complete the online contact form for a free design quality check and/or a Search Engine Optimisation analysis - This service is being offered at no cost

A question of design or Search Engine success? We have the answers....

Need help? - Call us for FREE ADVICE/ANALYSIS

We will give a no obligation professional opinion

Tel: 01942 684040 or or Click Here for contact?

Need Proof??? - Try the search test below!
Does your Website Enjoy Premium Search Engine Rankings?

CASE PROVEN!!!

Contact us - You may have nothing to lose except more sales/enquiries.....

Wishing you success online,

Sally
Sally Webster
Media Services
sally@fortetrinity.co.uk

Forte Trinity Limited Features and Benefits

Tel:
Fax:
Email:
Web:

+44 (0)1942 68 40 40
+44 (0)1942 68 14 21
info@fortetrinity.co.uk
www.fortetrinity.co.uk

 Partners and Technologies

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed and is not intended to be relied upon by any other person without subsequent written confirmation of its contents. As the recipient of this email you are responsible for running a virus check on the content or on any attachments thereto as Forte Trinity cannot be held liable for the misuse of our email address or the malicious attaching of virus files without our knowledge to email appearing to emanate from our domain name. Forte Trinity Ltd accepts no responsibility for information, errors or omissions in this e-mail nor for its use or misuse nor for any act committed or omitted in connection with this communication.

If you have received this email in error please notify us immediately by telephone on +44 (0)1942 684040 and ask for Tech Support.

Forte Trinity Ltd. | Registered in England and Wales No: 3345091 | VAT No: 704 0794 51

Office Address: The Cyber Suite, Triangle House, The Avenue, Leigh, Lancashire, United Kingdom, WN7 1ES
Registered Address: As office

Not Interested? Unsubscribe instantly

------=_NextPart_000_11BC0_01D2AA2D.A023B2B0-- From dknof@gmx.de Fri Mar 31 19:21:20 2017 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 smtp.gnome.org (Postfix) with ESMTP id 958557622B for ; Fri, 31 Mar 2017 19:21:20 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HK_NAME_FM_DR=0.01] autolearn=ham Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2xNUS71hJQS for ; Fri, 31 Mar 2017 19:21:19 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by smtp.gnome.org (Postfix) with ESMTPS id D0CFB76223 for ; Fri, 31 Mar 2017 19:21:18 +0000 (UTC) Received: from berit ([91.97.167.45]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LymHf-1c6AuL1ekx-0168Wz for ; Fri, 31 Mar 2017 21:21:14 +0200 Date: Fri, 31 Mar 2017 21:21:09 +0200 From: "Dr. Diether Knof" To: gtkmm-list@gnome.org Subject: Re: gtkmm 3.24 or new API in gtkmm 3.22? Message-ID: <20170331212109.72ab8850@berit> In-Reply-To: <1490952048.15975.2.camel@murrayc.com> References: <8eb2cae3-27a9-715e-a905-42726b018ab9@bredband.net> <1490952048.15975.2.camel@murrayc.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/M2d=uO_.8Yz3NIFOD57Hx0U"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:1uKojL+864rpkzv2vnrcWGOLtZuMfgExjcB2UEyLVB3G9cepT9o VTIGC/QNBdexqqjfx30bzkutBzo+ojS2ynYuPijRzd/c/rnvZFChMN3CRA2sVbiDARr2Gq0 xkJtXPKpHoshTgliQnS3GQhfZg4weG4Jk1dGQmVNfeIS2hK8AN8SdkNT2F1wHAL3hWeuJ9q uUfdN04CQAy8/VwNEdr3w== X-UI-Out-Filterresults: notjunk:1;V01:K0:H8oPSwkexfo=:S+tiuqiZpTVpLj1YnnJKQ1 IzwP8zRZRAGJOfQDwh47ihOJzTlkOg8rKplEcnCb9ArInOkJMy0AV78m5oYT1+WHro3tHAGsJ LB25Rwvyz+xLhP5K7TuVeLR3fa5F1ut3jzQopQiGSLlUsAP+kso1Ewh0zsEttZBY22WAod+O5 0rhXPHd/1tbVKBPNI6MoQSJMFOlM26OswfNbXZUhvDelububMYONNFgduabqfFN+jAbzLqS3Z vKsjNjOhwFCe0ttYTPCm5Q8YYCaGUt0Vir9NwFTPJj2T/b78joy/WQ2sqzet2lVG+y8L52QKa 2g2cM/2Q7dqqwwNhjsRZgZDm2k/4KhyassbqSJ7GqkzvtxAY7VBE1wPKMd96O3BEEb07dIIb4 cNrdfNOCKmMmKEReo8s3nv4haPshJADmof6jpP7cpxm4vkqngHEfdM9kpcCUxpW2WDGhJeHLK TKyQYrWiAx52XIGh5231HnOh/a2nVSKe34loXFbbSVs58Zh5FdTDIUQhtwNJEBDpjsbjOLBWp 56MSVQ/TCZQEkYxkr4RSLFes8UZ8egQ1InmclzPSl+rfyjD8+7yRM+DfY4QvkWAUhh2xLheKW 22Nvpxdr/Typp4OAQY4Wo+Ma7ZOnh7iQya9nJ9u4SZxuWbxeSlCIEN8Qr14TzOxz/MJLrxMUf 86jLwGWIHUfGH0yjL9GL6x7Z6CrSaRX/t2aTjUoYogIpJtd/EUmFBAj95xbfXGYEIKQVNELgc VvwRkfVRHb5x0/xy3opxAttc63/0pD4pti4dI8fffd/OyuaP8HqIAc9fZKU= X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 19:21:20 -0000 --Sig_/M2d=uO_.8Yz3NIFOD57Hx0U Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, I prefer to add API in gtkmm 3.22.x.=20 I think it is the better choice to make the same =E2=80=9Cerror=E2=80=9D as= gtk but stay with the same numbering then differ from the gtk numbering sc= heme.=20 In the case gtkmm changes to 3.24 whereas gtk stays in 3.22, if the gtk+ ve= rsion 3.24 has another API change, gtkmm would have to change to 3.26, so t= he problem persists. Greetings Diether Knof --Sig_/M2d=uO_.8Yz3NIFOD57Hx0U Content-Type: application/pgp-signature Content-Description: Digitale Signatur von OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAljerCkACgkQjjy4b315IRPPxgEAmTtpmh0z9PLRC5nLRMulAio2 oz1vu8nhbzgVWObZYEwA+wcvIDQhrflFoUnIecHodqs8tjUFfnehYf3s3IT1XINE =0170 -----END PGP SIGNATURE----- --Sig_/M2d=uO_.8Yz3NIFOD57Hx0U-- From dboles.src@gmail.com Fri Mar 31 19:47:41 2017 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 smtp.gnome.org (Postfix) with ESMTP id 967FF7622B for ; Fri, 31 Mar 2017 19:47:41 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no Received: from smtp.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcGcdjmXAFyB for ; Fri, 31 Mar 2017 19:47:40 +0000 (UTC) Received: from mail-lf0-f43.google.com (mail-lf0-f43.google.com [209.85.215.43]) by smtp.gnome.org (Postfix) with ESMTPS id 812ED76223 for ; Fri, 31 Mar 2017 19:47:40 +0000 (UTC) Received: by mail-lf0-f43.google.com with SMTP id z15so49066499lfd.1 for ; Fri, 31 Mar 2017 12:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=/OWA7jDFKvLKgQhohuEp8oTBt3vzqJrh0p7aNyTxu7w=; b=n7jGzBLWHOmuLH96ge4ekGkx8gRAsoeXc2w0yNEAKwZZXGuLMsGM9BWif4w4AZHzdx 6NdS89ww8N3NIvvGROzsGdlsdeivUwbm7XRTgswy5viyWeAnGriT12R+LQZugWefF0/F 2ICmZV+G2U2YJ5dnSEdnySepeiy/HnmrnWFF6xmJikYsbCkxDPkv16xZ95X3zdj0bGWB armeivwUjymIoEyX4EhxIM+Ecci2IZ3CCauldsYxSGA/bugWA1AugO9FveQVslZnpdaR YyMC/wKYTQy7wGXOEGEti8NGIBFVSY7a3yN6V8f3wOJFvJZWa/D2WFKYHQKSSGgjXwc/ OSig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=/OWA7jDFKvLKgQhohuEp8oTBt3vzqJrh0p7aNyTxu7w=; b=ZAaIttoIkkokGcK3qlnnEK45y6OuJW1H/Wa/O77VT2sSiV22WaYXz7WYvXcC59rK7H a0Xiv3DWZ1YDAg4Eixcsz9n7XFLf6a/+hmD9B0nODmMpGBeWCXjJKun9Sr8PoMHsGsi3 MJqTJ5irHZGLGFIP6zmIu2lLfsUAIvlzz1CAn7ZcgPsZ5ODMmuZUVKoyoMcDuWtPfphj jdMehwtOy0kwfQW3gjttHzlTQOFQKVuZxSyX+aBQwi+2WrYcup3q+gBwPMX1mb/vLNo1 yejU+jLqFhXAyzHyI1dUxydwYNOhNoGRX07NeVJWT/Are2TEn9FXaVRAUzEYVjs2mnK7 aPpA== X-Gm-Message-State: AFeK/H0/U2JaKxTmTIFzFf9fItilvcq/wTNOv8yKY9xztmJ3RAdorPJc1hVWj/5E5nNMPOWhykPEVhxi02h/fQ== X-Received: by 10.25.217.153 with SMTP id s25mr1337356lfi.8.1490989657542; Fri, 31 Mar 2017 12:47:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.195.80 with HTTP; Fri, 31 Mar 2017 12:47:36 -0700 (PDT) In-Reply-To: <20170331212109.72ab8850@berit> References: <8eb2cae3-27a9-715e-a905-42726b018ab9@bredband.net> <1490952048.15975.2.camel@murrayc.com> <20170331212109.72ab8850@berit> From: Daniel Boles Date: Fri, 31 Mar 2017 20:47:36 +0100 Message-ID: Subject: Re: gtkmm 3.24 or new API in gtkmm 3.22? To: gtkmm-list@gnome.org Content-Type: multipart/alternative; boundary=94eb2c0638f0e6d5e4054c0c146f X-BeenThere: gtkmm-list@gnome.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: gtkmm general discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 19:47:41 -0000 --94eb2c0638f0e6d5e4054c0c146f Content-Type: text/plain; charset=UTF-8 I would agree with Dieter. But by all indications I've seen, there specifically will not be any GTK+ versions beyond 3.22. The idea is that 3.22 is the v3 version of 2.24 - the final 'minor' release of its kind, which will now only receive an arbitrary number of point releases, until its LTS ends. 2.24 is now on point release .31 This isn't to say that adding/deprecating API in 3.22 is good, but it's what we've got. If GTK+ manages to follow its own plan as laid out in the latest set of versioning blog posts, then we're not going to get a 3.24 or 3.26 or anything. Personally, I don't know quite how to feel. I like how GTK+ 3 is trying to be actually stable - at least, more so, if we recall the huge changes to theming that arrived clumsily just a couple of even minor releases ago. But I feel like 3 could do with some more *measured* changes to API, worthy of a new minor release, which will now (ideally!) be harder to get into 3.22. As for GTK+ 4, right now it is exciting more in theory than practice, as a lot has yet to be worked out, and some 'cleanups' have killed functionality that I'm loathe to give up without any sign that it'll be replaced. Oh well - I'll just keep doing what I can to cherry-pick useful changes from GTK+ 4 to 3.22, when the original authors don't. and hey, for whatever it indicates: GTK+ 4 has just hit a new milestone tonight with the release of v 3.90 --94eb2c0638f0e6d5e4054c0c146f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would agree with Dieter. But = by all indications I've seen, there specifically will not be any GTK+ v= ersions beyond 3.22. The idea is that 3.22 is the v3 version of 2.24 - the = final 'minor' release of its kind, which will now only receive an a= rbitrary number of point releases, until its LTS ends. 2.24 is now on point= release .31

This isn't to say that adding/deprecating API in 3.22 is good, b= ut it's what we've got. If GTK+ manages to follow its own plan as l= aid out in the latest set of versioning blog posts, then we're not goin= g to get a 3.24 or 3.26 or anything.

Personally, I don't know quite how to fe= el. I like how GTK+ 3 is trying to be actually stable - at least, more so, = if we recall the huge changes to theming that arrived clumsily just a coupl= e of even minor releases ago. But I feel like 3 could do with some more = measured=C2=A0changes to API, worthy of a new minor release, which will= now (ideally!) be harder to get into 3.22. As for GTK+ 4, right now it is = exciting more in theory than practice, as a lot has yet to be worked out, a= nd some 'cleanups' have killed functionality that I'm loathe to= give up without any sign that it'll be replaced. Oh well - I'll ju= st keep doing what I can to cherry-pick useful changes from GTK+ 4 to 3.22,= when the original authors don't.

<= /div>
and hey, for whatever it indicates: GTK+ 4 = has just hit a new milestone tonight with the release of v 3.90
--94eb2c0638f0e6d5e4054c0c146f--