Re: Why isn't the constructor of Gtk::Application public?

[Chris Vine via gtkmm-list]

On Tue, 28 Sep 2021 22:26:46 +0200
 wrote:
> So because objects of a classes inheriting from GObject are held by
> Glib::RefPtr's Gtk::Application's are also held in Glib::RefPtr's?
> 
> I think smart pointer should only be used if they are needed. Probably
> this is only my philosophy and if you discussed it already i will not
> insist of it being public.:)

(1) I haven't discussed it, as far as I am aware, or if I have it was
in the mists of time.  I recall that the matter has been discussed.  The
origins of the gtkmm wrappings go back nearly 20 years.  Things are as
they are, and in real life consistency is important.

(2) Your posting is public, which is fine. There is nothing
inappropriate in it.

> btw. now that Glib::RefPtr is a std::shared_ptr you could use
> std::make_shared().
> (also my philosophy)

That wouldn't work.  GObject and cognates are the materialization of an
object system for C, and GObject objects are constructed by their C
constructors.  glibmm makes a brave attempt at wrapping that within the
C++ object system, but that is all it does.  On that note, the
conversion of Glib::RefPtr to std::shared_ptr seems silly to me: C++
intrusive pointers interfacing with GObject reference counting are
fine.  But I have not used gtkmm for a number of years (and C++ does
not have the buzz it used to) so it is possible I am missing something
new about glibmm.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Why isn't the constructor of Gtk::Application public?

[Chris Vine via gtkmm-list]

On Tue, 28 Sep 2021 18:26:51 +0100
Rob Pearce  wrote:
> On 28/09/2021 15:07, pho...@autistici.org wrote:
> > If the constructor would be public we and the compiler wouldn't have to
> > deal with smart pointers:
> >
> > Gtk::Application app("org.example");
> > return app.make_window_and_run(argc, argv);
> >
> > The Gtk::Application::create function just passes the argument to the
> > constructor and stores the Gtk::Application in a Glib::RefPtr. Is there
> > a reason why the constructor isn't public?
> 
> At a guess... precisely to prevent you doing what you suggest!
> 
> Statically allocated complex class instances are seriously problematic 
> in C++ because the order of initialisation and instantiation of "static" 
> objects is very poorly defined. There were many places in GTKmm 2.4 
> where objects that could be instantiated statically would simply break. 
> The correct approach was always to dynamically generate a singleton and 
> use that, thus providing a guaranteed order of creation.

I doubt anyone is going to attempt to construct a Gtk::Application
object statically, and the fact that such objects are held by
Glib::RefPtr doesn't stop you doing so anyway, in the sense that you
could attempt to call Gtk::Application::create() before main is
entered in order to initialize a RefPtr in namespace scope.  That
almost certainly wouldn't work though because you can't initialize GTK
statically.

I suspect the real reason is that GtkApplication derives from
GApplication which derives from GObject rather than GInitiallyUnowned.
Such objects are conventionally held by Glib::RefPtr in the gtkmm
wrapper.  Types which derive from GInitiallyUnowned, such as widgets,
conventionally do not.  It didn't necessarily need to be that way (that
is an old debate) but that's the way it is.  Consistency is good.

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

Re: Why can't information be passed using the Dispatcher?

[Chris Vine via gtkmm-list]

On Thu, 17 Sep 2020 13:48:55 -0400
Jackson Campolattaro via gtkmm-list  wrote:
> Hello,
> 
> `Glib::Dispatcher` has syntax similar to a void signal, but there are cases
> where it would be convenient to pass information between threads using the
> same syntax. Obviously returning anything would be impossible, but is there
> a technical reason not to have one way communication (e.g.
> `Glib::Dispatcher` that can be used a little like a
> `sigc::signal`)? Obviously the user would have to be especially
> careful about scope (don't pass references to things that might be deleted
> before the other thread can act on the signal). In some cases it might also
> make sense to pass a mutex alongside the value.
> 
> Is this functionality not provided as part of libsigc++ just because it's
> unsafe-by-default, or is there a deeper problem? According to this old
> thread ,
> libsigcX  provides something
> similar, but it looks like it hasn't been updated in a very long time.
> 
> If there's not an obvious issue that makes it impossible, I'll probably
> write myself a wrapper class that gives me this kind of behavior.

Glib::Dispatcher uses a pipe to synchronize between threads.  You could
possibly serialize objects and send them over the pipe in a C++
standard non-conforming way (that would work with an int) but why
bother?  Just use an asynchronous queue as suggested, which is pretty
much fool-proof and will work with non-trivial objects (using "trivial"
in its C++-standard sense).
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Alternative to sigc::mem_fun

[Chris Vine via gtkmm-list]

On Tue, 19 Jun 2018 17:00:35 +0100
Daniel Boles via gtkmm-list  wrote:
> I still don't see the problem. There is an overload that takes a reference
> instead and should be in each case.
> 
> So, for
> 
> *sigc::mem_fun * *(* *T_obj * * *_A_obj*,
> 
> 
> *T_return(T_obj2::*)(T_arg1, T_arg2) * *_A_func*
> 
> *)*
> 
> you should substitute
> 
> *sigc::mem_fun * *(* *T_obj & * *_A_obj*,
> 
> 
> *T_return(T_obj2::*)(T_arg1) * *_A_func*
> 
> *)*
> 
> 
> These are immediately adjacent in the docs:
> https://developer.gnome.org/libsigc++/stable/group__mem__fun.html#ga0df7af9f32990cc624c4bb60782b4f78
> 
> or did I miss something else and this doesn't work for you somehow?

The poster is confusing sigc::mem_fun() with std::mem_fun().

To the OP: from C++11 onwards, in place of std::mem_fun() use either
std::bind or a lambda expression.  None of this affects sigc::mem_fun().
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: can't run multiple gtkmm programs in Window 7

[Chris Vine]

On Thu, 17 May 2018 07:37:15 + (UTC)
John Siino  wrote:
> I can't run multiple gtkmm programs in Window 7.  If I try to run different
> compiled gtkmm gcc compile exe files, only the first one runs.  A second
> exe won't start.
> John
 
If these are programs that you have written yourself, perhaps you are
passing the same application id for each to Gtk::Application.
Application id's must normally be unique.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: get/set wrap methods.

[Chris Vine]

On Sat, 24 Feb 2018 10:46:49 -0600
Pavlo Solntsev  wrote:
> By mistake I made the bug visible to llibgdamm developers only. I
> added your email and other email. You should be able to it. It looks
> like only libgdamm developer can change visibility of the bug. If you
> still have problem - let me know and I will resubmit as a new one.
> 
> -Pavlo Solntsev

What on earth is the point of restricting bug visibility to any one set
of people?  It seems completely pointless, and also counterproductive.

Make it a public bug report.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Event if a widget becomes "realized" / was drawn

[Chris Vine]

On Tue, 26 Dec 2017 11:13:25 +0100
Klaus Rudolph  wrote:
> Is there an event which I can bind a signal handler to which fires if
> a widget becomes visible / "realized". I want to do some thing AFTER
> the widget is drawn.
> 
> Thanks!

Amongst Gtk::Widget's numerous signals is a signal_realized signal,
which probably does what you want:
https://developer.gnome.org/gtkmm/stable/classGtk_1_1Widget.html
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Why button press event only reacts on double click?

[Chris Vine]

On Tue, 26 Dec 2017 10:56:34 +0100
Klaus Rudolph  wrote:
> The function "signal_button_press_event()" reacts only if I double
> click the button. Is it possible to react also on a single press
> event?
> 
> #include 
> #include 
> #include 
> 
> class ExampleWindow: public Gtk::Window
> {
>  Gtk::Button button;
>  public:
>  ExampleWindow(): button("Hallo")
>  {
>  add(button);
>  button.signal_button_press_event().connect( [this]( 
> GdkEventButton* ev)->bool{ std::cout << "Press" << std::endl; return 
> true; });
>  }
> };
> 
> 
> int main(int argc, char* argv[])
> {
>  Gtk::Main kit(argc, argv);
> 
>  ExampleWindow window;
> 
>  window.show_all_children();
>  Gtk::Main::run(window);
>  return 0;
> }

button-press-event is a GDK event and is concerned principally with
mouse buttons. You want the clicked signal.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: gtkmm-4: Widget wrappers can't be deleted like in gtkmm-3

[Chris Vine]

On Fri, 1 Dec 2017 13:35:01 +0100
Kjell Ahlstedt  wrote:
> Changes in gtk+-4 make it impossible to delete C++ widget wrappers
> like it's done in Gtk::Object::~Object() and 
> Gtk::Object::_release_c_instance(). See 
> https://bugzilla.gnome.org/show_bug.cgi?id=773642#c20. How can we do
> it in gtkmm-4? Comments ans suggestions are welcome.

I guess one approach is to retain the Gtk::Widget/Gtk::Window class for
top level widgets, on which gtk_widget_destroy() can be called with the
correct result, and to manage everything else by operating only on the
GObject reference count (as with Glib::RefPtr) and by adding and
removing widgets from their containers.  That is essentially (and
somewhat fortuitously) what a wrapper of my own which I sometimes use
does, and what (as I understand it) C code is supposed to do with GTK+4.

It would however give rise to a fearsome amount of work and a complete
redesign of the interfaces, which I imagine would not be welcome to
gtkmm users.

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

Re: Gtk::Builder and item id

[Chris Vine]

On Tue, 7 Nov 2017 09:29:18 +0100
Kjell Ahlstedt  wrote:
> Den 2017-11-07 kl. 00:07, skrev Christian Schoenebeck:
> >
> > But I guess I have to move this issue over to the Gtk+ list.  
> Yes, that's a good idea.
> > However I wonder if I am really the first one encountering this
> > issue. I mean it should be quite common to retrieve menu items at
> > runtime. Or does that mean other people are using a different
> > approach by assembling menus with
> >
> > 
> >
> > format instead?  
> The gtk+ demos at
> https://git.gnome.org/browse/gtk+/tree/demos/gtk-demo contains the
> menus.ui file with  elements without ids, and the demo.ui file
> with elements such as
> 
> | I don't know if that's
> how it's supposed to be, i.e. if you have to use GtkMenuItem when you
> want to get a pointer to the menu item from the GtkBuilder. |

Quite a bit in gtk+-3.92 seems to be broken, which may not be too
surprising given that it is the current development branch[1].  For
example I have noticed that GtkPrintOperation doesn't work, which will
be problematic for any program wanting to offer a print option.

It is probably best to treat gtk+-4 as a work in progress.

Chris

[1] When gtk+-3.22 was frozen it was the stated hope that gnome
projects would switch to the unstable API leaving gtk+-3 for other
applications.  That hasn't happened - nothing in gnome-3.26 and (as far
as I can tell) gnome-3.27 uses the gtk+-4 branch.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Background Threading Option

[Chris Vine]

On Tue, 3 Oct 2017 15:58:37 +0530
Deepak Chiradoni  wrote:
> Hello,
> 
> Is there a Background threading option in GTKMM as in VB script. As I
> am doing CAN communication using GUI (GTKMM 3.0). The GUI has to
> receive and send packets continuously in the interval of 20
> milliseconds. While receiving packets the task I defined for widgets
> has to update in parallel. The thread has to work according to the
> following Link as in VB.
> 
> https://www.codeproject.com/Articles/99143/BackgroundWorker-Class-Sample-for-Beginners

You can just start your worker thread using std::async, std::thread or
Glib::Threads::Thread, and on completion the worker thread can post its
continuation to the glib main loop using
Glib::SignalIdle::connect_once(): see
https://developer.gnome.org/glibmm/2.52/classGlib_1_1SignalIdle.html

For something more formalized you could use
TaskManager::make_task_packaged_compose() from c++-gtk-utils:
http://cxx-gtk-utils.sourceforge.net/2.2/classCgu_1_1Thread_1_1TaskManager.html#aea4d2ce3d963f207f2c23813ae9e8c2a

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

Re: Pointer casting related question

[Chris Vine]

On Mon, 7 Aug 2017 15:04:48 +0100
Daniel Boles <dboles@gmail.com> wrote:
> On 7 August 2017 at 14:59, Chris Vine <vine35792...@gmail.com> wrote:
> 
> > A static cast will carry out pointer adjustment when traversing an
> > inheritance graph to account for multiple inheritance or a vtable.
> > It is reinterpret cast which will not.
> >  
> 
> Indeed, thanks. I was only half-thinking at the time, and decided to
> err on the side of caution. :)
> 
> I am one of the seemingly unpopular people who think it's perfectly
> fine to static_cast if you know the conversion will always be valid -
> i.e. so long as the program is not already in the process of crashing
> or failing asserts, which obviously should not be treated as
> reachable in released builds.

I agree with you.  I rarely use dynamic_cast (and I rarely use virtual
inheritance - mainly only for type erasure).  In practice you usually
know statically what your object consists of.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Pointer casting related question

[Chris Vine]

On Mon, 7 Aug 2017 13:58:07 +0100
Daniel Boles  wrote:
> use Glib::RefPtr::cast_dynamic(source_refptr)
> 
> or cast_static if you can guarantee that the cast is valid, does not
> require adjustment for multiple/virtual inheritance, and don't want
> the (probably insignificant) overhead of a checked cast.
> 
> see:
> https://developer.gnome.org/glibmm/stable/classGlib_1_1RefPtr.html#afba688c406f0c3d1239c6b7c3716c1de
> https://mail.gnome.org/archives/gtkmm-list/2010-August/msg00051.html

A static cast will carry out pointer adjustment when traversing an
inheritance graph to account for multiple inheritance or a vtable.  It
is reinterpret cast which will not.

A static cast does not allow a direct cast between two siblings in
a multiple inheritance graph (you will get a compiler error unless you
do it in two stages via a common parent), and as you say it does not
check for validity.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Why do Glib::ustring::operator[] and at() return values, not references?

[Chris Vine]

