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 <[email protected]> wrote:
On 23/11/2015 20:43, Rainer Weikusat wrote:
>Roger Leigh<[email protected]> writes:
>>On 23/11/2015 13:50, Rainer Weikusat wrote:
>>>Roger Leigh<[email protected]> 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
_______________________________________________
Dng mailing list
[email protected]
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
