On Sun, 2022-01-16 at 19:18 +0100, Kjell Ahlstedt via gtkmm-list wrote:
> The www.gtkmm.org website has not been updated for a long time. There
> are a number of gtkmm issues about obsolete information. I don't know
> how to update the website. The source code is stored at
>
Sorry, I forgot to answer your email to me about this. I will check how it works and get back to you. I have previously tried using gitlab for this but it sounds like you have had more luck.On 16 Jan 2022 19:18, Kjell Ahlstedt via gtkmm-list wrote:
The www.gtkmm.org website has not been
g here is a serious achievement.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
at the
> meson.build file in the package's top directory.
>
> Gtkmm itself can't be built with Meson yet. That's several months
> ahead, I think.
You might consider, if you like, not removing autotools from the other
builds until gtkmm uses Meson, if you remove autotools. Th
le working on the
code. Thanks for pursuing this.
Where would I go to find basic instructions for using Meson with gtkmm
and co. For instance, how would I build with or without our strict
warnings as errors?
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
weird build-
time thing. Feel free to do what feels right and feel free to make it
more sane.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
et, and we have advised distros
not to package them.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
On Thu, 2018-04-12 at 21:10 +0100, Jonathan Wakely wrote:
> On 12 April 2018 at 21:02, Murray Cumming wrote:
> > I've just released a version of libsigc++-3.0 (currently unstable)
> > that
> > requires C++17. This means that gtkmm-4.0 (currently unstable)
> > requires
&
I've just released a version of libsigc++-3.0 (currently unstable) that
requires C++17. This means that gtkmm-4.0 (currently unstable) requires
C++17 too. I should have mentioned it first, but I think this is fine.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
_bug.cgi?id=495762#24
Sure. That should be fine.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
: Document drag_dest_set(Gtk::DestDefaults, Gdk::DragAction).
(Kjell Ahlstedt)
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
/GNOME
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
mention GtkObject in comments.
(Kjell Ahlstedt)
* Glib::Variant: Hide namespace Glib::detail from Doxygen
(Kjell Ahlstedt) Bug #787698 (Daniel Boles)
* Glib::Variant: Slightly elaborate Variant docs.
(Daniel Boles) Bug #778219 (Daniel Boles)
--
Murray Cumming
murr...@murrayc.com
On Tue, 2017-10-24 at 10:48 +0200, Kjell Ahlstedt wrote:
> 1. Cairo::make_refptr_for_instance(nullptr)
This seems obviously better, or maybe something even simpler.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing l
hich would probably be sensible from the
> outset.
[snip]
I think that would be even more confusing.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
On Thu, 2017-09-14 at 23:17 +0200, Murray Cumming wrote:
> On Wed, 2017-04-05 at 16:00 +0200, Murray Cumming wrote:
> > On Sat, 2017-04-01 at 09:22 +0200, Kjell Ahlstedt wrote:
> > > I agree with Diether and Daniel: Let's do as gtk+ does, even
> > > though
> > &g
On Wed, 2017-04-05 at 16:00 +0200, Murray Cumming wrote:
> On Sat, 2017-04-01 at 09:22 +0200, Kjell Ahlstedt wrote:
> > I agree with Diether and Daniel: Let's do as gtk+ does, even though
> > they break the rules.
>
> OK. Then I don't object anymore. Thanks for being patient.
On Fri, 2017-07-28 at 12:46 +0100, Russel Winder wrote:
> On Fri, 2017-07-28 at 12:54 +0200, Murray Cumming wrote:
> > […]
> >
> > Maybe we could try having build file for Meson alongside the
> > autotools
> > files. Patches would be welcome. Someone m
a branch
for a while until it works. I suggest starting with glibmm.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
in the *mm
> projects?
I have not looked at meson yet. I don't know what support would be
needed.
I guess someone should try to create a hello world project with meson
and gtkmm.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list
expected.
> However, in many or perhaps most cases, there is an unset() to make
> things simpler, and IMO that is better API and should be offered/used
> where possible.
Yes, the unset_*() methods are more obvious. We just need to mention
them in the documentation.
--
Murray Cumming
m
for themselves; I suspect the
> answer might be no. Still interested in any thoughts.
I'm not aware of any efforts to make this easier. It does bother me
too.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
What is wrong' and no more info that that. It
> doesn't provide any fuel for discussion, and frankly it's starting to
> feel like spam.
Daniel, please be more patient if you choose to respond. This person is
asking for help. Your first two sentences would have been enough.
If you also
this. Maybe it would be best to try to reduce this to a
simple test case.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
method.
(Kjell Ahlstedt)
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
.
(Vyacheslav Yurkov) Bug #781818
Documentation:
* RefPtr: Clarify comment about undefined behaviour.
(Daniel Boles)
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman
On Sun, 2017-05-21 at 15:03 +0100, Daniel Boles wrote:
> On 21 May 2017 at 14:29, Murray Cumming <murr...@murrayc.com> wrote:
> > We've already used move/r-value-references in several places, but
> > not
> > for string arguments.
I assume that std::string's own mov
o it may not be a suitable replacement for
> ustring.
I guess std::string_view deals with bytes, regardless of their
encoding, just as std::string does. If we keep using Glib::ustring,
we'd maybe want to have a Glib::ustring_view, at least as just a type
alias.
--
Murray Cumming
murr...@murrayc.co
On Mon, 2017-05-29 at 19:22 +0100, Daniel Boles wrote:
> On 29 May 2017 at 15:32, Murray Cumming <murr...@murrayc.com> wrote:
> > On Fri, 2017-05-26 at 22:11 +0100, Daniel Boles wrote:
> > > There are a few uses of the GLib typedef gsize in glibmm et al.
> > >
+ standard type.
Yes, that sounds good. Thanks.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
* Proxy: Wrap call() and call_sync() methods.
(Vyacheslav Yurkov) Bug #781818
gmmproc:
* Use of static_cast<> instead of C-style casts.
(Murray Cumming)
Build:
* Fix the build on MacOS, where glib doesn't have gdesktopinfo.
(John Ralls) Bug #781947
* Really use desktopappinfo.hg
://www.gtkmm.org
*** Changes
3.91.0 (unstable):
Distro packagers should probably not package this yet.
Gdk:
* Improve Gdk::Event, creating a class hierarchy.
(Mark Vender, Kjell Ahlstedt) Bug #135978
* Cursor: Change CursorType to Cursor::Type.
(Murray Cumming)
* Device: Change DeviceType
inter, you could try to fix
it. If that shows why it should still be a pointer, it would be nice to
have a comment saying that. Thanks.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome
t that would be an issue for the C API, right?
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
might start taking std::string_view with C++17 instead of
std::string and this might largely take care of this.
> Assuming nothing can be done here, if anyone can think of any other
> cases where we could make use of move semantics, that'd be a nice
> consolat
this, in gtkmm 3,
Gtk::RESPONSE_OK
into this, in gtkmm 4:
Gtk::Dialog::Response::OK
without also polluting the API with this
Gtk::Dialog::OK
Using an old-style enum would let us have this:
Gtk::Dialog::RESPONSE_OK,
(and Gtk::Dialog::Response::RESPONSE_OK)
which is still an improvement, but not quite
k
> and probably post on the bugs to double-check whether they're
> suitable for the 2-52 branch.
I'd like to release 2.52.0 soonish, so that would be helpful. Thanks.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
On Fri, 2017-04-28 at 14:34 +0200, Murray Cumming wrote:
> On Fri, 2017-04-28 at 13:25 +0200, Kjell Ahlstedt wrote:
> > On 2017-04-28 09:08, Murray Cumming wrote:
> > > On Fri, 2017-04-28 at 08:31 +0200, Kjell Ahlstedt wrote:
> > > > Why does Gtk::PackOptions af
On Fri, 2017-04-28 at 13:25 +0200, Kjell Ahlstedt wrote:
> On 2017-04-28 09:08, Murray Cumming wrote:
> > On Fri, 2017-04-28 at 08:31 +0200, Kjell Ahlstedt wrote:
> > > Why does Gtk::PackOptions affect only horizontal expansion and
> > > alignment? Look for instance at
On Fri, 2017-04-28 at 08:31 +0200, Kjell Ahlstedt wrote:
> On 2017-04-27 12:31, Murray Cumming wrote:
> > Thoughts? Should we remove these gtkmm-specific
> > Box::pack_start()/pack_end() methods anyway? That will still have
> > the
> > same change-of-beha
master branch of
libgdamm (the libgdamm-6.0 API) builds with the master branch of libgda
(the libgda-6.0 API) and the master branch of glibmm (the glibmm-2.54
API).
At least, it's meant to.
Maybe you are sometimes talking about distro package versions (Debian,
Ubuntu, Fedora?) and sometimes a
On Thu, 2017-04-27 at 14:08 -0500, Pavlo Solntsev wrote:
> Thanks.
>
> For me it is confused to see one version in the file name and another
> inside.
I'm sorry. I don't understand. What change are you suggesting? Maybe a
patch would make that clearer. Thanks.
Murray
On Thu, 2017-04-27 at 12:31 +0200, Murray Cumming wrote:
> The gtk_box_pack_start()/pack_end() API changed slightly,
> meaning that our C++ pack_start()/pack_end() convenience overloads
> can
> no longer have a default value for our PackOptions convenience enum:
> https://git.g
t; Or maybe I missed something.
> The recent package is libgda-5.0 therefore it looks like a typo for
> me.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
On Thu, 2017-04-27 at 12:27 -0400, Bill William wrote:
> fair enough... but, which part of gtk defines how the XML maps to the
> GUI objects? gtk+, gtkmm, or glade?
GtkBuilder in GTK+, and probably parts of the widgets themselves.
--
Murray Cumming
murr...@murrayc.com
www.murra
matic layout and always has.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
t glibmm-2-52 should be
> compatible with glib 2.54.
Yes, that would be nice.
Thanks.
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
it:
box.pack_start(child, Gtk::PACK_SHRINK).
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
ason.
> I made a simple patch to implement this. I may try
> to help more if it is useful. Let me know.
Please add the patch to a bugzilla bug:
https://bugzilla.gnome.org/page.cgi?id=browse.html=libgdamm
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
On Wed, 2017-04-19 at 10:30 +0100, Jonathan Wakely wrote:
> On 19 April 2017 at 09:37, Murray Cumming wrote:
> > In the ABI-breaking versions of glibmm and gtkmm, we have recently
> > changed the enums to be C++11 "enum class"s. This is generally a
> > welcome
m to group the values together?
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
stable release. However, we cannot break ABI.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Debian. However, this
suggests that the Ubuntu libgdamm package would be a good start for a
debian package.
> BTW, do you still support Glom?
I "support" Glom as much as I ever did - which is not very much.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
__
On Sun, 2017-04-09 at 07:20 +0100, Daniel Boles wrote:
> On 5 April 2017 at 15:00, Murray Cumming <murr...@murrayc.com> wrote:
> > On Sat, 2017-04-01 at 09:22 +0200, Kjell Ahlstedt wrote:
> > > I agree with Diether and Daniel: Let's do as gtk+ does, even
> > tho
mm/log/?h=gtkmm-3-22
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
On Tue, 2017-04-04 at 15:09 +0100, Jonathan Wakely wrote:
> On 4 April 2017 at 14:52, Murray Cumming wrote:
> > Any ideas about how we should support C++17 in gtkmm-3.0 without
> > losing
> > C++11/14 compatibility and without breaking ABI?
>
> Replace all dynam
Any ideas about how we should support C++17 in gtkmm-3.0 without losing
C++11/14 compatibility and without breaking ABI?
Or should we require C++17 for later gtkmm-3.0 versions?
Noticed here:
https://bugzilla.redhat.com/show_bug.cgi?id=1438766
--
Murray Cumming
murr...@murrayc.com
hat 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
murr...@murrayc.com
www.mu
On Wed, 2017-03-22 at 10:04 +, 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
murr...@murrayc.com
www.murrayc.
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
e 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.
Th
about that. I've changed it as you suggest:
https://git.gnome.org/browse/gtkmm/commit/?id=422c202a31740d2d52c045e97
975b4b7a9f15be4
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
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=fb1906fe
he vfuncs. And the
> default constructor, which uses GlibmmIOChannel, must be removed, I
> suppose.
That makes sense. Thanks.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gn
a test case showing how to use
this feature?
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Comments?
The change in application code is at least simple. It seems fine to me.
Thanks.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
instead of a function pointer.
(Kjell Ahlstedt)
Documentation:
* Demos: Remove obsolete text from the TextView demo
(Kjell Ahlstedt)
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https
On Wed, 2016-11-16 at 13:56 +0100, Murray Cumming wrote:
> > > * glibmm-2.52 instead of glibmm-2.4
> > > * cairomm-1.14 instead of cairomm-1.0
>
> This is now cairomm-1.16 instead.
>
> > > * pangomm-2.42 instead of pangomm-1.4
> > > * atkmm-2.26 i
akes a baseline.
(Murray Cumming)
Gdk:
* Device: Remove grab() and ungrab().
(Kjell Ahlstedt)
* DeviceManager: Remove list_devices().
* Display:
- Add is_composited() and is_rgba().
- Remove get_device_manager().
(Kjell Ahlstedt)
* Add DrawContext.
(Kjell Ahlstedt)
* DrawingContext:
: Rename some vfuncs to add _full().
(Murray Cumming)
Documentation:
* ActionMap:
- ActivateSlot: Mention add_action_bool().
- ActivateWithParameterSlot: Be more specific.
(Daniel Boles) Bug #77
Build:
* Update the Visual Studio project files.
(Chun-wei Fan)
* Some minor cppcheck fixes
?
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
++14.
(Murray Cumming)
* Use glibmm-2.52 instead of glibmm-2.4,
pangomm-2.42 instead of pangomm-1.4,
and atkmm-2.26 instead of atkmm-1.6.
Note that, via, glibmm, we now use libsigc++-3.0 instead
of libsigc++-2.0.
(Murray Cumming)
* Remove deprecated API.
(Kjell Ahlstedt)
* Add default
there is no
glib 3.0.
Build:
* Require C++14.
(Murray Cumming)
* Use libsigc++-3.0 instead of libsigc++-2.0.
https://www.murrayc.com/permalink/2016/03/07/libsigc-3-0-very-variadi
c/
(Murray Cumming)
* Remove lots of deprecated API.
(Kjell Ahlstedt)
Gio:
* BufferedInputStream, InputStream
For gtkmm 4 (well, in the corresponding glibmm), we are thinking of
replacing Glib::RefPtr with std::shared_ptr:
https://bugzilla.gnome.org/show_bug.cgi?id=755037
This is a large change so I'm mentioning it here too. It shouldn't
affect application code much if it works.
--
Murray Cumming
murr
On Mon, 2016-11-14 at 11:08 +0100, Murray Cumming wrote:
> > * glibmm-2.52 instead of glibmm-2.4
> > * cairomm-1.14 instead of cairomm-1.0
This is now cairomm-1.16 instead.
> > * pangomm-2.42 instead of pangomm-1.4
> > * atkmm-2.26 instead of atkmm-1.6
> > * gtkmm-3
On Mon, 2016-11-14 at 10:51 +0100, Murray Cumming wrote:
> * glibmm-2.52 instead of glibmm-2.4
> * cairomm-1.14 instead of cairomm-1.0
> * pangomm-2.42 instead of pangomm-1.4
> * atkmm-2.26 instead of atkmm-1.6
> * gtkmm-3.0 instead of gtkmm-2.4
I mean gtkmm-4.0 instead of gtkmm-3
On Thu, 2016-11-10 at 12:15 +0100, Murray Cumming wrote:
> Because we are creating a new parallel-installable gtkmm ABI (gtkmm-
> 4.0), for use with GTK+ 4.0, this is a fairly good time to do the
> same
> with glibmm, though glib will not have a new ABI at this time.
>
> That le
, but I don't see a better alternative. We can't call it glibmm-
3.0 because that would cause problems when there is a glib-3.0 one day.
Any objections?
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
I in the master branch. I guess we have to do
> the same in gtkmm whether we like it or not, if we want gtkmm to be
> compatible with gtk+'s master branch. Is there a reasonable
> alternative?
> Kjell
Agreed. Anything else would be even more confusing.
--
Murray Cumming
murr...@
On Mo, 2016-09-26 at 22:26 +0200, Murray Cumming wrote:
[snip]
> I don't think it's likely to work so I'd rather just wait and see
> what
> actually happens. At the least, it just looks like a suggestion that
> they want to start working more now on a parallel-installable GTK+ 4.
On Di, 2016-09-27 at 01:27 +0100, Chris Vine wrote:
> On Mon, 26 Sep 2016 22:26:01 +0200
> Murray Cumming <murr...@murrayc.com> wrote:
> >
> > On Fr, 2016-09-23 at 16:51 +0200, Kjell Ahlstedt wrote:
> > >
> > > Gtk+ has announced a new versioning sch
I'm happy for us to try targeting GTK+ 4, but I wouldn't do that in git
master before GTK+ 3.9/4 is in git master.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Could you please subscribe to the full mailing list, so we don't see
these odd email subjects when you reply.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman
On Do, 2016-08-11 at 19:05 +0200, Kjell Ahlstedt wrote:
> Den 2016-08-09 kl. 19:28, skrev Kjell Ahlstedt:
> > Den 2016-08-05 kl. 09:45, skrev Murray Cumming:
> > > Maybe we could just remove any sentence that includes "g_free".
> > > We
> > >
sentence, but I guess it would be worth it.
Alwin, thanks for mentioning these documentation errors.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
ll compilers relevant to me.
>
> Best wishes,
> Christoph
>
> Murray Cumming <murr...@murrayc.com> schrieb am Do., 7. Juli 2016 um
> 12:19 Uhr:
> > Our current stable versions require C++11. Does anybody object to
> > us
> > requiring C++14 for the current
it.gnome.org/browse/gtksourceviewmm
You shouldn't need to write the documentation inline in the .hg file
unless you are significantly rewriting it. gmmproc generates
documentation based on the C documentation. But I didn't bother to
remove the inline documentation to check that that is wor
noticed that both libgdamm and libgda-uimm needed some
> fixes in order to build. They have not kept up with the latest
> changes in libgda. Would it be a good idea for me to update them?
I wouldn't waste time on them, if I was you.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
such as decltype(auto) and std::make_unique().
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
achieved?
Try putting it in a pair first. For instance:
std::pair<Glib::ustring, Glib::ustring> thing = row[columns.col];
auto str = thing.first;
That might also work like this:
const std::pair<Glib::ustring, Glib::ustring>& thing =
row[columns.col];
const auto
eases, but not when comparing stable releases.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
ng your code down to the smallest possible example that
reproduces the problem.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
ate() method and
calling load_from_*(), like the implementation of the protected
create_*() methods:
https://git.gnome.org/browse/gtkmm/tree/gtk/src/printsettings.ccg#n77
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-li
On Fri, 2016-04-22 at 09:22 +0100, Russel Winder wrote:
> On Mon, 2016-04-18 at 19:57 +0200, Murray Cumming wrote:
> […]
> > On debian, it's actually coming from the libsigc++ pkg-config file,
> > as
> > I think you'll find when you do this:
> > $ pkg-config sigc++-
On debian, it's actually coming from the libsigc++ pkg-config file, as
I think you'll find when you do this:
$ pkg-config sigc++-2.0 --cflag
They have done this against our wishes:
https://bugzilla.gnome.org/show_bug.cgi?id=755750#c13
This is very much a distro-specific problem that you should co
that manually in their own place?
Yes. Adding it as CFLAG from pkg-config would cause this very problem.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
=c++14 or
> later.
> Does anyone have an idiomatic way of not allowing pkg-config to
> enforce
> the -std=c++11?
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mail
On Mon, 2016-02-08 at 21:50 +0100, Murray Cumming wrote:
> The more I see how awkward my suggestion can be, the more I hesitate
> to
> deprecate Gtk::manage() even if we have support unique_ptr<>.
I plan to commit this, without deprecating Gtk::manage(), but probably
not for gtk
es, if possible.
>
> Kjell
>
> ___
> gtkmm-list mailing list
> gtkmm-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtkmm-list
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
__
I will run this on glibmm first, quite soon. Let me know if there are
any patches that you want to get in first, before I cause merge/rebase
conflicts.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list
1 - 100 of 2112 matches
Mail list logo