On Sat, 24 Jun 2017 19:48:07 +0100
Daniel Boles <dboles@gmail.com> wrote:
> On 24 June 2017 at 19:12, Chris Vine <vine35792...@gmail.com> wrote:
> 
> > On Sat, 24 Jun 2017 19:08:36 +0100
> > Chris Vine <vine35792...@gmail.com> wrote:
> >  
> > > It is because UTF-8 is a multibyte encoding, and any one
> > > character may require between 1 and 5 bytes to represent it.  If
> > > you were allowed to change a byte at will you would be able to
> > > introduce invalid encoding sequences.  As to the absense of
> > > documentation, maybe it is because this was thought to be
> > > self-evident, dunno.  
> >
> > And I should perhaps also make the point that these operators
> > return a 32-bit unicode character, not a byte, which is consequent
> > on the same point.  If you allowed mutation, the length of the
> > string (in bytes) might change.  
> 
> Right, of course. It does seem very obvious now. It seemed to
> completely slip my mind that we're dealing with characters of
> arbitrary width, not e.g. UTF-16. :( Thanks for the comprehensive
> answer to a stupid question!

UTF-16 is also a variable width encoding, with surrogate pairs for
anything outside the basic multilingual plane.  Which is why UTF-16 is
regarded by many as a fairly unhelpful encoding.  It does have the
feature that for the average japanese text, it does occupy slightly
less space that UTF-8.  The same is not true of Chinese text though.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Why do Glib::ustring::operator[] and at() return values, not references?

[Chris Vine]

On Sat, 24 Jun 2017 19:08:36 +0100
Chris Vine <vine35792...@gmail.com> wrote:

> On Sat, 24 Jun 2017 15:51:49 +0100
> Daniel Boles <dboles@gmail.com> wrote:
> > Title says it all really. I had to use an std::string in one place
> > because I needed to modify it quickly and with less hassle than
> > using .replace() - and Glib::ustring won't let me get a reference to
> > perform such modification.
> > 
> > The documentation states
> > "No reference return; use replace()
> > <https://developer.gnome.org/glibmm/stable/classGlib_1_1ustring.html#a0f0c9b5aaad58279d3ac87a86a173f4a>
> > to write characters."
> > but does not explain why, nor does the commit log: these comments
> > were added way back in the initial revision.
> > 
> > So I'm wondering whether there's really a reason for this, or if it
> > is just something that no one has wanted to change (until now!)  
> 
> It is because UTF-8 is a multibyte encoding, and any one character may
> require between 1 and 5 bytes to represent it.  If you were allowed to
> change a byte at will you would be able to introduce invalid encoding
> sequences.  As to the absense of documentation, maybe it is because
> this was thought to be self-evident, dunno.

And I should perhaps also make the point that these operators return a
32-bit unicode character, not a byte, which is consequent on the same
point.  If you allowed mutation, the length of the string (in bytes)
might change.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Why do Glib::ustring::operator[] and at() return values, not references?

[Chris Vine]

On Sat, 24 Jun 2017 15:51:49 +0100
Daniel Boles  wrote:
> Title says it all really. I had to use an std::string in one place
> because I needed to modify it quickly and with less hassle than
> using .replace() - and Glib::ustring won't let me get a reference to
> perform such modification.
> 
> The documentation states
> "No reference return; use replace()
> 
> to write characters."
> but does not explain why, nor does the commit log: these comments were
> added way back in the initial revision.
> 
> So I'm wondering whether there's really a reason for this, or if it
> is just something that no one has wanted to change (until now!)

It is because UTF-8 is a multibyte encoding, and any one character may
require between 1 and 5 bytes to represent it.  If you were allowed to
change a byte at will you would be able to introduce invalid encoding
sequences.  As to the absense of documentation, maybe it is because this
was thought to be self-evident, dunno.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Replacing old C-style casts with static|reinterpret_cast?

[Chris Vine]

On Wed, 10 May 2017 20:25:49 +0100
Daniel Boles  wrote:
> On 10 May 2017 at 20:24, Daniel Boles  wrote:
> 
> >
> > Do you have any recommended reading on the cases which C casts can
> > handle, and adjust as required, but reinterpret_cast<> cannot? That
> > was surprising to me as I thought the C++ casts could cover all the
> > angles. 
> 
> Sorry, of course I meant 'reinterpret_cast<> and any other C++
> casts', i.e. cases that only the old C cast can handle. Some examples
> of discussion and a note of the relevant Standard bits (I have the
> PDF open permanently but never have much luck searching!) would be
> much appreciated.

I don't have any recommended reading I am afraid.  The ability to use C
casts to cast from derived to private base is required by these words
in §5.4/4 of C++14, in describing the behaviour of C casts:  "The same
semantic restrictions and behaviors apply, with the exception that in
performing a static_cast in the following situations the conversion is
valid even if the base class is inaccessible" .

Therefore, C casts can cast as if by static_cast to inaccessible types
even where static_cast cannot.

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

Re: Replacing old C-style casts with static|reinterpret_cast?

[Chris Vine]

On Wed, 10 May 2017 17:22:51 +0100
Daniel Boles  wrote:
> Murray mentioned on a Bugzilla that replacing these with
> static_cast<> is always good.
> 
> Is the same true for cases where we need reinterpret_cast<> ? That is
> semi frequent because GTK+ types are opaque even to us, so converting
> pointers cannot use static_cast<> as the latter cannot verify that
> e.g. both types have the same 1st member.
> 
> The raw C cast would ultimately boil down to a reinterpret_cast
> anyway, so my POV is that we should explicitly write the latter, as
> it signals that we know what we're doing - rather than the raw cast,
> which only really says 'try everything you can think of, and pick
> anything that barely works'!

You can use reinterpret_cast when casting between C types which employ
"C style" inheritance (that is, where the "parent" is a struct which is
the first member of the "child" struct).  This is because C structs are
of necessity standard layout types in C++ speak.  More to the point,
because such inheritance is not inheritance in the C++ sense (they are
unrelated types from the C++ inheritance point of view) casting can
only be done using a C cast or a reinterpret_cast, which is guaranteed
to work by §9.2/20 of the C++ standard.

If that was what your post was about, then I think you are fine.  But
if you were looking at casting more broadly, you cannot assume that any
other valid C cast can be replaced by a reinterpret_cast.  This is
because C casts degrade according to the order set out in §5.4/4 of the
C++ standard, and they will only be implemented as a reinterpret_cast
where a static_cast is not available (and of course a reinterpret_cast
cannot perform a const cast).

This is important because a static cast (and so a C cast) can
be used to navigate an inheritance graph of types which do not have
standard layout, and will adjust pointer addresses on casting
automatically.  This means that, amongst other things, a static_cast can
cast between, say, a virtual derived class and its non-virtual base
(objects of which will generally have different addresses because of
the vtable of the derived class), and also between derived types and
base types where multiple inheritance is employed.  reinterpret_cast on
the other hand will never adjust pointer addresses and will give
undefined behaviour in such cases.

As it happens, one cast can only be made using a C style cast.  A C
style cast will allow you to cast from a derived type to its private
base (that is, where private inheritance is used), even if both are not
standard layout types, and make the correct pointer adjustment.
static_cast will refuse the cast, and reinterpret_cast will allow it
but give undefined behaviour where pointer adjustments would be
required for the cast to succeed.

Except when navigating "C style" or "C++ style" inheritance graphs,
reinterpret_cast and C casts both give rise to strict aliasing issues
when using them for type punning (§3.10/10 of the standard), but that
is a separate matter.

You probably know all this but that wasn't clear from your question.

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

Re: Supporting C++17

[Chris Vine]

On Tue, 4 Apr 2017 23:28:09 +0100
Jonathan Wakely <gt...@kayari.org> wrote:
> On 4 April 2017 at 23:08, Chris Vine wrote:
[snip]
> >  It also seems
> > weird that merely applying -std=c++17 to your code should break its
> > ABI.  The more I think about it, the less clear I am what making the
> > noexcept specification part of the function type in C++17 actually
> > involves compiler-wise, or what it achieves.  
> 
> It allows overloading on whether a function can throw, and
> specializing templates on it, and deducing it from template arguments.
> 
> So if you take the address of a function you don't lose it's
> "noexceptiness". Previously this static assertion could never pass:
> 
> void f() noexcept;
> template void g(F f) {
> static_assert( noexcept( f() ), "callback won't throw" );
> }
> 
> int main() {
> g(  );
> }
> 
> In C++17 it compiles.

Aha, this may be it.
http://en.cppreference.com/w/cpp/language/noexcept_spec also says:
"Functions differing only in their exception specification cannot be
overloaded (just like the return type, exception specification is part
of function type, but not not part of the function signature) (since
C++17)."

So I suspect that the noexcept specification may still not affect name
mangling.  It might cause a compile error on type mismatch in C++17 when
say assigning a function to a function pointer, and as you say it may
allow the noexcept specification to participate in template type
resolution, but it may not affect linkage. I hope so anyway.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Supporting C++17

[Chris Vine]

On Tue, 4 Apr 2017 23:09:33 +0100
Jonathan Wakely <gt...@kayari.org> wrote:
> On 4 April 2017 at 22:56, Chris Vine wrote:
> > I would check that.  It didn't affect ABI in C++11/14, but I am not
> > so sure about C++17.  According to
> > http://en.cppreference.com/w/cpp/language/noexcept_spec,
> > in C++17 "The noexcept-specification is a part of the function type
> > and may appear as part of any function declarator."  If it is part
> > of the type then it might feature in name mangling, so this is
> > worth checking with the compiler writers.  
> 
> In C++17 the exception spec is part of the type, so noexcept(true)
> functions are mangled differently from functions that are
> noexcept(false).

As I said in my follow-up email, on reflection I agree with you about
noexcept(false).

But if this is correct about noexcept(true), and I am now beginning to
doubt myself on this, then it seems a recipe for broken libraries.  It
makes any code with a noexcept(true) function specification which has
been compiled with the -std=c++14 option ABI incompatible with the same
code compiled with the -std=c++17 option.

What benefit accrues from making the noexcept specification part of
the type which is worth all that ABI breakage?
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Supporting C++17

[Chris Vine]

On Tue, 4 Apr 2017 22:56:22 +0100
Chris Vine <ch...@cvine.freeserve.co.uk> wrote:
> On Tue, 04 Apr 2017 18:13:46 +0200
> Murray Cumming <murr...@murrayc.com> wrote:
> > 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 dynamic exception specifications with noexcept(false)
> > > (or just no exception specification). That's not an ABI
> > > change.
> > 
> > That's great to know. I'll take care of that then.  
> 
> I would check that.  It didn't affect ABI in C++11/14, but I am not so
> sure about C++17.  According to
> http://en.cppreference.com/w/cpp/language/noexcept_spec,
> in C++17 "The noexcept-specification is a part of the function type
> and may appear as part of any function declarator."  If it is part of
> the type then it might feature in name mangling, so this is worth
> checking with the compiler writers.

On second thoughts, noexcept(true) might possibly change ABI in C++17,
but it seems inconceivable that noexcept(false) would.  It also seems
weird that merely applying -std=c++17 to your code should break its
ABI.  The more I think about it, the less clear I am what making the
noexcept specification part of the function type in C++17 actually
involves compiler-wise, or what it achieves.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Supporting C++17

[Chris Vine]

On Tue, 04 Apr 2017 18:13:46 +0200
Murray Cumming  wrote:
> 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 dynamic exception specifications with noexcept(false)
> > (or just no exception specification). That's not an ABI change.  
> 
> That's great to know. I'll take care of that then.

I would check that.  It didn't affect ABI in C++11/14, but I am not so
sure about C++17.  According to
http://en.cppreference.com/w/cpp/language/noexcept_spec,
in C++17 "The noexcept-specification is a part of the function type and
may appear as part of any function declarator."  If it is part of the
type then it might feature in name mangling, so this is worth checking
with the compiler writers.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: New versioning scheme in gtk+. And in gtkmm?

[Chris Vine]

On Thu, 23 Mar 2017 15:19:51 +
Daniel Boles <dboles@gmail.com> wrote:
> On 23 March 2017 at 15:09, Chris Vine <ch...@cvine.freeserve.co.uk>
> 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.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: New versioning scheme in gtk+. And in gtkmm?

[Chris Vine]

On Thu, 23 Mar 2017 11:51:00 +0100
Murray Cumming <murr...@murrayc.com> 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
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: New versioning scheme in gtk+. And in gtkmm?

[Chris Vine]

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.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: New versioning scheme in gtkmm? In glibmm?

[Chris Vine]

On Mon, 26 Sep 2016 22:26:01 +0200
Murray Cumming  wrote:
> On Fr, 2016-09-23 at 16:51 +0200, Kjell Ahlstedt wrote:
> > Gtk+ has announced a new versioning scheme:
> > https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-pr
> > omise-in-gtk
> > I suppose that it will affect gtkmm. Will gtkmm use the same
> > versioning scheme? If so, I suppose that once a gtkmm-3-22 branch
> > has been created in the git repository, we shall start removing all
> > deprecated API in the master branch. And fix bug reports that
> > require an ABI and/or API break. Am I right?
> > Will glib use a similar versioning scheme? I.e. soon an ABI/API-
> > breaking glib 2.90 release and then glib 3.0?
> > Kjell  
> 
> It's very hard to know what they really intend, or what will really
> happen. But it looks like this is what they want:
> * GTK+ 4.0, 5.0, 6.0, etc, will be stable releases (installed in
> parallel, as we'd already expect).
> * GTK+ 3.9*, 4.9*, 5.9* will be unstable releases of those APIs.
> * These will take longer to become stable releases, compared to the 6-
> monthly cycles we have now, with releases such as 3.2.x, 3.4.x, 3.6.x,
> etc.
> 
> So it just looks like they want to take much longer between stable
> releases that add new API.

That isn't really it.  The intention is that API/ABI will be broken with
every new major stable release, as at present (so 5.0 will be API/ABI
incompatible with 4.0, and so on), but that these new major stable
releases will come out at a much higher rate than at present - every 2
to 3 years. This is supposedly firstly to allow for a higher rate of
innovation (official breakage), and secondly to reduce the amount of
unofficial breakage between ostensibly stable and compatible releases,
which has caused problems with the 3.* series.  Successive incompatible
stable releases will come out more frequently, but within any major
version compatibility will be more rigorously enforced.  In particular,
once a new major stable release has actually come out, thereafter it
will only receive bug fixes and not new features.

There will still be six-monthly releases of new minor versions, leading
to the next stable release every 2 to 3 years' time, but these minor
releases are not guaranteed to be compatible with one another.

I can't say I like it, but there we are.

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

Re: gtkmm Monitoring IO example

[Chris Vine]

On Fri, 25 Sep 2015 15:13:48 +0200
Kjell Ahlstedt  wrote:
> When I tested the input example program on my dual-core PC, I got the 
> same result: The CPU load on one of the cores is 100% after something
> is written to the fifo. Most of the relevant code is in glib. I don't
> know all details, but this is what I found:
> 
> Before anything is written to the fifo, the program waits at
> read_fd = open("testfifo", O_RDONLY);
> without using much CPU time (perhaps no time at all).
> Once the fifo contains data to read, open() returns, and the program 
> enters the main loop at
> app->run();
> After that, the fifo is monitored by polling. Polling is inefficient. 
> Probably it's the only possible way that the OS offers. It does seem
> a bit extreme to use all available CPU time for polling, but probably
> it's normal behaviour.

Assuming we are talking about a unix-like system, it certainly isn't.
glib will either call poll() or select() and block in a separate i/o
thread, and I think it is poll() which it uses.  Neither should busy
wait, assuming the waiting input is correctly extracted from the file
descriptor which has become ready.

I suspect there is something wrong with the example code, possibly
to do with the way Glib::IOChannel is used with the version of
Glib::SignalIO::connect() which takes a file descriptor rather than the
IOChannel object itself - it would be worth trying the version of
Glib::signal_io().connect which takes the IOChannel object.  Possibly
something goes amiss if you don't do that, but that's a guess.

As an aside, I have always found Glib::IOChannel and GIOChannel quite
difficult to use and I avoid them.  The Gio namespace offers better
functionality.  Where Glib::SignalIO::connect() comes into use is if
you have a raw file descriptor which you want to read when it comes
available using something like unix read(): then, the version of
Glib::SignalIO::connect() which takes a descriptor can be very useful.

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

Re: C++11: Deprecate Glib::Threads

[Chris Vine]

On Sun, 30 Aug 2015 12:34:30 +0200
Murray Cumming murr...@murrayc.com wrote:
 We could probably require C++14 for the next glibmm version (2.47/48).

That would require gcc-4.9 or later, which supports the -std=c++14
flag and also shared mutexes (read-write locks). That doesn't mean it
shouldn't be done, but it would become the minimum requirement.

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

Re: C++11: Deprecate Glib::Threads

[Chris Vine]

On Sat, 29 Aug 2015 13:49:49 -0700
Andy Tai a...@atai.org wrote:
 A related generic question:  would a C++ based implementation of
 dispatcher be more efficient than the glib (C) based ones?

I am not sure what you mean.  It already uses the glibmm wrapper of glib
so far as relevant.

Do you mean that it should stop using glib/glibmm?  That is impossible
because Glib::Dispatcher uses the glib/glibmm main loop, and that is
its whole purpose: to execute callbacks in a program's main loop
(normally the main loop used by GTK+) when invoked by a worker thread.
If you were thinking of std::promise and std::future, they are
completely different.  Those provide potentially blocking waits, not
asynchronous delivery to a program loop.

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

Re: Using C++11

[Chris Vine]

On Tue, 30 Jun 2015 12:06:46 +0200
Murray Cumming murr...@murrayc.com wrote:

 On Tue, 2015-06-30 at 10:53 +0100, Chris Vine wrote:
  On Tue, 30 Jun 2015 08:32:43 +0200
  Murray Cumming murr...@murrayc.com wrote:
   On Mon, 2015-06-29 at 19:44 +0100, Chris Vine wrote:
   [snip]
Fedora 23, which will use gcc-5.1 with the new ABI, will have to
recompile all its C++ binaries (libraries and programs)[1], for
all versions of C++ those libraries and programs may happen to
use.
   [snip]
   
   And would you agree that Ubuntu (for instance) will have to do the
   same thing when C++11 (--std=c++11) becomes the default in g++ 6,
   when they use g++ 6?
  
  No.  Assuming gcc-6 still provides libstdc++ with both ABIs (my
  guess is that gcc will do so for a considerable number of
  releases), then it would depend on whether ubuntu chooses to use
  the new ABI instead of the old one for its C++ binaries.
 
 Isn't Ubuntu likely to make the same choice that Fedora has made, at
 least at some point?
 
 Or is Fedora just doing this (using the C++11 libstdc++ API) because
 they really like C++11 and want to make the C++11 experience as good
 as possible?

I would guess that it is because fedora is a fast moving distribution
and they like to press ahead with what everyone will be doing in a few
years' time.

I doubt it is in order to be especially C++ friendly.  The ABI changes
are pretty much irrelevant to the average C++11/14 user.  How often does
your code's performance depend on O(1) rather than O(N) complexity of
std::list::size() (and if this does affect performance in a particular
case, why are you using lists in the first place)?  And how often does
your code rely on the requirement that non-const operator[]() for a
string may not invalidate iterators into the string (C++03 does permit
that, C++11 does not, and is what rules out copy-on-write)?

For what it is worth, I write all my C++11 code with the old ABI, for
the moment.

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

Re: Using C++11

[Chris Vine]

On Tue, 30 Jun 2015 12:22:38 +0200
Murray Cumming murr...@murrayc.com wrote:
[snip]
 It looks like Ubuntu does plan to use gcc 5 in Ubuntu 15.10 (in
 development now):
 http://summit.ubuntu.com/uos-1505/meeting/22506/gcc-5-update-for-1510/
 though it's currently still using gcc 4.9.2:
 http://packages.ubuntu.com/search?suite=wilykeywords=gcc
 
 The plan isn't clear to me, but they are maybe going to try doing
 parallel-installs of all the affected libraries, though that seems
 unmanageable to me:
 http://pad.ubuntu.com/uos-1505-gcc-5-update-for-1510
 These are the meeting notes. If you can't log in to see that, here's a
 copy/paste of part of the current contents:
[snip]

It looks to me as if they are going to switch to the new ABI, but
haven't made any firm decision on that yet.

However, I don't think this should have any bearing on whether gtkmm
adopts C++11.  As I have mentioned, this should not and does not depend
on what ABI a particular distribution happens to choose for its C++
binaries.

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

Re: Using C++11

[Chris Vine]

On Mon, 29 Jun 2015 14:22:27 +0200
Murray Cumming murr...@murrayc.com wrote:
 (Sorry, I'm trying to keep this very simple.)
 
 I don't know if Firefox depends on any other C++11 libraries so it
 might not be the example I'm looking for.
 
 Another for-instance question:
 Ubuntu 15.04 (Vidid Vervet), which I'm running here, has g++ 4.9.2 and
 its glibmm/gtkmm are built without --std=c++11. If SomeAppOrOther
 depended on gtkmm as it is now, could its Ubuntu package be safely
 built with or without --std=c++11?

SomeOtherApp (an appliction using gtkmm) _should_ be able to be safely
built with or without the -std=c++11 flag, if that application only uses
C++98/03 features  [1].  If SomeOtherApp uses C++11 features, then it
must be built with the -std=c++11 flag.  (For that matter it _should_ be
possible to compile gtkmm-3 with the -std=c++11 flag - set your
CXXFLAGS and give it a try.)

I say should because this assumes that the program, and the current
gtkmm headers, don't fall down some crack representing the minor changes
of existing features that occurred between C++03 and C++11, as
conveniently summarized in Appendix C2 of the C++11 standard.  For
example, auto has changed its meaning.  But this is very improbable
and easily fixed.  The C++11 standard was intended to be compatible
with existing code except in a few exceptional and unavoidable cases
which are rarely encountered in practice.

I have the feeling that you might have a slightly different question,
because the one referred to above doesn't seem relevant to the question
whether the next version of gtkmm should require C++11. If it does,
then user code would require to be compiled with the -std=c++11 flag,
as well as gtkmm itself.

Or were you asking what would happen if gtkmm-3 (a C++98/03 library)
were compiled with the -std=c++11 flag and a user program were not?  I
_think_ the user program would be OK but I would want to test it
first.  Even easier would be not to do it, or to ask on the g++ mailing
lists.

Chris

[1] But why would the author of SomeOtherApp compile it with
-std=c++11 if it were to be a C++98/03 only application?  One answer I
guess may be to make use of move semantics within the standard library,
for compilers which support it.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Using C++11

[Chris Vine]

On Mon, 29 Jun 2015 08:18:12 +0200
Murray Cumming murr...@murrayc.com wrote:
 On Sun, 2015-06-28 at 20:30 +0100, Chris Vine wrote:
  On Sun, 28 Jun 2015 20:17:28 +0200
  Murray Cumming murr...@murrayc.com wrote:
   Given that --std=c+11 breaks ABI compatibility (at least in the
   standard library), I wonder if/when distros would ever build
   glibmm with C++11 support.
  
  gcc-3.4 and gcc-4.* do not provide libstdc++ with a C++11 compliant
  ABI (this is mainly concerned with gcc's copy on write string
  implementation) and gcc-5.1 does by default do so,
 [snip]
 
 So do you think any apps have been built with C++11 on mainstream
 distros so far?

Yes, if only because mozilla now requires c++11.  I occasionally see
other things I compile which test for C++11, although don't ask me what
they were. However, far more will link with C++11 code dynamically
without knowing it.  I noticed that llvm-3.6 now uses C++11 (I filed a
bug when mesa-10.4 failed to compile with llvm-3.6 because llvm-3.6
switched to std::unique_ptr - mesa 10.5 now does compile with llvm-3.6).

Some form of C++11 support has been available in gcc for ages - gcc-4.4
for example provided some support (smart pointers, variadic templates,
move semantics, the additional wide character types and some of C++11
threads). gcc-4.5 supported lambdas and most of C++11 threads (but not
the memory model).  gcc-4.6 supported range-for and an improved template
implementation.  gcc-4.7 was nearly C++11 complete (including template
aliasing) except that it did not support the full C++11 memory model
nor regular expressions and some of its tuple implementation was not
fully conforming.  gcc-4.8 seems to be pretty much completely
conforming (including the C++ memory model) except for regular
expressions. gcc-4.9 I think is pretty well c++11 complete (including
regular expressions) except for the string implementation which needed
ABI breakage to fix, and a few other things in the standard library
(including a O(1) std::list::size() function - see
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html).

To see what mozilla requires by way of gcc
see https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code
(latest releases require gcc-4.7).

The thing to do is to decide what the earliest version of gcc you want
gtkmm to compile with and test with that (and with gcc-5).  I would
suggest possibly gcc-4.6 or gcc-4.7.

The other point about the -std=c++0x, -std=c++11 and -std=c++14 flags
is that they do not change the ABI from the gcc-3.4 ABI to the gcc-5.1
ABI.  Only defining _GLIBCXX_USE_CXX11_ABI does that. Instead the flags
make some additional API available (or not available) and make some
minor other changes to the API.  Code compiled with the -std=c++11 flag
can link quite happily with a C++98/03 library such as gtkmm, provided
the same libstdc++ ABI is used for both.  The best way a distribution
can do that is to recompile all its C++ libraries with the same
_GLIBCXX_USE_CXX11_ABI setting and make that the default for the
compilation of user programs.

You might also want to read this, for an explanation about how Fedora
is dealing with gcc-5:
http://developerblog.redhat.com/2015/02/10/gcc-5-in-fedora/

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

Re: Using C++11

[Chris Vine]

On Mon, 29 Jun 2015 12:03:04 +0200
Kalev Lember kalevlem...@gmail.com wrote:
 On 06/29/2015 08:18 AM, Murray Cumming wrote:
  On Sun, 2015-06-28 at 20:30 +0100, Chris Vine wrote:
  On Sun, 28 Jun 2015 20:17:28 +0200
  Murray Cumming murr...@murrayc.com wrote:
  Given that --std=c+11 breaks ABI compatibility (at least in the
  standard library), I wonder if/when distros would ever build
  glibmm with C++11 support.
 
  gcc-3.4 and gcc-4.* do not provide libstdc++ with a C++11
  compliant ABI (this is mainly concerned with gcc's copy on write
  string implementation) and gcc-5.1 does by default do so,
  [snip]
  
  So do you think any apps have been built with C++11 on mainstream
  distros so far?
 
 All of Fedora 23 (scheduled for release this October / November) is
 built with the new C++11 ABI.

True, but this is orthogonal to the question whether distributions ship
programs built with C++11, from which I took Murray to mean which use
C++11 features and are compiled with the -std=c++0x or -std=c++11
flags.  Fedora 22 also ships with programs built with C++11, including
firefox.  Quite probably fedora 21 does so too.

The new C++ ABI covers any C++ program, C++98 or C++11 or whatever,
which uses a version of libstdc++ compiled for the new ABI.  The old
C++ ABI covers any C++ program, C++98 or C++11 or whatever, which uses
a version of libstdc++ compiled for the old ABI.

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

Re: Using C++11

[Chris Vine]

On Mon, 29 Jun 2015 17:00:44 +0200
Murray Cumming murr...@murrayc.com wrote:
[snip]
 Personally, it feels unwise for Fedora to build everything with
 --std=c ++11 if their compiler isn't going to use that by default.
 That's going to confuse developers who get weird errors when they
 don't specify --std=c++11. It's a bit like how Red Hat used to ship
 weirdly patched unstable compiler versions back in the gcc 2.* days.
 But anyway, it looks like it's happening. 

I don't disagree with the rest of your post, but this is wrong.  Using
the gcc-5.1 ABI does not require you to compile C++ code with the
-std=c++11 flag, and there is no proposal that fedora should do so.
From that point of view the _GLIBCXX_USE_CXX11_ABI define is a slight
misnomer - the point is that the ABI is compliant with C++11, not that
it is only for C++11.

The new ABI applies to all flavours of C++ compiled with the default
settings for gcc-5.1, including C++98/03 code - there is nothing in
C++98 that requires copy on write strings, nor O(N) complexity for
std::list::size() - the thing is that C++98 does not prohibit these,
whereas C++11 does.

I know my earlier posts were somewhat long, but it might be worth
reading them, as I explained all this.  I also provided some links
(which I see also Kalev reproduced for you).

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

Re: Using C++11

[Chris Vine]

On Mon, 29 Jun 2015 20:08:17 +0200
Murray Cumming murr...@murrayc.com wrote:
 On Mon, 2015-06-29 at 18:57 +0100, Chris Vine wrote:
  I don't disagree with the rest of your post, but this is wrong.
  Using the gcc-5.1 ABI does not require you to compile C++ code with
  the -std=c++11 flag,
 
 Ah, thanks.
 
   and there is no proposal that fedora should do so.
  From that point of view the _GLIBCXX_USE_CXX11_ABI define is a
  slight misnomer - the point is that the ABI is compliant with
  C++11, not that it is only for C++11.
 [snip]
 
 But the applications do need to be rebuilt in Fedora? So there is an
 ABI break? And that rebuild just has to be done with the newer
 compiler version?

The essentials are that:

1.  _GLIBCXX_USE_CXX11_ABI controls the ABI for all versions of C++.

2.  -std=c++[...] controls the API.

All C++ code, of all C++ flavours, for any setting of -std=c++[...]
uses the same ABI if it uses the same _GLIBCXX_USE_CXX11_ABI setting.

Therefore, fedora 22, which uses gcc-5.1 with the old ABI, did not need
to recompile any of its C++ binaries, for any version of C++.

Fedora 23, which will use gcc-5.1 with the new ABI, will have to
recompile all its C++ binaries (libraries and programs)[1], for all
versions of C++ those libraries and programs may happen to use.  Thus it
will have to recompile current gtkmm-3.16 for C++-98 for the new ABI,
irrespective of what gtkmm does in the future about C++11 (if
anything).  So yes, Fedora 23 represented an ABI break - all
out-of-distribution third party C++ applications would have had to be
recompiled if they were to use any C++ library other than the standard
library.

Chris

[1]  As Kalev has mentioned, strictly speaking this does not apply to
C++ programs which only use the standard library and use no external
C++ libraries such as gtkmm or Qt, because libstdc++ comes in dual
binary format.  In practice as I understand it fedora have recompiled
everything anyway.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Using C++11

[Chris Vine]

On Sun, 28 Jun 2015 20:17:28 +0200
Murray Cumming murr...@murrayc.com wrote:
 On Wed, 2015-06-24 at 13:17 +0200, Murray Cumming wrote:
  On Wed, 2015-06-24 at 09:27 +0200, Murray Cumming wrote:
Please see https://gcc.gnu.org/ml/gcc/2015-05/msg00075.html.
   
   I don't see any reply to your question. So I'm still stuck with
   wanting to use C++11 but having a big official warning telling me
   not to.
  
  Nevertheless, maybe we can do some things already. Feedback welcome:
  https://bugzilla.gnome.org/show_bug.cgi?id=751432
 
 Given that --std=c+11 breaks ABI compatibility (at least in the
 standard library), I wonder if/when distros would ever build glibmm
 with C++11 support.

gcc-3.4 and gcc-4.* do not provide libstdc++ with a C++11 compliant ABI
(this is mainly concerned with gcc's copy on write string
implementation) and gcc-5.1 does by default do so, but this is
selectable at gcc compilation time, and I should not worry about it for
gtkmm, because whatever default configuration distributions ship with
(including with respect to gtkmm), they ship with.  All gtkmm needs to
do is test at configuration time for the earliest version of gcc that
it is intended to compile with, and ensure that the library is compiled
with the -std=c++0x or -std=c++11 flag.  In a library I distribute, I
do this with some very simple autoconf macros.

You can compile libstdc++ in gcc-5.1 with both ABIs simpultaneously.
The default ABI is determined by whether gcc was compiled with the
--with-default-libstdcxx=c++98, --with-default-libstdcxx=c++11 or
--disable-libstdcxx-dual-abi flags. The last of those sticks with the
gcc-3.1/4.* ABI and does not provide the new one at all.  The other two
compile libstdc++ with both ABIs, and differ only in the default.  User
programs can override the default by defining _GLIBCXX_USE_CXX11_ABI
when compiling the program. Setting it to 0 will pick the old ABI, and
setting it to 1 will pick the new one.

For example Redhat intends its next distribution of Fedora after the
release of gcc-5 (possibly now its current release?) to have libstdc++
compiled with the --with-default-libstdcxx=c++98 flag.  It has
announced that its following release will be compiled with the
--with-default-libstdcxx=c++11 flag.

Library suppliers don't need to worry about it except in the very
unlikely event that they want to allow distributions to install a
version of their library for each ABI, in the same way that libstdc++
does with gcc-5.1.  This can be done by using special purpose ABI tags.
In my view that would be unnecessary for gtkmm and I should be very
surprised if any common C++ libraries, including Qt, bother with that.

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

Re: Sequence order in map values...

[Chris Vine]

On Wed, 8 Apr 2015 21:33:16 +0200
Glus Xof gtg...@gmail.com wrote:
 Hi guys,
 
 I write a simple code (see at the bottom) to ask you why the order
 sequence of values listed in the 'treeview' and in the 2nd Sequence
 don't correspond with the 1st Sequence...
 
 I mean, in the 1st Sequence I get,
 
 .1 == Point -- One
 .2 == Point -- Two
 .3 == Point -- Three
 01 == Zero -- One
 02 == Zero -- Two
 11 == One -- One
 
 Which is the desired sequence order... but in the
 2nd... (elaborated in a Gtk Application context...)
 
 01 *  Zero -- One
 02 *  Zero -- Two
 .1 *  Point -- One
 11 *  One -- One
 .2 *  Point -- Two
 .3 *  Point -- Three
 
 What happens, here ??
 
 Glus

[snip]

GtkApplication's constructor calls setlocale(), and your locale
probably has a different string comparison operator than does the C
locale.

Call setlocale() at the beginning of main and I expect they will give
you the same result.

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

Re: C++11 features, move semantics?

[Chris Vine]

On Wed, 21 Jan 2015 08:39:46 +0100
Murray Cumming murr...@murrayc.com wrote:
 On Sun, 2014-12-28 at 15:42 +0100, Christof Meerwald wrote:
  Hi,
  
  just wondering if anyone has given any thought on C++11 features for
  gtkmm.
  
  One thing that seems very unfortunate is that all objects are
  non-movable (due to them being explicitly made non-copyable which
  then also deletes the move constructor).
 [snip]
 
 I believe it's possible to make classes movable but not copyable. That
 feels strange to me, but maybe that's just because I'm not using C++11
 day to day. I hope that this wouldn't lead to code that looked too
 much like the widgets were being copied. I can imagine a lot of
 confusion from less experienced coders.

It is possible (the canonical example is of course std::unique_ptr) and
it does not confuse, because lvalues can only be moved by converting
them to rvalues, in other words by calling std::move on them.  Calling
std::move makes it clear, I think, that no copying is involved.

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

Re: Gtk::Grid::attach_next_to

[Chris Vine]

On Wed, 29 Oct 2014 09:16:37 +
Thomas Harty t.har...@physics.ox.ac.uk wrote:
 Okay, that's what I'd assumed.
 
 Bug filed at https://bugzilla.gnome.org/show_bug.cgi?id=739340.
 
 Related: what's the best way to get the number of rows/columns
 currently in a Gtk::Grid?

I have never had to to that, and I don't think you can, other than by
keeping either a mental note or, if you are not constructing the grid
statically, some state variable(s) which will tell you.

You might find that just using the add() method inherited from
Gtk::Container will do what you want.  The documentation states that
Grid can be used like a Box by just using Gtk::Container::add(), which
will place children next to each other in the direction determined by
the 'orientation' property.  Quite how that works (if it does) where
there is more than one row or column in the desired direction I am not
sure, but you could try it and see (GtkBox is the same as GtkGrid with
rank 1 in one of its dimensions).

If that doesn't work I should just use the C interface if it is
easier.

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

Re: Gtk::Grid::attach_next_to

[Chris Vine]

On Sat, 25 Oct 2014 11:43:17 +
Thomas Harty t.har...@physics.ox.ac.uk wrote:
 The documentation for Gtk::Grid::attach_next_to
 (https://developer.gnome.org/gtkmm/stable/classGtk_1_1Grid.html#ae42f1ae2fc23e16880c51438afa8fbcf)
 says that the sibling widget can be set to 0 to place the child
 widget at the beginning/end of the grid. Does this imply a conversion
 between int and Gtk::Widget, or am I missing something?

This looks like an artefact from the documentation for GTK+ which has
been pulled in.   You cannot have null references in C++ so you will
probably have to use the C interface to get this to work (that is, call
gtk_grid_attach_next_to()).  For that purpose, you can call the grid's
and widget's gobj() method to get the pointers for the first and second
arguments for that function. Alternatively, if you want to stick with
the C++ interface, you could do the necessary calculations yourself and
call the attach() method.

You could regard this as a wrapper error, and file a bug.  However,
there is probably little that can be done about it, except provide a
new overload without the sibling argument.

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

Re: Gtkmm draw line with mouse events

[Chris Vine]

On Mon, 14 Jul 2014 21:27:50 +0530
Gurjot Singh bhattigur...@gmail.com wrote:
 On 14 July 2014 00:22, Chris Vine ch...@cvine.freeserve.co.uk wrote:
  If that is not possible only then I'd be forced to do everything
  in a single on_draw().
 
  You should draw in the on_draw() method or in a draw signal handler
  so that the widget re-renders correctly when this is necessary by
  virtue of other desktop activities.  Obviously your overriding
  on_draw() method can call whatever other drawing functions it
  wants.  You can force a draw when needed by calling
  Gtk::Widget::queue_draw_area() and cognates.
 
 Pardon me, but I didn't get you.
 Can you explain with some example?
 Are you saying that everything that is to be drawn must be written in
 on_draw function?
 Suppose I have two functions that are called to draw point and line,
 something like this:
 http://pastebin.com/Ancx87EF

This example looks fine.

 But if this is it, it'd re-draws the whole drawing area, so I'd be
 unable to retain any previously drawn entity.

I don't understand what you mean here.  Anyway, the cairo context comes
pre-clipped with the area of the dirty region which caused the draw
event.  See the documentation on the draw signal:

The signal handler will get a cr with a clip region already set to the
widget's dirty region, i.e. to the area that needs repainting.
Complicated widgets that want to avoid redrawing themselves completely
can get the full extents of the clip region with
gdk_cairo_get_clip_rectangle(), or they can get a finer-grained
representation of the dirty region with
cairo_copy_clip_rectangle_list().

However, fiddling about with the dirty region is highly unlikely to be
necessary for what you want to do.  When it comes to interfacing with
the X backend (or whatever backend you are using) GDK knows what region
needs to be reproduced.

 And that is why I was asking if it could be done something like,
 
 void DrawingArea :: on_line_cb()
 {
 
 cr-set_source_rgb(0.0, 0.26, 0.26);
 cr-save();
 cr-move_to(0,0);
 cr-line_to(100,100);
 cr-restore();
 cr-stroke();
 
 queue_draw();
 std::coutLine createdstd::endl;
 }
 
 But this doesn't work because it says that 'cr' is not declared in the
 scope or something related to this.

As a matter of cairo implementation you need a cairo context to work
with.  That is provided by the on_draw() method (pre-clipped, as I
said). As a matter of basic C++, the cairo context object needs to be
visible to the code addressing it, which means it must be in scope.

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

Re: Gtkmm draw line with mouse events

[Chris Vine]

On Sun, 13 Jul 2014 23:24:26 +0530
Gurjot Singh bhattigur...@gmail.com wrote:
 On 13 July 2014 22:31, Juan R. Garcia Blanco juanr...@gmail.com
 wrote:
  Hi,
 
  Maybe the Gestures demo could serve as an example (not sure).
 
 That example is using everything to draw in the one on_draw()
 function. But I want to define some drawing in different function
 which when called will draw it.
 If that is not possible only then I'd be forced to do everything in a
 single on_draw().

You should draw in the on_draw() method or in a draw signal handler so
that the widget re-renders correctly when this is necessary by virtue of
other desktop activities.  Obviously your overriding on_draw() method
can call whatever other drawing functions it wants.  You can force a
draw when needed by calling Gtk::Widget::queue_draw_area() and cognates.

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

Re: Running Gtk application in new terminal

[Chris Vine]

On Thu, 5 Jun 2014 16:08:07 +
Mazer, Alan S (389M) alan.s.ma...@jpl.nasa.gov wrote:
 Here you go.  This code implements a simple command processor, one
 command of which starts up a gtk app.  I tried it with an app of mine
 called ngdcs and it works.  You might want to read up on fork and
 exec (man fork, man execv) but this does work for me:

Since the OP is using GTK+, it seems more logical to use
g_spawn_async() or g_spawn_async_with_pipes(), the latter of which will
also set up pipes for stdin, stdout and stderr for you.  (And they are
also cross-platform.)

https://developer.gnome.org/glib/2.40/glib-Spawning-Processes.html

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

Re: Running Gtk application in new terminal

[Chris Vine]

On Thu, 5 Jun 2014 17:59:15 +0100
Chris Vine ch...@cvine.freeserve.co.uk wrote:
 On Thu, 5 Jun 2014 16:08:07 +
 Mazer, Alan S (389M) alan.s.ma...@jpl.nasa.gov wrote:
  Here you go.  This code implements a simple command processor, one
  command of which starts up a gtk app.  I tried it with an app of
  mine called ngdcs and it works.  You might want to read up on
  fork and exec (man fork, man execv) but this does work for me:
 
 Since the OP is using GTK+, it seems more logical to use
 g_spawn_async() or g_spawn_async_with_pipes(), the latter of which
 will also set up pipes for stdin, stdout and stderr for you.  (And
 they are also cross-platform.)
 
 https://developer.gnome.org/glib/2.40/glib-Spawning-Processes.html

And I now see that this is the gtkmm and not gtk mailing list.  In
which case there is:

https://developer.gnome.org/glibmm/stable/group__Spawn.html

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

Re: Unhandled exception?

[Chris Vine]

On Mon, 26 May 2014 15:03:47 -0400
Phillip Susi ps...@ubuntu.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 On 05/22/2014 12:52 PM, Kjell Ahlstedt wrote:
  The gtkmm tutorial contains a section that describes how to use the
  gdb debugger to see where an exception is thrown in a signal
  handler.
  
  https://developer.gnome.org/gtkmm-tutorial/stable/sec-exceptions-in-signal-handlers.html.en
 
 Thanks... so it seems the problem is that Glib::IOChannel::read() is
 throwing the exception because dosfsck is spitting out a 0xBD
 character.  It seems that in CP 437, that is a 1/2 chracter, but in
 UTF-8 it is an incomplete multi byte sequence.  This leads me to
 conclude that there is a bug in glibmm, and I have a question on how
 to handle this character.  The question is how to have
 IOChannel::read treat its input as CP-437 instead of UTF-8, and the
 bug:
 
 glibmm seems to have an automatic exception catch that prints a
 warning and attempts to continue.  This is wrong.  An unhandled
 exception should terminate the program.  By eating the exception,
 glibmm has caused gparted's call stack to unwind leaving the program
 in a broken state.

If you set the IOChannel's encoding to  using
Glib::IOChannel::set_encoding() immediately after creation it should
accept binary data.  Are you saying that that doesn't work?  If it
doesn't it is certainly a bug, as it works with the unwrapped
g_io_channel_set_encoding() when passed a NULL argument.  (In which
case, I guess you could use g_io_channel_set_encoding() on the
underlying GIOChannel object.)

However, if you have a file descriptor and you are handling binary data
why use a IOChannel at all?  Why not connect the file descriptor to the
main loop using Glib::signal_io().connect() and read the file
descriptor using standard (unix) read().

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

Re: Unhandled exception?

[Chris Vine]

On Tue, 27 May 2014 10:24:26 +0100
Chris Vine ch...@cvine.freeserve.co.uk wrote:
 On Mon, 26 May 2014 15:03:47 -0400
 Phillip Susi ps...@ubuntu.com wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA512
  
  On 05/22/2014 12:52 PM, Kjell Ahlstedt wrote:
   The gtkmm tutorial contains a section that describes how to use
   the gdb debugger to see where an exception is thrown in a signal
   handler.
   
   https://developer.gnome.org/gtkmm-tutorial/stable/sec-exceptions-in-signal-handlers.html.en
  
  Thanks... so it seems the problem is that Glib::IOChannel::read() is
  throwing the exception because dosfsck is spitting out a 0xBD
  character.  It seems that in CP 437, that is a 1/2 chracter, but in
  UTF-8 it is an incomplete multi byte sequence.  This leads me to
  conclude that there is a bug in glibmm, and I have a question on how
  to handle this character.  The question is how to have
  IOChannel::read treat its input as CP-437 instead of UTF-8, and the
  bug:
  
  glibmm seems to have an automatic exception catch that prints a
  warning and attempts to continue.  This is wrong.  An unhandled
  exception should terminate the program.  By eating the exception,
  glibmm has caused gparted's call stack to unwind leaving the program
  in a broken state.
 
 If you set the IOChannel's encoding to  using
 Glib::IOChannel::set_encoding() immediately after creation it should
 accept binary data.  Are you saying that that doesn't work?  If it
 doesn't it is certainly a bug, as it works with the unwrapped
 g_io_channel_set_encoding() when passed a NULL argument.  (In which
 case, I guess you could use g_io_channel_set_encoding() on the
 underlying GIOChannel object.)
 
 However, if you have a file descriptor and you are handling binary
 data why use a IOChannel at all?  Why not connect the file descriptor
 to the main loop using Glib::signal_io().connect() and read the file
 descriptor using standard (unix) read().

Two subsidiary thoughts: as an alternative have you tried setting the
encoding to CP437? iconv() supports it on my system so glib ought to
also.

Secondly, on the issue of exceptions, if you are reading the IOChannel
in a callback in the glib main loop I suspect glibmm is swallowing the
exception in order to protect the main loop, although I haven't looked
at glibmm's wrapper for executing callbacks in the main loop for some
time so I could be wrong.  It is often better to swallow a throwing
callback and print to g_critical() than terminate the program, as you
can use g_log_set_always_fatal() to change the behaviour if you want.

If I am right about glibmm protecting the main loop, I would be
surprised if by swallowing the exception, glibmm caused gparted's call
stack to unwind.  You would expect that to do the opposite (and
exceptions can't propagate through glib's C layer to unwind the stack
anyway), albeit as you say probably rendering the program useless.

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

Re: Unhandled exception?

[Chris Vine]

On Tue, 27 May 2014 11:00:57 -0400
Phillip Susi ps...@ubuntu.com wrote:
 On 5/27/2014 6:04 AM, Chris Vine wrote:
  Two subsidiary thoughts: as an alternative have you tried setting
  the encoding to CP437? iconv() supports it on my system so glib
  ought to also.
 
 Yes, calling set_encoding() fixed the exception, although iconv seems
 to be translating the 0xBD character incorrectly.
 
 That might work in this particular case if I know the input is CP-437,
 but how should this conversion exception be handled in general?  I
 tried catching and ignoring the exception, but read() leaves the bad
 characters in the stream, so trying again just keeps throwing the same
 exception.  How can you skip over the damn thing and move on?

If you want to treat input text as text, but don't know the encoding,
you are stuffed, so just catch the conversion exception and abort, or
try to deduce the codeset for yourself and abort when you fail.  If you
want to treat it as binary data, treat it as binary data and all will
be well.

  Secondly, on the issue of exceptions, if you are reading the
  IOChannel in a callback in the glib main loop I suspect glibmm is
  swallowing the exception in order to protect the main loop,
  although I haven't looked at glibmm's wrapper for executing
  callbacks in the main loop for some time so I could be wrong.  It
  is often better to swallow a throwing callback and print to
  g_critical() than terminate the program, as you can use
  g_log_set_always_fatal() to change the behaviour if you want.
  
  If I am right about glibmm protecting the main loop, I would be 
  surprised if by swallowing the exception, glibmm caused gparted's
  call stack to unwind.  You would expect that to do the opposite
  (and exceptions can't propagate through glib's C layer to unwind
  the stack anyway), albeit as you say probably rendering the program
  useless.
 
 That is the bug I was referring to.  An unhandled exception is
 supposed to be a fatal error, resulting in abort().  By catching and
 ignoring the exception, glibmm is inviting all kinds of trouble.

I don't agree on that, as you know.  I prefer the programmer to be
given a choice (assuming that is what glibmm is doing here) according
to the appropriate log level fatality preference.  Call
g_log_set_always_fatal(G_LOG_LEVEL_CRITICAL) and your wish will be
glib's command.  But as I said above, you should really catch the
(fully documented) exceptions which might be thrown by
Glib::IOChannel::read() locally yourself and decide what to do about it.
Especially so in an asynchronous callback, where that is the only
opportunity you can ever have to deal with it.

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

Re: Unhandled exception?

[Chris Vine]

On Tue, 27 May 2014 13:18:25 -0400
Phillip Susi s...@ubuntu.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 5/27/2014 12:59 PM, Chris Vine wrote:
  If you want to treat input text as text, but don't know the
  encoding, you are stuffed, so just catch the conversion exception
  and abort, or try to deduce the codeset for yourself and abort when
  you fail.  If you want to treat it as binary data, treat it as
  binary data and all will be well.
 
 Rather than abort, it would be preferable to ignore the bad characters
 and keep reading.  Either that or replace them with the unknown
 character.  It doesn't look like IOChannel provides a way to recover
 from this exception though, other than closing the IOChannel and
 giving up.

A couple of posts ago you were arguing it should abort (which you can
set it to do, as I mentioned).

I don't think GIOChannel is being developed any more.  The best thing
to do is to move to GIO.  GCharsetConverter (Gio::CharsetConverter) has
a 'use-fallback' property which seems to do what you want with
Gio::ConverterInputStream (although I have never tried it).

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

Re: Various questions about Gtk::PlacesSidebar

[Chris Vine]

On Tue, 03 Sep 2013 09:40:19 +0200
Murray Cumming murr...@murrayc.com wrote:
 On Mon, 2013-09-02 at 16:13 +0200, Krzysztof Kosiński wrote:
  2013/9/2 Kjell Ahlstedt kjell.ahlst...@bredband.net:
   Objects of classes that derive from Gtk::Object are not put in
   Glib::RefPtrs. I'm not sure why.
  
  I'm also a little confused by this but it probably has something to
  do with Gtk::manage().
 
 GtkWidgets don't use simple reference counting in the GTK+ C API. They
 can be destroyed at any time regardless of the reference count. So we
 can't use RefPtr with them easily.

That is not really true.  widgets are always (and only) destroyed when
their sunk reference count reaches 0, and incrementing the reference
count before removing a widget from a container is how you move them
between containers. There is no problem with holding a non-top level
widget by RefPtr provided you call g_object_ref() on the C object
first, which is inconvenient with gtkmm and leaves the opportunity to
forget to do so. So it is inadvisable.

With top level windows it would be highly confusing to take your own
reference in this way.  You expect a top level window to disappear when
you call gtk_widget_destroy() on it to drop GTK+'s top level reference,
not hang around.

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

Re: Various questions about Gtk::PlacesSidebar

[Chris Vine]

On Tue, 03 Sep 2013 22:34:51 +0200
Murray Cumming murr...@murrayc.com wrote:
 On Tue, 2013-09-03 at 21:20 +0100, Chris Vine wrote:
  On Tue, 03 Sep 2013 09:40:19 +0200
  Murray Cumming murr...@murrayc.com wrote:
   On Mon, 2013-09-02 at 16:13 +0200, Krzysztof Kosiński wrote:
2013/9/2 Kjell Ahlstedt kjell.ahlst...@bredband.net:
 Objects of classes that derive from Gtk::Object are not put in
 Glib::RefPtrs. I'm not sure why.

I'm also a little confused by this but it probably has
something to do with Gtk::manage().
   
   GtkWidgets don't use simple reference counting in the GTK+ C API.
   They can be destroyed at any time regardless of the reference
   count. So we can't use RefPtr with them easily.
  
  That is not really true.  widgets are always (and only) destroyed
  when their sunk reference count reaches 0,
 
 Calling gtk_widget_destroy() will destroy a widget. Containers destroy
 their child widgets by default in GTK+ with C.

On reflection I think you may well be right (except that it _is_ the
case that widgets will only be finalized when their reference count
reaches 0). gtk_widget_destroy() calls g_object_run_dispose() which
causes the object to drop all references to other objects.  This will
cause all containers to drop their references to it.  However, if the
references dropped includes other objects which are part of the
widget's own implementation then there are problems.

The documentation for gtk_widget_destroy() sort-of suggests that
keeping a reference will keep the widget alive: ... If the widget is
inside a container, the widget will be removed from the container. If
the widget is a toplevel (derived from GtkWindow), it will be removed
from the list of toplevels, and the reference GTK+ holds to it will be
removed.  Removing a widget from its container or the list of toplevels
results in the widget being finalized, unless you've added additional
references to the widget with g_object_ref().  It would be somewhat
pointless to not finalize the widget if in fact it is unusable.  At a
suitable opportunity I will do a test and see which result occurs.

However, GTK+ containers don't call gtk_widget_destroy(): users do.
GTK+ containers just drop their references when being finalized.

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

Re: What is the minimum number of lines to update a gui window without user clicking a button

[Chris Vine]

On Sun, 11 Aug 2013 08:33:18 -0400
L. D. James lja...@apollo3.com wrote:
[snip]
 I appreciate all the tips from all the experts here.  However, I can
 tell from many of the comments that a lot of you are thinking I'm
 trying to do something different that just learn how to work with a
 blank window and add text to it.

I think we all understand that perfectly well.  The problem you seem
to have difficulty in accepting is that you have to find a way of doing
that within the GUI's main loop.  The numerous responses you have
received have all been for the purpose of showing you how to do this.

What your headline console test case does is launch a process using
popen() and then read its stdout in blocking mode and print it to the
console.  You have two choices when faced with doing an equivalent to
this with a GUI:

1.  Launch the child process asynchronously and connect that process's
file descriptors to your main loop.  I suggested this, and pointed to
the tools glib provides for the purpose, which you thought inadequate
for your purposes. However, it is by far the easiest way to do it
because it avoids threads.

2.  Launch the child process synchronously as your console application
does. This requires starting a new thread to carry out the blocking
operations and finding some mechanism (which could be Glib::Dispatcher
or which could more easily, if it is only text, be a pipe) to convey
in a thread-safe way the information you want to convey from the new
thread to the main loop thread.

What I have said is true of any common GUI system which runs its own
main loop, whether GTK+, Qt or Windows.  Until you grasp the concept of
this you are going to struggle.  You will end up programming by
coincidence and bafflement.

There is no need to respond to this post.  But it does set out what
your two options are.

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

Re: What is the minimum number of lines to update a gui window without user clicking a button

[Chris Vine]

On Sun, 11 Aug 2013 10:18:59 -0400
L. D. James lja...@apollo3.com wrote:
 I learned from my previous thread how to actually update  the gui 
 window.  I agree that I don't have the terminology to put it into 
 technical words how it's done.  But that part is very simple.  I
 believe you're still trying to answer that question in this new
 thread.  I believe you think that I'm ungrateful for not changing to
 the conversation.

To be quite honest, I have no idea what you are talking about.

However, whatever else I think, be assured I do not think you are
ungrateful.

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

Re: What is the minimum number of lines to update a gui window without user clicking a button

[Chris Vine]

On Sat, 10 Aug 2013 05:43:42 -0400
L. D. James lja...@apollo3.com wrote:
 When I first started programming and was able to output a Hello
 World, I was happy.  It worked.  I made lots of changes and
 understood it. When I performed my first I/O  it was just a minimum
 number of lines and did a strictly limited task.  I was able to
 dissect it in one short session, then start using it productively in
 my crude programs.
 
 I'm trying to find this same strict focus with outputting and updating
 the gtkmm gui (without user input).  If I can understand this, I'll
 have a foundation of which I could build upon.

The point you may not understand is that you would rarely if ever want
to do this in a simple real-world application, and particularly where
your simple application is a learning exercise about using GTK+. GTK+
is, like almost all other GUI toolkits, event driven, and runs in a main
loop. Therefore, if text arrives which you want to put in a widget, it
would normally arrive as an event.  If you are monitoring I/O, you
would use Glib::signal_io().connect() to connect a file descriptor or
Glib::IOChannel object to the main loop. Similar convenience functions
are available for timeouts and idle handlers.

I would strongly advise you not to get involved in using threads until
you have more programming experience.

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

Re: What is the minimum number of lines to update a gui window without user clicking a button

[Chris Vine]

On Sat, 10 Aug 2013 09:32:58 -0400
L. D. James lja...@apollo3.com wrote:
[snip]
 As far as realworld applications, most applications have some element
 of processing and outputting a status to the user without the user
 having to sit at the concole and constantly click buttons.  I really
 appreciate your input and suggestions.  But I believe you're
 misunderstanding the question.  I realize buttons and user input is
 an important part of applications.  However, at present, I would just
 like to be able to output notifications to my clients into a gui
 window without my application having to be hung until they come to
 the computer and click a button.  The purpose of what I'm trying to
 do is allow the user to know at which stage the application has
 progressed, and to be able to report to me any messages, errors
 status updates that I present.  As far as the VPN connection, if my
 program is waiting for an internet connection, it will state that.
 When it has the connection, without the user having to come back and
 tell the program to continue, it will just update, internet
 connection established, the remote host is currently off line... will
 try again in 5 minutes.  The  present console program eventually
 says, vpn connection established now configuring the local routing.
 
 I have many applications (or c++ routines) to do things such as that.
 They all output to a black screen.  They frighten my customers.  I
 hope to find a simple way of outputting the status to a friendly gui
 window.
 
 I don't mean to sound ungrateful with my reply, but I'm hoping that
 I'm clarifying what I'm trying to do, and that it does have some
 merit.

Your posts are no doubt highly meritorious but I am afraid they are not
offering much clarification.  You would probably make your point better
if you shortened your posts by roughly an order of magnitude.  However,
after cutting through the dense undergrowth, I still think you have
failed to understand how programs using event loops work.  If the
program is not just running a single batch of instructions, it has to
have a loop in there somewhere, which is blocking until there is
something to process.  The simplest loop for your console program would
involve blocking on select() or poll(), for which purpose presumably
you must have a file descriptor to poll on.  In that case, as I said,
you can do the same with Glib::signal_io().connect().  Or maybe you are
polling using timeouts, in which case the equivalent for gtkmm is
Glib::signal_timeout().connect().

Why not get to the heart of the matter, and post a short compilable
console program, cut down from the ones which you appear to have written
for monitoring VPNs, but of no more than 50 lines, and we can tell you
how to do the same using a graphical interface.

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

Re: What is the minimum number of lines to update a gui window without user clicking a button

[Chris Vine]

On Sat, 10 Aug 2013 12:16:16 -0400
L. D. James lja...@apollo3.com wrote:
[snip]
 The VPN application currently have 500 lines.  I'll strip it down to
 50, making sure it retains functionality and post it.
 
 One of the reasons I didn't post it before, but posted sleep(10) to
 represent the application was doing something, because the program is
 designed to make changes to the system.  But, I'm sure I'll be able to
 comment and have such a flow that you might be able to easily follow
 it just by looking at it, or, on your own, comment out the parts that
 makes changes.

If an outline of your code just consists of:

void check_stuff() {
  if (vpn_connections_changed()) std::cout  XXX changed\n;
}

int main(int argc, char* argv[]) {
  for (;;) {
sleep(10);
check_stuff();
  }
  return 0;
}

Then in gtkmm this just becomes:

bool check_stuff() {
  if (vpn_connections_changed()) std::cout  XXX changed\n;
  return true;
}

int main(int argc, char* argv[]) {
  Gtk::Main app(argc, argv);
  Glib::signal_timeout().connect_seconds(sigc::ptr_fun(check_stuff), 10);
  app.run();
  return 0;
}

You can go from there and add your graphical interface to check_stuff()
in place of the call to std::cout.  You might, for example, want to
display a Gtk::MessageDialog object.  With gtkmm-3.0, you might want
to use Gtk::Application instead of Gtk::Main.  But first things first.

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

Re: What is the minimum number of lines to update a gui window without user clicking a button

[Chris Vine]

On Sat, 10 Aug 2013 17:53:41 -0400
L. D. James lja...@apollo3.com wrote:
[snip]
 Chris, thanks again for your interest in my question.  I apologize
 for the delayed response, as I was on a support call for most of the
 day. When I got back I trimmed down 500 lines of code to the example
 below.
 
 This is 48 lines of my vpn connection routine. It's 48 out of the 500 
 line application. In those 48 lines I have 4 lines outputting to the 
 console. I would like for those lines to output to a gui window.
 
 Those 4 lines are just some of the actually 25 lines of status that
 will be output in the course of running the application. While it's
 running and checking the connection it outputs either starts * or
 dots . at 10 second interval while it checks some of the file and
 connection status.
 
 
 // code begin
 // -
 #include iostream
 #include fstream
 #include unistd.h
 #include string
 using namespace std;
 int main(int argc, char* argv[]) {
  string ret;
  string server;
  string command;
  string runit(string c);
  setuid(0);
  server = argv[1];
  string peerentry = /etc/ppp/peers/ + server;
  command = ls  + peerentry;
  ret = runit(command);
  if (ret != peerentry){
  cout  Problems locating server:   server  endl; // 
 console out
  return 1;
  }
  string filetest = /var/run/ppp- + server + .pid;
  ifstream myfile(filetest.c_str());
 
  if (myfile.is_open()){
  cout  Connection is in effect  endl; // console out
  myfile.close();
  }
  else{
  cout  Connecting to...  server  endl; // console out
  command = pppd call  + server;
  ret = runit(command);
  cout  Results: [  ret  ]  endl; // console out
  }
  return 0;
 }
 string runit(std::string c){
  string lret = ;
  c +=  21;
  FILE *in;
  char buff[512];
  if (!(in = popen(c.c_str(), r))){
  return lret;
  }
  while (fgets(buff, sizeof(buff), in) != NULL){
  lret += buff;
  }
  pclose(in);
  return lret;
 }
 // -
 // code end

This appears to be just a batch job calling popen() which brings up a
ppp connection. There is no program loop anywhere and the while
loop for fgets() in runit() will block until EOF is reached, which
equates to the call to pppd ending and the process in which it is
running closing its stdout. Presumably you run this as a cron job, or
something like that? Or, since you say, while it's running and
checking the connection it outputs either starts '*' or dots '.' at 10
second interval while it checks some of the file and connection status,
possibly you have excised the loop logic, which is the interesting part
for present purposes. (As it happens, it will not compile because the
prototype for runit() is not in namespace scope, but that is no doubt
just a matter of transcription.)

To call up an executable (in this case pppd) in this kind of usage
using glib you would normally use Glib::spawn_async_with_pipes() and
connect to the standard_output and standard_error file descriptors with
Glib::signal_io().connect(). The problem you have got here though is
that you call setuid(0) on a binary which presumably has its suid bit
set in order to launch pppd. You should definitely not do that directly
with a GTK+ program.  You would need to have a small wrapper with suid
set which calls up pppd, which is launched by your GTK+ program using
Glib::spawn_async_with_pipes().  (Yuck.)

As it happens, if you want a short cut for a batch job like this which
provides a GTK+ user interface, I would consider a shell script and
zenity, which is what zenity was intended for.  A google search will
tell you more. However you would still need to circumvent your setuid
problem.

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

Re: What is the minimum number of lines to update a gui window without user clicking a button

[Chris Vine]

On Sat, 10 Aug 2013 19:41:33 -0400
L. D. James lja...@apollo3.com wrote:
[snip]
 While I'm having problems just sending text to a window, you're 
 suggesting that I dive figure and use gtkmm for my other calls.  I
 might get to that at some time.  But at present, I just want to use
 gtkmm to output to a gui screen instead of a black screen.

You keep missing the point.  If you don't want to use zenity, as I said
use Glib::spawn_async_with_pipes() and Glib::signal_io().connect().
That is the correct way to do it.

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

Re: Memory leak when using Gio::File

[Chris Vine]

On Thu, 23 Aug 2012 11:25:44 +0600
Galymzhan kozha...@gmail.com wrote:
 Using Gio::init() instead of g_type_init() does not make a difference.
 There is still a leak:
 
 
 ==2885== LEAK SUMMARY:
 ==2885==definitely lost: 40 bytes in 1 blocks
 ==2885==indirectly lost: 120 bytes in 10 blocks
 ==2885==  possibly lost: 13,975 bytes in 258 blocks
 ==2885==still reachable: 79,346 bytes in 1,424 blocks
 ==2885== suppressed: 0 bytes in 0 blocks
 
 
 Here is a full valgrind summary: https://gist.github.com/3432925
 Also, I tried to reset RefPtr's pointer with `file.reset();` but that
 does not help. Is there any method of Gio::File which is supposed to
 do closing or cleanup?

It almost certainly isn't a leak.  For a start, it doesn't look from
your earlier posting that you turned off memory slices (which uses
caching) by forcing use of malloc or followed the other advice on using
valgrind with gobject/gtk+. Even if you did, glib doesn't free one time
allocations made on type initialisation when exiting, for efficiency
reasons.

The gnome webpage on using gtk+ with valgrind also has some links to
suppressions files which may or may not be suitable for your purposes.

Or you could use your example as the beginnings of your own suppression
generator.

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

Re: gtkmm 3.4.0 (gtk 3.4.2) multithread app graphic deterioration

[Chris Vine]

On Sun, 8 Jul 2012 21:44:47 -0400
Paul Davis p...@linuxaudiosystems.com wrote:
 the simplest solution is actually to use the GDK idle handler.
 whenever you receive data that requires some sort of redraw, you queue
 up an idle callback that will call someWidget.queue_draw() and then
 returns false (so that it is not called again). i tend to do this with
 C (g_idle_add()) rather than C++ but IIRC the syntax is something
 like:
 
 Glib::SignalIdle().connect (sigc::ptr_fun
 (somethingThatWillQueueARedraw));
 
 or
 
 Glib::SignalIdle.connect (sigc::mem_fun (some_object,
 Object::someMethod));
 
 Glib::Dispatcher is a more general purpose mechanism that is actually
 built on the idle mechanism if i recall correctly.

Glib::SignalIdle.connect() is not thread safe and should definitely
not be used for what the OP wants.

Glib::SignalIdle.connect_once() is hoped to be thread safe as of about
2 months' ago provided that the slot object does not represent a
non-static method of a class deriving from sigc::trackable, but I don't
think that has hit a main release yet. (Hoped to be means that I
don't think anyone has stress tested it yet, but the code was committed
some 2 months' ago.)

Glib::Dispatcher doesn't use the idle mechanism.  On unix like systems
it uses a pipe.  On win32 it uses event objects.

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

Re: gtkmm 3.4.0 (gtk 3.4.2) multithread app graphic deterioration

[Chris Vine]

On Mon, 9 Jul 2012 07:47:52 -0400
Paul Davis p...@linuxaudiosystems.com wrote:
 ah, OK. this helps explain why i continue to use g_idle_add() for this
 purpose, then :)
 
 actually, to be fair, i don't use g_idle_add() a lot, but rather my
 own implementation of the same concept that Glib::Dispatcher
 represents.

Ditto me.  I have something similar to Glib::Dispatcher, but which is
entirely thread-safe so any thread can access all of its methods and
avoids the sigc::trackable problem, and also my own entirely thread-safe
wrapper for idle sources.

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

Re: gtkmm 3.4.0 (gtk 3.4.2) multithread app graphic deterioration

[Chris Vine]

On Mon, 09 Jul 2012 16:59:31 +0200
Kjell Ahlstedt kjell.ahlst...@bredband.net wrote:
 2012-07-09 12:05, Chris Vine skrev:
  Glib::SignalIdle.connect_once() is hoped to be thread safe as of
  about 2 months' ago provided that the slot object does not
  represent a non-static method of a class deriving from
  sigc::trackable, but I don't think that has hit a main release yet.
  (Hoped to be means that I don't think anyone has stress tested it
  yet, but the code was committed some 2 months' ago.)
 
 
 Hi Chris,
 
 I suppose you refer to the changes mentioned in bug 
 https://bugzilla.gnome.org/show_bug.cgi?id=396963, which you helped
 me to get (hopefully) correct. Those two commits were pushed on April
 3 and 4, and they are included in glibmm 2.32.

Kjell,

Yes, that's the one I was thinking of.  Good to know it is now out
there.

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

Re: gtkmm 3.4.0 (gtk 3.4.2) multithread app graphic deterioration

[Chris Vine]

On Sun, 8 Jul 2012 08:53:28 +0200
Giuseppe Penone gius...@gmail.com wrote:
 Thank you Chris, I'll read more about this Glib::Dispatcher, in the
 past I already took a look but then discouraged and used gdk lock
 that I already was able to use.

The main problem you will come across using Glib::Dispatcher is passing
data to the callback.  For that, it is best to use an asynchronous
queue.

In another posting you said your program does a lot of input-output.
You don't need threads just for that: you can set up a watch on a
file descriptor for the main GUI thread using
Glib::signal_io().connect(). GIO/giomm also has a wide range of
asynchronous IO functions where all the hard work is done for you.

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

Re: gtkmm 3.4.0 (gtk 3.4.2) multithread app graphic deterioration

[Chris Vine]

On Sat, 7 Jul 2012 10:13:39 +0200
Giuseppe Penone gius...@gmail.com wrote:
 Many thanks,
 Giuseppe.
 
 
 On Sat, Jul 7, 2012 at 9:14 AM, Kjell Ahlstedt
 kjell.ahlst...@bredband.netwrote:
 
  I don't know if this is any help, but anyway, have you seen these
  comments at
  http://developer.gnome.org/**gdk3/stable/gdk3-Threads.htmlhttp://developer.gnome.org/gdk3/stable/gdk3-Threads.html
 
  -- Unfortunately the above holds with the X11 backend only. With
  the Win32 backend, GDK calls should not be attempted from multiple
  threads at all.
 
  -- Before calling gdk_threads_leave() from a thread other than your
  main thread, you probably want to call gdk_flush() to send all
  pending commands to the windowing system.
 
  Kjell
 
  2012-07-05 14:52, Giuseppe Penone skrev:
 
   Hi,
  I'm writing a multithread app where different threads operate on
  the graphic.
  The non gui threads operate on graphic only after semaphores:
 
  gdk_threads_enter();
  OPERATION ON GUI FROM NON GUI THREAD
  gdk_threads_leave();
 
  and the gui thread is opened this way:
 
  g_thread_init(NULL);
  gdk_threads_init();
  Gtk::Main  kit(argc, argv);
  ...
  gdk_threads_enter();
  Gtk::Main::run(p_window);
  gdk_threads_leave();
 
  After some time the gui starts to deteriorate as in screenshot
  http://www.freeimagehosting.**net/hjltxhttp://www.freeimagehosting.net/hjltx(label
  over an icon, columns not expanding...). I have no clue about what
  could be wrong since there is no warning/error from the terminal
  while in the past when I missed a
  gdk_threads_enter/gdk_threads_**leave I had errors printed and the
  app crashed.
 
  Can anybody help me to understand where the error could be given
  the screenshot?
  I'm also considering porting the app back to gtkmm2 but since I
  use glade I'm afraid this will be not that easy.

Calling up the GDK global lock is not a good way to do it with gtkmm
because (amongst other things) libsigc++ is not thread safe.  You might
want to read the attachment to the now very old bug report at
https://bugzilla.gnome.org/show_bug.cgi?id=512348 for an explanation of
how to do it.  (The lack of priority given to threading issues might
also be something you want to consider.)

If you do want to use the global lock, you should in any event move the
call to gdk_threads_enter() so that the instantiation of Gtk::Main is
within it, as well as making sure that all access to libsigc++ objects
by multiple threads, including any unseen access arising from the
operation of sigc::trackable, are within a mutex (which might of
course be the global lock).

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

Re: gtkmm 3.4.0 (gtk 3.4.2) multithread app graphic deterioration

[Chris Vine]

On Sun, 8 Jul 2012 00:16:24 +0200
Giuseppe Penone gius...@gmail.com wrote:
 I'm not very experienced in c++ and gtkmm, so far (after reading
 http://developer.gnome.org/gdk3/stable/gdk3-Threads.html)
 I did protect the following graphics calls:
 
 1) from non main threads
 2) the glib timeout calls
 
 are you saying I have to protect also every single gtk callback? This
 would be very bad of gtkmm :(

No.  I am saying three things:

1.  Don't use the gdk global lock at all with gtkmm; use
Glib::Dispatcher instead.

2.  However, if you insist on using the gdk global lock, protect all
calls to libsigc++ objects which are accessed in more than one thread
(and avoid sigc::trackable).  Also of course, comply with all the other
things in the documentation to which you have referred.

3.  Best of all, combine 1 above with reading the attachment to the bug
report I mentioned in my earlier post.  That will tell you how to
program threads safely in gtkmm.  (Here is an even more direct html
reference to it:
http://bugzilla-attachments.gnome.org/attachment.cgi?id=201915 ).

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

Re: Save files with correct character set

[Chris Vine]

On Thu, 22 Mar 2012 00:58:01 +0100
Spazzatura.Live kharho...@hotmail.com wrote:
 I'm trying to save the content of a Glib::ustring to a file. I tried 
 using the Glib::file_set_contents but it uses the std::string, and so
 it writes a non-unicode file.

That's wrong.  The std::string object will hold whatever encoding you
put in it.  std::string objects just hold octets.

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

Re: Save files with correct character set

[Chris Vine]

On Thu, 22 Mar 2012 20:11:31 +0100
Spazzatura.Live kharho...@hotmail.com wrote:
 You're right, the content is UTF-8, so my problem is that i don't need
 one like that.
 
 I thought the casting from Glib::ustring to std::string also made a
 conversion of the content (from unicode char) so the file has wrong
 extended character so that was the issue...
 
 Probably, instead, is the tool i use after which doesn't support
 Unicode file (i mean files with Unicode character encoding).
 
 So the new question is that: How can i convert the Glib::ustring from
 Unicode to ASCII (ISO-8859-1) and save to file?

ISO-8859-1 (Latin-1) is not ASCII.  It uses the 8th bit for non-ASCII
characters.  Latin-1 and UTF-8 are ASCII compatible if you stick to the
ASCII character set.

If you are saving data to file, it is much better to save it in unicode
format as UTF-8, and if you need to convert it, convert it when reading.
However, if you really think you need to convert to Latin-1, use
Glib::convert().

But what drew you to Latin-1?  If that is your locale encoding, it won't
necessarily be other people's locale encoding, and for that reason
saving data to file in the locale encoding is generally a bad idea, as
it is non-portable. However, if that is not an issue, you could use
Glib::locale_from_utf8().

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

Re: Save files with correct character set

[Chris Vine]

On Thu, 22 Mar 2012 22:07:03 +0100
Spazzatura.Live kharho...@hotmail.com wrote:
 It doesn't work:
  Saving file failed: Invalid byte sequence in conversion input
 
 Using: Glib::file_set_contents(filename, 
 Glib::locale_from_utf8(TextView.get_buffer()-get_text()));

OK, that means that ISO-8859-15 is not your locale encoding.  Use
Glib::convert().

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

Re: Save files with correct character set

[Chris Vine]

On Thu, 22 Mar 2012 22:27:44 +0100
Spazzatura.Live kharho...@hotmail.com wrote:
 Right, I forgot... My locale is utf8...
 
 As to_codeset variable should I just use: iso-8859-15?

'iconv -l' will tell you what your system supports.  ISO8859-15 looks
to be appropriate. My system doesn't have ISO-8859-15 (it does however
have ISO_8859-15, which is a synonym for ISO8859-15.

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

Re: Webkit in Gtkmm

[Chris Vine]

On Sun, 26 Feb 2012 14:46:53 +0100
 
 Thank you, i've now moved from using a thread to using a timeout
 handler and that works.
 Now i'm also using a Gtk::Grid instead of a Gtk::Table. The Gtk::Grid
 is being created in a derived Gtk::ScrolledWindow. In this
 MyScrolledWindow the update is being made periodically. But if i
 attach new widgets to the grid, using grid-attach, the scrollbar of
 MyScrolledWindow disappears and i get:
 Gtk-CRITICAL **: gtk_widget_get_preferred_width_for_height: assertion
 `height = 0' failed
 Whats the correct way of dynamically extending a Gtk::Grid? is this
 also possible with a Gtk::Table or a Gtk::Box?

Everything you do to a Gtk::Box is dynamic.  I haven't used Gtk::Grid,
but I thought the same was true of that also.  With Gtk::Table, you
call Gtk::Table::resize() to resize a table after it has been created.

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

Re: Webkit in Gtkmm

[Chris Vine]

On Sat, 25 Feb 2012 20:18:52 +0100
 Hello,
 
 I'm fairly new to programming with c++ and gtkmm.
 I'm trying to write an application to display status.net statuses. The
 statuses are being displayed in a derived Gtkmm::Table. Every row is
 one status. Every status is a webkit GtkWidget, wrapped with
 Glib::wrap. This works quite well.
 Now i'm trying to create a thread, to fetch the statuses periodically.
 In the thread the fetching is done and new statuses are being put into
 a private std::list of the derived Gtkmm::Table. Then an update signal
 is emitted, which triggers a function to redraw the table (put the new
 statuses in webkit GtkWidget, wrap them and attach them to the table).
 But this doesn't work with webkit. As soon as i try to create a
 GtkWidget with webkit_web_view_new() the program crashes. I've no idea
 why, can anybody help? Or is there a better solution to do this, not
 using a thread?
 
 thanks,
 birger

Try reading this:
http://bugzilla-attachments.gnome.org/attachment.cgi?id=201915
which has been lost in the mists of unawesomeness.

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

Re: Glib::ustring and C++11 utf-8 literals

[Chris Vine]

On Thu, 16 Feb 2012 11:04:19 +0100
Dénes Almási de...@rudanium.org wrote:
 Hi! 
 
 As one can see on wikipedia, C++11 offers the ability to
 create utf-8 string literals.
 (http://en.wikipedia.org/wiki/C%2B%2B11#New_string_literals [1])
 Is it
 possible to pass these safely to Glib::ustring when constructing them?
 
 
 It is suspicious that 
 Glib::ustring::ustring(const char * _src_,
 size_type _n_ )
 constructor will do the job. Is this right?

All string literals are null terminated after conversion to the
execution character set, so you pass it to the constructor taking a
const char*.  The requirement of Glib::ustring is that this execution
character set must be UTF-8.

I have not done any playing about with C++11 string literals, but as I
understand it you should be OK with a string literal with the 'u8'
prefix assuming the compiler is able to perform the conversion from the
source character set, what your code editor spits out, to this execution
character set (see §2.2/5: Each source character set member in a
character literal or a string literal, as well as each escape sequence
and universal-character-name in a character literal or a non-raw string
literal, is converted to the corresponding member of the execution
character set; and §2.4.15/7: A string literal that begins with u8,
such as u8asdf, is a UTF-8 string literal and is initialized with the
given characters as encoded in UTF-8).

The key to this is my assuming the compiler ... above: the problem is
that you have to let the compiler know what your source character set is
in order for it to perform this conversion, and gcc will in the absence
of the appropriate switch assume your source file is in your locale
encoding, which makes source files non-portable with non-ASCII string
literals unless you are importing whole unicode code points into your
u8 string (for which purpose the u8 prefix is genuinely useful).

For more on gcc, see
http://gcc.gnu.org/onlinedocs/cpp/Character-sets.html and also the gcc
switch documentation:

  -finput-charset=charset:  Set the input character set, used for
  translation from the character set of the input file to the source
  character set used by GCC. If the locale does not specify, or GCC
  cannot get this information from the locale, the default is UTF-8.
  This can be overridden by either the locale or this command line
  option. Currently the command line option takes precedence if there's
  a conflict. charset can be any encoding supported by the system's
  iconv library routine.

If you use windows, I believe VS uses Windows ANSI as its default
source encoding, but you would need to look it up if that is your
platform.

This makes it almost always better to pass in your string literals
programmatically, say via gettext().

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

Re: No yet encrypted...

[Chris Vine]

On Tue, 06 Dec 2011 11:58:59 +0100
Kjell Ahlstedt kjell.ahlst...@bredband.net wrote:
 2011-12-05 21:04, Chris Vine skrev:
  On Mon, 5 Dec 2011 18:27:43 +0100
  Glus Xofgtg...@gmail.com  wrote:
 
  The problem, here, is that this code works fine with one-byte
  characters string but breaks with multi-byte characters strings !
  It would help if you said what breaks means.  Do you mean it
  throws a conversion exception?   If so then:
 
std::cout  Glib::ustring::compose(# %1, mess).raw()
std::endl;
  Thanks, was that... !
  You have found the problem, but as I said in my original problem
  this is a diagnostic and not the fix. You should not put text into a
  Glib::ustring object which is not in utf-8 encoding.  Use a
  std::string object instead and don't use the ustring composing
  functions.
 
  Chris
 
 Isn't the problem here that r_mess and mess _are_ utf-8 encoded, but 
 operator(std::ostream, const Glib::ustring) can't convert to the 
 encoding used for printing?
 You may find some useful information in bug 661588, 
 https://bugzilla.gnome.org/show_bug.cgi?id=661588.
 
 And I agree with Chris Vine that you should have been more specific. 
 The program throws a Glib::ConvertError exception with message 
 BlaBlaBla is much more informative than The program breaks.

Who knows?  The encoding is whatever is sent over the socket. As I
mentioned in my original response, it could be that
std::locale::global(std::locale()) (or setlocale(LC_ALL,)) has not
been called, so that the conversion from utf8 to the locale encoding
fails.

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

Re: No yet encrypted...

[Chris Vine]

On Mon, 5 Dec 2011 17:32:30 +0100
Glus Xof gtg...@gmail.com wrote:
[snip]
         g_free (r_mess);
 
         std::cout
                   Glib::ustring::compose (# %1, mess)
                   std::endl;
 
 
 The problem, here, is that this code works fine with one-byte
 characters string but breaks with multi-byte characters strings !

It would help if you said what breaks means.  Do you mean it throws a
conversion exception?   If so then:

  std::cout  Glib::ustring::compose(# %1, mess).raw()
 std::endl;

will probably work, but you need to consider your character encodings
more carefully to cover all cases, as this is not of itself a robust
solution. It would mean that the text you are putting into 'mess' is
not in fact in utf-8 encoding, or you have done something else wrong
like not calling std::locale::global(std::locale()).

What calling ustring::raw() would do here is suppress the implicit
conversion into the locale encoding carried out by the operator()
overload for Glib::ustring.

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

Re: No yet encrypted...

[Chris Vine]

On Mon, 5 Dec 2011 18:27:43 +0100
Glus Xof gtg...@gmail.com wrote:

  The problem, here, is that this code works fine with one-byte
  characters string but breaks with multi-byte characters strings !
 
  It would help if you said what breaks means.  Do you mean it
  throws a conversion exception?   If so then:
 
   std::cout  Glib::ustring::compose(# %1, mess).raw()
              std::endl;
 
 Thanks, was that... !

You have found the problem, but as I said in my original problem this is
a diagnostic and not the fix. You should not put text into a
Glib::ustring object which is not in utf-8 encoding.  Use a std::string
object instead and don't use the ustring composing functions.

Chris


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

Re: Can a Multi-Threaded GTKMM Application Use std::thread Rather Than Glib::Thread?

[Chris Vine]

On Tue, 18 Oct 2011 12:49:43 +1300
Gavin Lambert gav...@compacsort.com wrote:
 There will be some caveats; despite using the same kernel primitives
 they might not be using the same glibc elements, or may tack on
 additional data. As such, you probably won't be able to convert a
 std:: mutex into a Glib:: mutex, although in principle there
 shouldn't be any problem in using a std:: mutex to wake up a Glib::
 thread, or vice versa.  (This may depend on the specific
 implementation of the library you use.)
 
 It's also possible that one or the other have particular per-thread
 init or cleanup requirements which won't be met by the other (I
 recall the Win32 days when the CRT got grumpy if you used
 CreateThread instead of _beginthread, and MFC got grumpy if you used
 either instead of AfxBeginThread); I'm not really familiar enough
 with either threading model to say definitively whether this will or
 won't be an issue here.

Anyone who tries to convert a Glib::Mutex to a std::mutex, or to
terminate a thread with a different call set from the one which created
it, deserves everything they get.

I can't see any reason why using std::mutex to lock data in a thread
created by Glib::Thread::create() should cause any difficulty.  It
would be extremely difficult to create such a difficulty, as mutexes lie
in the kernel. As well as being difficult, it would also be completely
perverse for the gcc libstdc++ authors to pervert their system calls so
as make std::mutex incompatible with gcc's pthread mutex
implementation, and equally perverse for the visual studio authors to
make std::mutex incompatible with windows critical sections.  Amongst
other things, it would make it impossible for programs written for
std::thread to call into native windows or unix-like libraries which
happen to use their respective native implementations.

Chris


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

Re: Can a Multi-Threaded GTKMM Application Use std::thread Rather Than Glib::Thread?

[Chris Vine]

On Sun, 16 Oct 2011 23:35:07 +0100
Chris Gordon-Smith c.gordonsm...@gmail.com wrote:
 Hello Chris
 
 Thanks for this. Yes - I've used Glib::Dispatcher, thanks to a large
 degree to your posting to this list back in March!
 
 I have used Glib::Thread to give myself a GUI Thread and a simulation
 thread, so that my GUI remains active even while the simulation is
 running. I now have a choice if I want to multithread the simulation
 thread for parallelism. Either I extend the use of Glib::Thread, or I
 use std::thread, in which case anyone trying to understand my program
 (including me!) has to understand two threading systems. 

Since we now have an approved C11 standard (passed its ballot and
awaiting ISO publication) as well as a C++11 standard (just recently
formally published), each with threading and memory consistency models
which deliberately map onto each other, the proper approach would
probably now be for glib to drop its own threading implementation.

I don't necessarily see that happening in the near future, if only to
avoid glib API breakage, but it argues against a my way or the
highway approach by glib to threading, something which it appears
just recently to have avoided.

You will find very little difficulty moving between glibmm threads and
C++11 threads if you keep away from such things as futures/promises, or
for that matter in moving between pthread/Gthreads and C threads.
Programmers used to the windows threading API will have more work to do.

Chris


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

Re: Can a Multi-Threaded GTKMM Application Use std::thread Rather Than Glib::Thread?

[Chris Vine]

On Mon, 17 Oct 2011 21:57:00 +0100
Chris Gordon-Smith c.gordonsm...@gmail.com wrote:
 [snip]
 So the way ahead for my project is:-
 
 *  Continue using Glib::Thread and Glib::Dispatcher to keep two
separate Glib threads in my program - one for the GUI and one for
the simulation
 *  If and when I want to multithread the Glib simulation thread to
take advantage of the multi-core processors that are now widely
available, I'll use std::thread
 *  If and when gtkmm can support multithreading without use of
Glib::Thread, I'll update my program accordingly
 
 Having two threading systems in the same program adds a bit of
 complication, but (assuming its feasible) I think its better than
 making the program more reliant on Glib::Thread than is essential.
 
 I suppose that the two systems should not interfere. From the point of
 view of Glib, there will be two threads, a GUI thread and a Simulation
 thread. The std threading system will probably not 'know' that there
 is a GUI thread. It will just know that it has taken an original
 Simulation thread and split it into several parallel ones.

I think you looking at it the wrong way.  Threads don't know
anything, they just share address space.

I see no particular reason to split things up as you propose: just use
one threading interface or the other for everything.  Just make sure
you have called Glib::thread_init() if using glib  2.24, or
Glib::thread_init(), g_type_init() or instantiated Gtk::Main if using
glib  2.32, in order to make glib thread safe, and use
Glib::Dispatcher for inter-thread communication, and you are ready to
go.

As it happens I generally don't use either std::thread (to the best of
my knowledge g++ doesn't support it properly yet) nor GThreads in my
GTK+/glib programs. I normally use pthreads directly, as it does a
number of things that GThreads don't do, together with Glib::Dispatcher
or things equivalent to Glib::Dispatcher for inter-thread communication.

Chris


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

Re: Can a Multi-Threaded GTKMM Application Use std::thread Rather Than Glib::Thread?

[Chris Vine]

On Mon, 17 Oct 2011 23:19:08 +0200
Murray Cumming murr...@murrayc.com wrote:
 On Mon, 2011-10-17 at 21:57 +0100, Chris Gordon-Smith wrote:
  Thanks. This makes sense to me. I agree that Glib should eventually
  drop its own threading implemention. As things stand now, the
  requirement for GTKmm programmers to use Glib::Thread impedes the
  adoption of the standard - std::thread. 
 
 Then this is something that someone should talk to the glib developers
 about.
 
Glib::Thread doesn't impede the use of std::thread or C threads, and it
now appears that there is now no intention to do so (a great deal of
code would be broken if that was attempted). It is an alternative.

Incidentally, is anything happening about bug #512348?

Chris


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

Re: Can a Multi-Threaded GTKMM Application Use std::thread Rather Than Glib::Thread?

[Chris Vine]

On Mon, 17 Oct 2011 23:40:01 +0100
Chris Gordon-Smith c.gordonsm...@gmail.com wrote:
[snip]
 Hmmm. Are you saying that instead of calling Glib::Thread::create, I
 could call the equivalent for std::thread? If feasible, it would be a
 definite improvement over what I am currently doing.

Yes.

There is no magic to threads.  They are threads of execution started by
the kernel (in the case of linux, by the clone() call).  Mutexes and
semaphores are executed in the kernel (in the case of linux by the
futex system calls).  glibc's pthreads implementation calls into these.
glib (on unix-like systems) in turn calls into glibc's pthreads.  gcc's
C11 and C++11's std::thread implementations will probably call into
glibc's pthreads implemention on unix-like systems also, although I
guess it is possible that they might go into glibc directly in other
ways. But they will all use the same kernel primitives

As it happens C11 and C++11 threads require some relaxed memory ordering
options for its atomics that pthread doesn't provide (pthreads and
windows threads provide stricter/safer sequential memory ordering), and
that may require a dip into processor specific assembly code.  But it
almost certainly will be a pthreads based implementation underneath on
unix-like systems so that std::thread::native_handle() can return
something meaningful.

If you are using windows, again I suspect visual studio's implementation
of std::thread calls into windows thread primitives.  But if in doubt,
send them an e-mail.  (Microsoft are pretty responsive on this kind
of thing.)

Chris


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

Re: Can a Multi-Threaded GTKMM Application Use std::thread Rather Than Glib::Thread?

[Chris Vine]

On Sun, 16 Oct 2011 19:44:53 +0100
Chris Gordon-Smith c.gordonsm...@gmail.com wrote:
 My question is: Could I have avoided use of Glib::Thread altogether,
 and just used std::thread?

You can use C++11 threads fine with glib/glibmm, because the C++
standard library will almost certainly use the native threading
implementation underneath (pthreads or windows threads) - that is
expected by std::thread::native_handle() - but even if it doesn't, it
will use the same kernel primitives. However, to do anything meaningful
with your program you will probably have to communicate with the thread
running the GTK+ gui from time to time. If you are going to avoid using
the GDK global lock, which is much to be desired, then you will end up
using Glib::Dispatcher, and so glibmm.  You will also need to make glib
thread safe by a call to Glib::Thread::init(), although this
requirement will disappear once glib-2.32 comes out.

This is touched upon by the draft documentation at the end of this now
very lengthy bug report at on glibmm/gtkmm threading at
https://bugzilla.gnome.org/show_bug.cgi?id=512348 , which might give
you some tips, but has become becalmed by a lack of interest.

Chris


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

Re: Gtk::Frame not drawing any shadow

[Chris Vine]

On Mon, 3 Oct 2011 16:23:56 +0200
Johannes Marbach j...@rapidrabbit.de wrote:
 The Gtk::Frame widget does not draw any shadow at my end. If for
 instance I compile and run the attached sample code, I only get this
 http://img94.imageshack.us/img94/4446/screenshotat20111003162.png. Is
 this intended behaviour (maybe related to Gtk+3) or am I doing
 something wrong? I'm running gtk and gtkmm version 3.2.0

It's a problem with both the default gtk+3 theme (which will show a
border but only with a shadow in) and the adwaita gnome-3 themes, which
won't show a shadow at all.

I suggest you file a bug at gnome bugzilla.

Chris


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

Re: more size questions

[Chris Vine]

On Mon, 12 Sep 2011 19:45:14 -0600
D. R. Evans doc.ev...@gmail.com wrote:
 PS Is there a way to file bug reports against the gtkmm
 documentation? I would hate for someone else to spend as much time as
 I did harbouring the mistaken belief that the Fixed documentation was
 correct.

Yes, file a bug at gnome bugzilla for the gtkmm component.  While you
are at it, file a bug for gtk+ as well, as the gtkmm documentation
copies the gtk+ documentation (although, on this point, is not
autogenerated from it).

Chris


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

Re: Handling utf8 data from SQLite

[Chris Vine]

On Mon, 12 Sep 2011 10:42:46 +1200
Gavin Lambert gav...@compacsort.com wrote:
 Quoth Chris Vine:
  try {
std::cout  DB - Password:   password  std::endl;
  }
  catch (Glib::Exception e) {
std::cerr  e.what().raw()  std::endl;
  }
  catch (std::exception e) {
std::cerr  e.what()  std::endl;
  }
 
 If you're going to catch exceptions as references (which you should),
 make sure you catch them as const references.  Otherwise they may not
 catch all throw cases.

The exception throwing mechanism always copies the thrown exception
object as a non-const object, in C++98/03 at least, so it shouldn't make
any difference to the things caught; and to specify 'const' means that
only const methods of the exception object can be called in the catch
block (I realise that what() is a const method).

Section 4.3 of TC++PL (3rd Edition) says: In addition, we can add
const to the type used to catch an exception in the same way that we can
add it to a function parameter.  This doesn't change the set of
exceptions we can catch; it only restricts us from modifying the
exception caught.

Has this changed in C++11?  If so, what additional excptions will a
const type in the catch statement cover which a non-const type will
not, under the new standard?  (I have a copy of the draft standard so if
you can point me to the paragraph concerned that would be very helpful
- it is always nice to learn new things.)

Chris


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

Re: Handling utf8 data from SQLite

[Chris Vine]

On Mon, 12 Sep 2011 00:34:11 +0100
Chris Vine ch...@cvine.freeserve.co.uk wrote:
 Section 4.3 of TC++PL (3rd Edition) says ...

Correction, that's section 14.3.


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

Re: Handling utf8 data from SQLite

[Chris Vine]

On Mon, 12 Sep 2011 00:34:11 +0100
Chris Vine ch...@cvine.freeserve.co.uk wrote:
 Has this changed in C++11?  If so, what additional excptions will a
 const type in the catch statement cover which a non-const type will
 not, under the new standard?  (I have a copy of the draft standard so
 if you can point me to the paragraph concerned that would be very
 helpful
 - it is always nice to learn new things.)

If it helps, I see that §15.1 of the C++11 standard says:

A throw-expression initializes a temporary object, called the
exception object, the type of which is determined by removing any
top-level cv-qualifiers from the static type of the operand of throw
and adjusting the type from “array of T” or “function returning T” to
“pointer to T” or “pointer to function returning T”, respectively. The
temporary is an lvalue and is used to initialize the variable named in
the matching handler (15.3).

This seems to me to be identical in effect to C++98 - a temporary
copy with all cv qualifiers removed (ie non-const) is created, which
although a temporary is treated as an lvalue (normally temporaries are
rvalues) which will therefore bind to a non-const reference.  As it
happens, section 15.3 goes on to prohibit explicitly rvalue
references types in the catch specification, which is redundant as a
necessary corollary of the exception copy comprising a lvalue is that it
won't bind to rvalue references.

Chris



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

Re: more size questions

[Chris Vine]

On Fri, 09 Sep 2011 18:03:37 -0600
D. R. Evans doc.ev...@gmail.com wrote:
 Chris Vine said the following at 09/09/2011 06:33 AM :
 
  This assumes of course that the even simpler approach of putting a
  Gtk::Label into a Gtk::Fixed as the Gtk::Fixed's one and only child
  doesn't do what you want, so you need to customise it further.
 
 That would be perfect... except that override_background_color()
 doesn't work on Labels. So I have to have some other widget in
 addition to the Label. I have been using an EventBox and then adding
 the Label to the EventBox, because that's what I found by googling
 the question of how to set the background colour for a Label.
 
 So we have a Label inside an EventBox inside a Fixed... which all
 along has seemed like it should work -- after all, the documentation
 for Fixed explicitly says that:
 
 The Gtk::Fixed widget is a container which can place child widgets at
 fixed positions and with fixed sizes, given in pixels.
 
 But having a Label inside an EventBox inside the Fixed doesn't work:
 the Label changes size, and hence so does the EventBox.
 
 There are functions with suggestive names line set_vexpand(bool) and
 set_hexpand(bool) whose purpose is undocumented but sound like they
 could be used to fix the size of a widget. But they don't. I don't
 know what they do, but the widgets still change size even after these
 functions have been called.
 
 The solutions using Cairo might be possible; I'll have to look at it
 -- I don't know anything about Cairo. I do have the horrible feeling
 that I'm diving ever deeper into a mire simply to implement something
 that is trivial on 1980s-era PCs. It seems like colouring a rectangle
 and putting text in the coloured area shouldn't be that hard.

Drawing text with cairo is actually pretty easy, particularly if you
are not interested in internationalisation (and in particular with
right-to-left languages) so you are not going to use pango. In Gtk+3,
DrawingAreas have a 'draw' callback rather than an 'expose_event'
callback which even presents a cairo context for you to draw the text
on.  I realise it may not be so easy for you but it would take me about
10 minutes to implement a subclass of Gtk::DrawingArea which would draw
text in the way that you want.  All your new set_text method would do
is change the string (or whatever) holding the text the DrawingArea is
to display and then trigger a draw event by calling its queue_draw()
method.

However, I have been investigating the behaviour of Gtk::Fixed out of
interest, and what you want works as is with GTK+2.  With GTK+3 the
behaviour of GtkFixed (and so Gtk::Fixed) changed - in GTK+3 Fixed will
resize itself to meet the standard size allocations of all the widgets
put in the Fixed at the positions at which they have been placed in the
Fixed.  In GTK+2, Fixed will instead assume the size requested by
Gtk::Widget::set_size_request().

So the documentation is now wrong in saying The GtkFixed widget is a
container which can place child widgets at fixed positions and with
fixed sizes.  That is how it used to be in GTK+2, mostly (see below
about mostly). What it should say in GTK+3 is that The GtkFixed
widget is a container which can place child widgets at fixed positions.

The new behaviour isn't entirely wrong in concept, since even in GTK+2
widgets such as labels put in a Fixed were allowed to overlap rather
than being clipped, so the with fixed sizes was never entirely right.

So unless anyone on the list can think of an easy way of stopping
Gtk::Fixed resizing, I suppose you have three options: use GTK+2, use
another toolkit such as Qt or subclass Gtk::DrawingArea.

Chris


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

Re: more size questions

[Chris Vine]

On Sat, 10 Sep 2011 10:43:48 +0100
Chris Vine ch...@cvine.freeserve.co.uk wrote:
 So unless anyone on the list can think of an easy way of stopping
 Gtk::Fixed resizing, I suppose you have three options: use GTK+2, use
 another toolkit such as Qt or subclass Gtk::DrawingArea.

Ah, it has occurred to me that there is a fourth option.

This option depends on you not minding long text elipsizing (ending
itself with ... to show there is missing text).  Any real-life
application intended for other users is going to want to ellipsize to
indicate to users missing text, but yours may not be a real-life
application in that sense.

If you call set_ellipsize() on the label and then set its
size with set_size_request() it will behave as you want, but with
ellipsizing on long text.  As a development of this, you can set a tool
tip contained all the text which a user can hover over if she wants.

Chris


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

Re: Handling utf8 data from SQLite

[Chris Vine]

On Sat, 10 Sep 2011 10:11:47 +1000
Zettai Muri zettaim...@gmail.com wrote:
     sqlite3_finalize(stmt);
     sqlite3_close(db);
 
     std::cout  DB - Password:   password  std::endl;
     return password;
 
 The strangest part of this is that if I comment out:
 std::cout  DB - Password:   password  std::endl;
 
 Recompile it and run it.  All combinations of Japanese/English
 usernames to passwords can be searched for and returned (displayed on
 label) without producing the 'unhandled exception in signal handler'
 
 Does anyone know why just this line could cause this?

Why not catch the exception and print it out to find out?

Probably the conversion of utf-8 to the locale encoding done behind the
scenes by the overloaded operator() for Glib::ustring is throwing.
That in turn could be because the the input string is not in utf-8, or
because you have not called std::locale::global(std::locale()) to set
the locale.

More generally, unless you want to manipulate utf-8 in your strings by
using Glib::ustring's specific utf-8 reliant methods, you are better off
avoiding problems like this by using std::string.  More specifically,
if you do want to use utf-8 reliant methods but done want conversion to
occur with operator (), then do:

std::cout  DB - Password:   password.raw()  std::endl;

Chris


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

Re: Handling utf8 data from SQLite

[Chris Vine]

On Sun, 11 Sep 2011 00:16:46 +1000
Zettai Muri zettaim...@gmail.com wrote:
  Why not catch the exception and print it out to find out?
 
 To be honest I don't know how to do this but will try to see if I can
 work it out.

This is basic C++:

try {
  std::cout  DB - Password:   password  std::endl;
}
catch (Glib::Exception e) {
  std::cerr  e.what().raw()  std::endl;
}
catch (std::exception e) {
  std::cerr  e.what()  std::endl;
}

[snip]

 If I declare a string as Glib::ustring does this mean it is in utf8?
 Both username and password are declared as Glib::ustrings

If you are using a library provided by others which returns a string by
Glib::ustring, it is reasonable to assume the encoding is utf-8 (if it
isn't, file a bug with the library author). If you are providing
your own text to put in a Glib::ustring object, it is up to you to get
the encoding right. If you declare a string as Glib::ustring then you
must only put text in utf-8 encoding in it.  

Chris


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

Re: Handling utf8 data from SQLite

[Chris Vine]

On Sat, 10 Sep 2011 23:51:21 +0200
Milosz Derezynski internaler...@gmail.com wrote:
 Here we are, 2011, and Glib::ustring::operator is haunting us still.
 
 I'm a little bit tired and my advice may seem counterproductive, but
 just so you know, this is a very old issue, and in actuality is not
 related to the fact that you have to store UTF-8 strings only in
 Glib::ustring; it's a problem.

It is related to that.  If the stored text is not in UTF-8 then
operator() will throw, because the attempted conversion from UTF-8
to the locale encoding will fail.

I agree with your general sentiment, and Daniel Elstner has said a
number of times that in hindsight the conversion carried out by the
operator() overload for Glib::ustring was a mistake.  But it is a
mistake a coder generally only makes once and she soon gets used to
calling Glib::ustring::raw() when using ostreams.  It is pointless now
breaking API on this.

I find myself using Glib::ustring increasingly less often.  I find that
std::string in combination with the glibmm supplied UTF-8 iterator for
std::string (or my own slightly different version of it) does the job
well enough in most cases.

Chris


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

Re: Gtk::TextBuffer::signal_erase()

[Chris Vine]

On Fri, 09 Sep 2011 13:10:53 +1100
Mr.Cashe mrca...@gmail.com wrote:
 Thank you for link.
 With your modifications the output is follows:
 [mrcashe@home test]$ ./test
 on_c_insert(): pos = 14
 on_cxx_insert(): pos = 14
 on_c_erase(): start = 5, end = 5
 on_cxx_erase(): start = 5, end = 5
 Result = This a text
 
 In other words, both handlers runs after GtkTextBuffer builtin
 handler. The question is: how to install C++ handler BEFORE builtin
 handler? sigc++ does not providing smt. like
 sigc::signal::connect_before(). Am I right or not?

All GTK+ signals are executed through a glibmm SignalProxy object, and
the connect() method that glibmm/gtkmm present you with is a connect
method of the proxy, not of a sigc::signal object.  The connect method
of the SignalProxy takes a second bool 'after' argument, which by
default is true.  Pass a value of false to the 'after' argument of the
connect method if you don't want that.

Annoyingly, this is the obverse of GTK+ signals, which by default
execute the connected callback before the built in handler.

Chris


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

Re: more size questions

[Chris Vine]

On Thu, 08 Sep 2011 15:55:35 -0600
D. R. Evans doc.ev...@gmail.com wrote:
 My understanding (such as it is) after googling is that in order to
 control the foreground and background colours for a Label, one
 actually has to define both a Label and an EventBox of the same size
 (because the background of a Label is actually transparent).

Gtk::Widget::modify_fg() certainly works on labels in GTK+2 and
Gtk::Widget::override_color() in GTK+3.  Very probably
Gtk::Widget::modify_bg() and Gtk::Widget::override_background_color()
work as well (I don't know), although possibly the fact that labels do
not have their own GdkWindow object may affect setting a background.  If
that is the case, an event box will deal with it.

However, often using styles is a better way of doing it.

What have you actually tried doing, and what doesn't work for you?

You don't need to worry about the same size stuff on this particular
point.  If you add a label to an event box (which derives from Gtk::Bin
and therefore only takes one child) they will by definition be the same
size through the ordinary size request mechanisms. That is not to say
that your travails with getting a fixed label size in your other thread
are ill judged (for fixed size maybe the easiest thing is to write your
text to a cairo pattern with cairo or pango-cairo and paint that onto a
Gdk::Window from a Gtk::DrawingArea - see eg
http://zetcode.com/tutorials/cairographicstutorial/cairotext/ for an
example written in C). Most people however want all their text displayed
and the normal approach is to size it at construction time for the
longest known text it will display.  You can use pango-cairo then to
size it for you.  That only of course works if the text is determined
programatically rather than by user input.

Chris


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

Re: more size questions

[Chris Vine]

On Fri, 9 Sep 2011 13:19:28 +0100
Chris Vine ch...@cvine.freeserve.co.uk wrote:
[snip]
 for fixed size maybe the easiest
 thing is to write your text to a cairo pattern with cairo or
 pango-cairo and paint that onto a Gdk::Window from a Gtk::DrawingArea

This assumes of course that the even simpler approach of putting a
Gtk::Label into a Gtk::Fixed as the Gtk::Fixed's one and only child
doesn't do what you want, so you need to customise it further.

Chris


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

Re: Preventing a window going to front - moving a window

[Chris Vine]

On Tue, 6 Sep 2011 19:02:18 +0100
lecas malecas darkiii...@gmail.com wrote:
 I did a bit more testing, the move() function works well, I tried
 calling it with some numbers.
 
 The problem is really with the get_position(), which returns always 0
 (for x and y).
 
 I think I'm calling it right (the compiler doesn't complain at
 least :p).
 
 I have this on the function that gets called on the signal_hide():
 
 this-get_position (x_position, y_position);
 
 cout  ONHIDE x   x_position   y   y_position  endl;
 
 where x_position and y_position are integers of the class.

I am not completely sure I understand what you mean, but if you hide
it, by definition it has no position, so the result you are getting
seems correct.

Chris


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

Re: Preventing a window going to front - moving a window

[Chris Vine]

On Tue, 6 Sep 2011 22:48:33 +0100
lecas malecas darkiii...@gmail.com wrote:
 You're right, its because the window is hidden.
 
 I tried with a timeout() and it does work.
 
 It would be better with an event though, there's probably no way to
 get something to run before hiding a window, so I'm trying to update
 the variables when dragging occurs, I tried signal_drag_begin() and
 signal_drag_end() from Gtk::Widget but the event function isn't
 called.

Since hiding a window is done programatically, there is obviously a way
to take the window's position before hiding it.  It you are using the
default delete event handler, which hides the window, override it so
that it does what you want.

Chris


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

Re: Gio::DBus::Connection::emit_signal issue

[Chris Vine]

On Sun, 21 Aug 2011 22:46:57 +0300
Aurimas Černius auri...@gmail.com wrote:
 I have issues with Gio::DBus::Connection::emit_signal.
 When I call it this way:
 connection-emit_signal(OBJECT_PATH, INTERFACE_NAME, Click);
 
 It doesn't do anything, except priting to conlose
 (server:23353): GLib-GIO-CRITICAL **: g_dbus_connection_emit_signal:
 assertion `destination_bus_name == NULL || g_dbus_is_name
 (destination_bus_name)' failed
 
 
 If I replace the line with
 g_dbus_connection_emit_signal(connection-gobj(), NULL, OBJECT_PATH,
 INTERFACE_NAME, Click, NULL, NULL);
 
 everything work fine.
 
 Am I misunderstanding something, or is it a bug?

My guess is that you have found a bug in the wrapper, possibly arising
from the way the wrapper deals with a null (all stations) destination
argument. At a guess, maybe it is passing the C function a string of no
size rather than a NULL pointer in this case.  I am not sure there are
sufficient users to give the wrappers a decent testing, and this is a
particularly obscure part of the GDBus API.

If you can, look at the wrapper code for this function and see if that
is indeed the problem, and in either event file a bug.

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

Re: help on array of widgets

[Chris Vine]

On Thu, 28 Jul 2011 10:37:26 +0800 (SGT)
Mj Mendoza IV mjmend...@konsolscript.org wrote:
  Probably the original poster needs to explain what purpose he is
  trying to achieve in storing widgets in a vector. There is probably
  a fundamental design error present.
 
 Hi Chris,
 
 What I had in mind is like GIMP's Layer Dock where, a layer can be
 added, removed and rearranged. To keep my learning simple, I
 experimented with Buttons first. What I opted to do is a vector of
 Buttons, which failed obviously. So with Yann's suggestion, I'm
 currently using vector of Button pointers instead.
 
 Do you have any better design in mind?

I am afraid I don't know anything about GIMP's layer dock, nor what a
Layer is, nor whether it is cognate with a GTK+ widget.  It sounds as
if you want a widget stack.  Qt has one of those, but GTK+ doesn't as
far as I am aware.

With such ignorance about GIMP, all I can do is give you some pointers.
The main thing you need to realise, if you want to transfer GTK+
widgets between parents, is that only one parent can own a child widget
at a time.

Since you can only have one parent owning a child, placing widgets in a
C++ aggregate container is in most cases a waste of time (see below
about dormant widgets as an exception to this).

In terms of GTK+'s C interface, all you need to do to reparent a widget
is to (i) increment its reference count so removal from its parent
doesn't destroy it, (ii) remove it from its parent, (iii) add it to its
new parent, and (iv) decrement the reference count again so that the new
parent controls its lifetime.  There is a convenience function call
which will do this for you in one go (gtk_widget_reparent()).

Of course you can have a GTK+ widget which at any one time does not
have a parent, provided that it is in a dormant (hidden) condition,
simply by stopping after stage (ii) above.  It could make sense to keep
dormant widgets of this kind in a C++ container until they are reused.
Under this scheme, if that is what your program UI requires, you would
pop it from the C++ container/widget stack when you place it into a
new GTK+ container.

You can more or less map this approach into gtkmm.  In fact you can map
it directly with non-widgets such as tree models, which are held by
Glib::RefPtr.

The problem that arises relates to objects deriving from Gtk::Widget.
Gtk::Widget::reparent() exists, but that wouldn't help you with
obtaining and keeping dormant widgets.  The nearest approach to this
would be to create a gtkmm widget with the new expression, put it into
a gtkmm container with the manage flag set and then, when you need to
make it dormant, take it out of the container, unset the manage flag,
and store it in a C++ aggregate container ready for re-use.

However, I don't know of any way of unsetting the managed flag on
Gtk::Widgets. gtkmm widgets inherit a set_managed() method from
Gtk::Object, but not an unset_managed() flag.

Therefore, if you do want to store dormant widgets, one approach is to
take over lifetime management by hand.  That is, don't set the managed
flag at all, and keep track by hand of what gtkmm container if any
happens to own a widget at any one time.  You would be responsible for
deleting the widgets when no longer needed - for example, when last
removing a redundant widget from a container or when the container of a
redundant widget is destroyed.

Another possible approach is to store all widgets, dormant or
otherwise, in the C++ container and transfer widget lifetime
ownership to the C++ container by managing the gtkmm widget by
std::shared_ptr.  This would mean that any widget would be destroyed
as soon as the C++ container is destroyed. This would in turn have the
effect of removing the widget from its gtkmm container automatically
when the C++ container is destroyed, I think safely: you would need to
check what the effect is of calling the delete expression on a gtkmm
widget owned by gtkmm container - I think it should safely remove it
because invoking the widget's destructor will cause the destroy signal
to be emitted (by calling gtk_widget_destroy() on the contained C
object), so causing the GTK+ container's reference on the widget to be
released.

Chris


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

Re: help on array of widgets

[Chris Vine]

On Wed, 27 Jul 2011 13:30:48 +0200
Yann Leydier y...@leydier.info wrote:
 It is the exact opposite ! :o)
 
 std::vectorGtk::Button* buttons;
 buttons.push_back(Gtk::manage(new Gtk::Button(but)));
 vbox.pack_start(*buttons.back(), …
 
 Calling Gtk::manage(widget_pointer) will cause the widget to be freed 
 when its parent is destroyed.
 
 Glib::RefPtr is generally not to be used when the API does not force
 you to use it.

On the last point, more accurately Glib::RefPtr is not intended to be
used with objects whose contained C object derives from
GInitiallyUnowned, which in gtkmm terms means anything deriving from
Gtk::Widget. Gtk::Widgets are not managed by RefPtr but are instead
intended either to be constructed without the new expression (say, as a
member of another class) or, if constructed by the new expression, then
to be managed by their container via Gtk::manage.

Given their intended purpose, there is very rarely a good reason to put
a gtkmm widget in a standard C++ container (I was going to say that
there is no good reason but that may be going too far), and they cannot
be contained by value because they are not copy constructible or copy
assignable (for very good reason). If there were to be an exceptional
reason why they must be held in a vector, as you say it would be best
for them to be held by raw pointer, but in that case I would strongly
advise against calling Gtk::manage() on them as you suggest, as that
could leave the std::vector container holding a pointer to an invalid
object - its lifetime would be controlled by the gtkmm container in
which it happens to be contained, which would negate the (imagined)
purpose of putting it in a vector in the first place.  It is completely
pointless putting a managed object in an aggregate C++ container.

Probably the original poster needs to explain what purpose he is trying
to achieve in storing widgets in a vector. There is probably a
fundamental design error present.

Chris


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

Re: ustring::compose and win32

[Chris Vine]

On Fri, 20 May 2011 09:49:24 +0200
Bastien Durel bast...@durel.org wrote:

 Le jeudi 19 mai 2011 à 23:41 +0100, Chris Vine a écrit :
  On Thu, 19 May 2011 21:00:12 +0200
  Bastien Durel bast...@durel.org wrote:
   The question is now : how to make g_convert work?
  
  I guess you are looking at the code in
  ustring::FormatStream::to_string() in ustring.cc.
  
 You're right.
 
  On unix-like systems, whether g_convert() supports a WCHAR_T target
  depends on whether iconv() supports it.  glibc's iconv() does, and
  normally on unix-like systems this would be mapped to UTF-32. It
  looks as if whatever provides the equivalent conversion support for
  windows does not.
  
  Two or three years ago the definition of SIZEOF_WCHAR_T was omitted
  when configuring glibmm for windows, I think because it caused some
  build problems somewhere.  It looks as if the code in ustring.cc
  hasn't caught up with this.  I guess this shows how infrequently
  glibmm is used under windows.  I should file a bug at bugzilla.
  
  In meantime, since as far as I am aware in all windows systems
  sizeof(wchar_t) is in fact 2, you could patch the preprocessor
  conditional compilation statement so that it only tests G_OS_WIN32.
  
 As I prefer not to recompile gtkmm (windows is not my primary target,
 and I did not succeed to compile it simply running msvc on the .sln),
 I choose another hack :
 
 https://github.com/BastienDurel/NR-deckbuilder/commit/16457166a8ae92ce9828fc9b4d0f007f3ab893c6
 
 this will not solve already-compiled code, but is sufficient to use
 compose.
 
 Thanks for looking.

I should still file a bug at bugzilla.  It deserves a new bug report.
(The reason why I knew about this was that I obliquely mentioned this
bug to the maintainer in a completely different bug report about 2 years
ago, so I knew where to look; but it's not going to be fixed without
more attention being drawn to it.)

Things can move slowly but it is likely to be fixed in the end.

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