Chum: new GTK+ example using gtkmm

[Neil Hodgson]

The previous GTK+ example Bait was minimal so I have made a more complex example called Chum.
https://github.com/nyamatongwe/chum

It is built using the gtkmm 3 C++ binding of GTK+ and will work with GTK+ 3.x.

I quite like the way gtkmm connects events to C++ member functions - the technique SciTE and Scintilla use with a static method to bounce events into a member function is ugly.

Does anyone have experience with gtkmm and did you like it?

Neil

[Matthew Brush]

Hi,

I think it's a good idea to have a C++ example as well as the normal C
one for GTK+.

If you wanted comments on the code itself:

- ScintillaWindow doesn't appear to need to be virtual, so you could
leave out `virtual ~ScintillaWindow() = default;` and it won't get a
vtable and all that jazz.
- ScintillaWindow constructor could use the initialization list to set
`editor` and `sci` instead of doing it in the body.
- I'm not super familiar with gtkmm ownership semantics, but it looks
like ScintillaWindow::editor is leaked, I think you need to use
Gtk::manage() or something to have the container delete it, or else
delete it in ScintillaWindow's destructor.
- It's handy for scintilla_send_message wrapper (Call) to provide =0
default arguments for wparam and lparam since often times they aren't
used. The member function Call in ChumPort could do the same or just
forward the arguments to ScintillaWindow::Call using variadic template
arguments/perfect forwarding.
- I think `virtual ~ChumPort() = default;` is redundant as it's already
virtual and the compiler will provide a default implementation (I could
be wrong, I'm no C++ expert to be sure).
- In ChumPort::on_action_file_open, you could use
Glib::file_get_contents() to read the file instead of the C stdio stuff.
- The number 932 seems magical.

Nothing major, just stuff I noticed while skimming the code.

It would be cool to update the bait example to be more feature-full too,
if I get bored I could have a crack at it if you want. It'd probably 100
lines longer or so.

Regards,
Matthew Brush

[Lex Trotman]

On 2 June 2017 at 08:56, Matthew Brush <matthe...@gmail.com> wrote:
> On 2017-05-31 03:31 PM, Neil Hodgson wrote:
>>
>> The previous GTK+ example Bait was minimal so I have made a more
>> complex example called Chum.
>> https://github.com/nyamatongwe/chum
>>
>> It is built using the gtkmm 3 C++ binding of GTK+ and will work with
>> GTK+ 3.x.
>>
>> I quite like the way gtkmm connects events to C++ member functions -
>> the technique SciTE and Scintilla use with a static method to bounce events
>> into a member function is ugly.
>>
>> Does anyone have experience with gtkmm and did you like it?

I havn't used gtkmm for a long time, but it worked fine for gtk2, and
the ability to derive widgets using normal C++ techniques without the
boilerplate was great.

Cheers
Lex

>>
>
> Hi,
>
> I think it's a good idea to have a C++ example as well as the normal C one
> for GTK+.
>
> If you wanted comments on the code itself:
>
> - ScintillaWindow doesn't appear to need to be virtual, so you could leave
> out `virtual ~ScintillaWindow() = default;` and it won't get a vtable and
> all that jazz.

If you never expect to derive from it then sure it can be non-virtual.

> - ScintillaWindow constructor could use the initialization list to set
> `editor` and `sci` instead of doing it in the body.

ScintillaWindow would have to be re-ordered so they initialised in the
right order.

> - I'm not super familiar with gtkmm ownership semantics, but it looks like
> ScintillaWindow::editor is leaked, I think you need to use Gtk::manage() or
> something to have the container delete it, or else delete it in
> ScintillaWindow's destructor.

gtkmm uses the "normal" GTK reference counting and should manage
ownership properly, it certainly always did for me.

> - It's handy for scintilla_send_message wrapper (Call) to provide =0 default
> arguments for wparam and lparam since often times they aren't used. The
> member function Call in ChumPort could do the same or just forward the
> arguments to ScintillaWindow::Call using variadic template arguments/perfect
> forwarding.
> - I think `virtual ~ChumPort() = default;` is redundant as it's already
> virtual and the compiler will provide a default implementation (I could be
> wrong, I'm no C++ expert to be sure).
> - In ChumPort::on_action_file_open, you could use Glib::file_get_contents()
> to read the file instead of the C stdio stuff.
> - The number 932 seems magical.
>
> Nothing major, just stuff I noticed while skimming the code.
>
> It would be cool to update the bait example to be more feature-full too, if
> I get bored I could have a crack at it if you want. It'd probably 100 lines
> longer or so.
>
> Regards,
> Matthew Brush
>
>

> --
> You received this message because you are subscribed to the Google Groups
> "scintilla-interest" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to scintilla-inter...@googlegroups.com.
> To post to this group, send email to scintilla...@googlegroups.com.
> Visit this group at https://groups.google.com/group/scintilla-interest.
> For more options, visit https://groups.google.com/d/optout.

[Neil Hodgson]

Matthew Brush:

> - ScintillaWindow doesn't appear to need to be virtual, so you could leave out `virtual ~ScintillaWindow() = default;` and it won't get a vtable and all that jazz.
> - ScintillaWindow constructor could use the initialization list to set `editor` and `sci` instead of doing it in the body.
> - I'm not super familiar with gtkmm ownership semantics, but it looks like ScintillaWindow::editor is leaked, I think you need to use Gtk::manage() or something to have the container delete it, or else delete it in ScintillaWindow's destructor.

I really wanted to make ScintillaWindow more of a part of the gtkmm type system - perhaps deriving it from Gtk::Widget but haven’t worked out how to do that yet.
Pushed an update that deletes editor. Possibly using a Glib::RefPtr instead of a bare pointer would also have worked.

> - It's handy for scintilla_send_message wrapper (Call) to provide =0 default arguments for wparam and lparam since often times they aren't used. The member function Call in ChumPort could do the same or just forward the arguments to ScintillaWindow::Call using variadic template arguments/perfect forwarding.

The definition of ChumPort::Call does =0; perhaps you were looking at the implementation.

> - I think `virtual ~ChumPort() = default;` is redundant as it's already virtual and the compiler will provide a default implementation (I could be wrong, I'm no C++ expert to be sure).

Its just an indicator that the default is fine and saves scanning the whole definition if you want to know about the destructor.

> - In ChumPort::on_action_file_open, you could use Glib::file_get_contents() to read the file instead of the C stdio stuff.

That is a nice simplification so committed.

> - The number 932 seems magical.

To me, a literal here is more specific than using a declared ‘shiftJIS’ constant since then there would be a question of which Shift-JIS variant. Added a comment.

> It would be cool to update the bait example to be more feature-full too, if I get bored I could have a crack at it if you want. It'd probably 100 lines longer or so.

Sounds like a good idea. I copied the features from the Haven Qt example program - it gets stuff added occasionally to help debug features like IME behaviour.

Lex Trotman:

> I havn't used gtkmm for a long time, but it worked fine for gtk2, and
> the ability to derive widgets using normal C++ techniques without the
> boilerplate was great.

I mostly like it but there are some problems.

Tried to make Chum work with both GTK+2 and 3 by building with gtkmm3 and 2.4 but the extra type safety of gtkmm actually makes it more difficult than using the bare GTK+ API. So it looks like using it for SciTE would be trouble since GTK+ 2.x support is still wanted.

Neil