Changing the subject... :-[
On 25/11/15 13:21, aitor_czr wrote:
> 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
::
Re: [DNG] Experiencing with GtkBuil…
