Hi Roger, Rainer:

Here is the code of the spinner using Gtkmm3 instead of Gtk3+.
The .xml file generated by Glade is the same.


###### SPINNER #######

#include <gtkmm.h>
#include <iostream>

Gtk::Window* pWindow = 0;
Gtk::Button* pButton1 = 0;
Gtk::Button* pButton2 = 0;
Gtk::Button* pButton3 = 0;
Gtk::Button* pButton4 = 0;
Gtk::Spinner* pSpinner1 = 0;

static void on_button1_clicked();
static void on_button2_clicked();
static void on_button3_clicked();
static void on_button4_clicked();

int main (int argc, char **argv)
{
   Glib::RefPtr<Gtk::Application> app = Gtk::Application::create(argc, 
argv, "org.gtkmm.example");
   Glib::RefPtr<Gtk::Builder> refBuilder = 
Gtk::Builder::create_from_file("spinner.ui");
   refBuilder->get_widget("window",  pWindow);
   if(pWindow)
   {
     refBuilder->get_widget("button1",  pButton1);
     refBuilder->get_widget("button2",  pButton2);
     refBuilder->get_widget("button3",  pButton3);
     refBuilder->get_widget("button4",  pButton4);
     refBuilder->get_widget("spinner1", pSpinner1);

     if(pButton1) 
pButton1->signal_clicked().connect(sigc::ptr_fun(on_button1_clicked));
     if(pButton2) 
pButton2->signal_clicked().connect(sigc::ptr_fun(on_button2_clicked));
     if(pButton3) 
pButton3->signal_clicked().connect(sigc::ptr_fun(on_button3_clicked));
     if(pButton4) 
pButton4->signal_clicked().connect(sigc::ptr_fun(on_button4_clicked));
   }

app->run(*pWindow);
delete pWindow;
return 0;
}

static void on_button1_clicked ()
{
pSpinner1->show();
}

static void on_button2_clicked ()
{
pSpinner1->hide();
}

static void on_button3_clicked ()
{
pSpinner1->start();
}

static void on_button4_clicked ()
{
pSpinner1->stop();
}

###### END #########

In my case, Rainer, the spinner works only into a chroot jail (i tried
it in a couple of computers).
It's very strange... And it's appearance is also different !!

... "The misterious affaire of the spinner" ...

To be continued :)

    Aitor.

On 24/11/15 13:00, Roger Leigh <rleigh@???> wrote:
> On 23/11/2015 20:43, Rainer Weikusat wrote:
>> >Roger Leigh<rleigh@???> writes:
>>> >>On 23/11/2015 13:50, Rainer Weikusat wrote:
>>>> >>>Roger Leigh<rleigh@???> writes:
>>>>> >>>>On 23/11/2015 11:49, Nate Bargmann wrote:
>>>>>> >>>>>* On 2015 23 Nov 00:53 -0600, aitor_czr wrote:
>>>>>>> >>>>>>In my opinion, using C with lists will be the most suitable.
>>>>>> >>>>>
>>>>>> >>>>>Have you looked at what glib provides? It is an underlying library of
>>>>>> >>>>>GTK and seems to contain many such solutions.
>>>>> >>>>
>>>>> >>>>Using GLib for structures like linked lists (GList) etc. is a much
>>>>> >>>>better solution than reinventing them unnecessarily.
>>>> >>>
>>>> >>>I beg to differ here: Using a lot of complicated code in order to
>>>> >>>accomplish something simple, ie, management of linked lists, may be
>>>> >>>regarded as advantageous, eg, because it enables avoiding a (typically
>>>> >>>negligible) amount of work or because it's more politically feasible but
>>>> >>>$code doesn't become a 'better' solution for some $problem just because
>>>> >>>it can be downloaded for free from the internet.
>>> >>
>>> >>This is true up to a point. Note the "unnecessarily" qualifier in
>>> >>what I wrote--sometimes there might be a justification for reinventing
>>> >>the wheel,
>> >
>> >"The wheel" (leaving the issue that wheels are being 're-invented', ie,
>> >new kinds of wheels are being developed all the time, aside) is a
>> >technical device which has been in use without changes to the basic
>> >design for a couple of thousands of years. In contrast to this, most
>> >other human inventions, say, steam-powered locomotives, delay line
>> >memory or CP/M, are very short-lived. This make it a particulary
>> >unsuitable analogy here.
> OK, "unnecessary reimplementation" then. Reimplementing basic stuff is
> wasteful on many levels.
>
>>> >>1) Use GLib
>>> >>2) Use a linked list implementation from another library
>>> >>3) Write your own
>>> >>4) Use C++
>>> >>5) Use another language
>>> >>
>>> >>As you say (1) isn't necessarily ideal, and this also potentially
>>> >>applies to (2) depending upon its quality of implementation and how
>>> >>well it matches your needs. Where I would disagree is that (3) has a
>>> >>"typically negligable" cost. A linked list is conceptually simple,
>>> >>and yes, not that much effort to write.
>> >
>> >One thing I always liked about Jeff Bonwick's 'Slab Allocator' paper was
>> >that he apparently didn't even think about implementing a generalized
>> >library for handling doubly-linked list instead --- he just wrote the
>> >code manipulating the link pointers as needed.
> Well, inside the guts of an allocator is exactly where direct pointer
> usage is required for the needed performance and flexibility. But for a
> list in a frontend GUI, not so much. It would be a waste of valuable
> time and effort when there are easier and simpler alternatives. The
> goal is to write a GUI, not mess around with list implementation details.
>
>>> >>If you take approach (4), and use a standard container type, the
>>> >>problem is solved immediately. "#include <list>", "std::list<mytype>
>>> >>mylist". Job done.
>> >
>> >One of the reasons why I stopped using C++ around 2001/2 (A lesser
>> >reason. The more important one was that it was neither a requirement nor
>> >particularly helpful) was that I always regarded it as very nice
>> >language with the millstone of an atrociously implemented standard
>> >library around its neck while I came to realize that a certain Mr
>> >Stroustroup seemed to regard is a rather atrocious language he could
>> >only sell because of the wonderful library requiring it.
> So this is pre-Standard C++ given the timeframe? It was particularly
> bad around this time, and it took several releases of GCC3.x before the
> bugs in libstdc++ were shaken out (so ~2004-5 when it became widely
> available). Not that the C++98 standard library is without its warts,
> but it's perfectly functional. With C++11, the library became properly
> usable--direct initialisation of containers makes it vastly better.
>
> If you came to me with a problem, and that required maps, lists etc. to
> solve, I would nowadays automatically discount C. I'd look and C++ or
> Python first. I'd have an implementation done and tested well before
> I'd even got started on it in C--where I'd be obliged to create all the
> low-level pieces before I even got started on the problem itself.
> There's no advantage to using C in a situation like this--other than for
> masochistic bragging rights--it doesn't do a better job, and it takes
> longer, requires more effort and will be more likely to contain bugs.
>
> std::vector<std::string> list{"foo", "bar", "baz"};
>
> Just works. How much low-level C would be required to implement that?
> Lots. Would it be worth the cost? Almost certainly not.
>
>
> Regards,
> Roger