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
On 15/04/2021 01:24, Oliver Niebuhr wrote:
I do not know if this is the Solution but I added 'sys.executable' and
the Error Message went away:
result = subprocess.run([sys.executable, 'aclocal', '--print-ac-dir'],
stdout=subprocess.PIPE,
stderr=subprocess.DEVNULL,
On 14/04/2021 09:41, Kjell Ahlstedt via gtkmm-list wrote:
The installation of mm-common fails on line 17 of
extra-install-cmd.py. I don't understand what the error message refers
to ("the file specified"). extra-install-cmd.py is a very simple
Python script that just prints a warning, if
On 31/08/2019 16:03, Karsten Pedersen wrote:
The biggest issue is that often many of them wouldn't experience any
catastrophic problems at all. They wouldn't even know anything was
wrong with their code. It is only when I would mark it and send their
binary through Valgrind it would light up
On 31/08/2019 12:56, Karsten Pedersen wrote:
I have yet to see it in any gtkmm code (you will be pleased to hear)
but my personal opinion is that it is surely a nice idea to attempt
to make C++ 100% safe rather than having to rely purely on the skills of
a developer.
That's a nice sentiment but
On 06/08/2019 14:50, Phil Wolff via gtkmm-list wrote:
I'm deriving from Gtk::ProgressBar in order to track mouse events
within the widget. The only callback that executes is on_map(). Can
anyone tell me what vital (and likely obvious) operation I've failed
to include?
I don't know if this
Hello again gurus,
In my GTKmm 2.24 application, there are some SpinButtons used to control
the system in various ways. One of our customers complained that the
up/down steps of one of them were too coarse, which is fair enough as
that one drives a fairly sensitive piece of equipment that can
On 08/06/2019 12:44, Daniel Boles via gtkmm-list wrote:
> There may be a better fix. It would be nice if calling clear() on the
> model didn't invoke the signal_changed of BOTH comboboxes 328 times each
Blocking the signal is another way to do it. That may or may not have
any quantitative
On 07/06/2019 21:11, Rob Pearce wrote:
And when it does so, the iterator returned by get_active() is invalid,
which my code doesn't test for in the secondary case, so that would be
worth doing... hold on...
Yep, that seems to have fixed it.
There may be a better fix. It would be nice
On 07/06/2019 19:56, Daniel Boles via gtkmm-list wrote:
It's not particularly clear what's going on. Posting the minimal code
required to reproduce this on a pastebin and linking it would be great.
Yes, I know, but this is all well embedded into a large code base, so it
won't be easy. I'll
On 07/06/2019 13:26, Daniel Boles via gtkmm-list wrote:
>>>
/Now, using the TreeModel and passing
iterators, I get a shed load of
Gtk-CRITICAL **: 12:24:08.859: gtk_tree_store_get_path: assertion
'iter->user_data != NULL' failed
interspersed with my own debug report of invalid iters passed to
e Path to get an iterator, but if we are talking about the same
instance, the iterator should work.
On 06/06/2019 18:13, Rob Pearce wrote:
On 06/06/2019 09:18, Carlos Gomez wrote:
If both ComboBoxes has the same items, perhaps you should use
Gtk::TreeModel::Path.
They not only have t
On 06/06/2019 09:18, Carlos Gomez wrote:
If both ComboBoxes has the same items, perhaps you should use
Gtk::TreeModel::Path.
They not only have the same items, they share a TreeModel instance and a
TreeModel::Columns instance (I believe this is an officially approved
scheme). So yes, Path
Hello experts,
I have a GTKmm (2.24) application in which two different windows each
have a ComboBoxText controlling the same item, so that whenever the user
makes a selection on one of them, the other one needs to be updated
accordingly. This is implemented by calling the set_active with the
(Oops, sent from wrong address first time)
On 24/02/15 12:28, Glus Xof wrote:
I need your help...
I insist that maybe it's not an specifically Gtkmm question... but you
may know better how it's done, the library...
It's not even related to the library, really. The issue here is a basic
On Sunday 20 July 2008, Johannes Bauer wrote:
I'm writing an application which reads from a DMM (asynchronously, I'm
using pthreads - is that a bad idea?)
Using threads is not bad in itself, but you must keep all GTK interaction in
one thread. Basically, apart from a few Glib functions like
On Wednesday 09 July 2008, Petr Hracek wrote:
You mean that when I will develop GUIs I do not need DevC? Only MinGW (of
course with gtkmm and glade) is neccessary? Am I right?
That depends a little on your definition of necessary. However, when I
develop GUI applications for Linux I don't use
On Wednesday 09 July 2008, Damon Register wrote:
Though I am not certain, I wonder if
using MinGW might increase the risk of having code that would be Windows
specific while using Cygwin might lead you to code that is more unix
generic.
When I tried to port an app from Linux to Windows, I
On Monday 16 June 2008, Jamiil wrote:
I have combo boxes and entry boxes that I want to clear up when the user
clicks on the 'Clear' button. I looked into the Gtk::ComboBox widget,
but I am unable to find the right method.
Any body?
I've done something like this on ComboBoxText widgets using
On Thursday 08 May 2008, Hubert Figuiere wrote:
On Wed, 2008-05-07 at 22:09 -0400, Jamiil wrote:
const Glib::ustring jve::Person::getTitle(){
switch(title){
case Mr: {return Mr; }
case Mrs: {return Mrs; }
case Miss: {return Miss;}
case Ms: { return Ms;
On Tuesday 26 June 2007 00:54, Jonathon Jongsma wrote:
On 6/25/07, Robert Pearce [EMAIL PROTECTED] wrote:
snip
IS there a better way to reference members of a liststore, so that
reordering the treeview won't break the references?
Or, alternatively, how can I best hook something up to the
On Tuesday 26 June 2007 09:00, Murray Cumming wrote:
On Mon, 2007-06-25 at 22:45 +0100, Robert Pearce wrote:
[snip]
However, a RefPtr will be
_cast_ to a C++ pointer automatically and invisibly,
[snip]
No, that's not true. And you should never need to use the raw pointer.
Fair enough.
22 matches
Mail list logo
