Subject: Re: [boost] [gui] Help with a little experiment.
From: Germán Diago (germandiago_at_[hidden])
Date: 2011-06-21 04:39:11
El 21/06/11 10:14, Artyom Beilis escribió:
>
> ----- Original Message ----
>> From: Mathias Gaunard<mathias.gaunard_at_[hidden]>
>> To: boost_at_[hidden]
>> Sent: Mon, June 20, 2011 12:09:50 PM
>> Subject: Re: [boost] [gui] Help with a little experiment.
>>
>> On 18/06/2011 16:55, Artyom Beilis wrote:
>>
>>> Making a GUI library is not about providing
>>> nice syntactic sugar for building layout.
>>>
>>> Syntactic sugar is the last thing that should interest you.
>> Having a short and concise declarative definition of your GUI has several
>> advantages.
>> It's easier to validate it, it allows to avoid bugs, and you can really
>> materialize
>> the intent of what you want instead of coding its logic directly.
>>
>> Moreover, writing GUIs is very tedious and uninteresting. It would be nice
>> if it were possible to automate more things.
> Few points.
>
> If you want an easy and fast declare GUI there are many RAD tools like QtCreator
>
> or
> Glade that do this job well.
>
> On the other hand. When I was programming some GUI tools the **easiest** part
> was to write a code that makes the layout and connects widgets...
>
> The hard part was to write the actions that should be done behind the widgets.
>
> Today when I write production code I think about users who are going to maintain
> it. And readability and clearness is very big concern.
>
> See:
>
> http://developer.qt.nokia.com/wiki/API_Design_Principles
>
> There are 6 primary points:
>
> * Be minimal
> * Be complete
> * Have clear and simple semantics
> * Be intuitive
> * Be easy to memorize
> * Lead to readable code
>
> Especially this one:
>
> An API is intuitive if a semi-experienced user
> gets away without reading the documentation,
> and if a programmer who doesn’t know the API
> can understand code written using it.
>
>
> IMHO The proposed API does not helps with all this
> and makes things very obscure for a programmer that is
> not fully familiar with the toolkit.
>
> If I show this code to average C++ programmer the
> vast majority of them would not know what happens there...
>
> The fact that you and 1 percentile
> of C++ programmers (that write Boost Libraries)
> understand the proposed code
> does not mean it is understandable to other.
>
> Consider:
>
> This
>
>> auto gui_definition =
>> Window(title="Hello, world!")<<
>> VBox(expand=true)<<
>> HBox(expand=true)<<
>> Label(text="Name:")&& Entry[SLOT(onEntryChanged)])
>> << End(HBox);
>> << Button(text="hello")[SLOT(onButtonClick)];
>> << End(VBox)
>> << End(Window);
> Or this?
>
> class MyWindow : public Window {
>
> MyWindow {
> setTitle(tr("Hello, World!"));
>
> base_layout = new VBoxLayout();
> setLayout(base_layout);
> base_layout->sizePolicy(Expand);
>
> top_layout = new HBoxLayout();
> base_layout->addItem(top_layout);
>
> top_layout->sizePolicy(Expand);
>
> top_layout->addWdiget(new Label(tr("Name:")));
>
> text = new TextEdit();
> top_layour->addWidget(text);
>
> button = new PushBotton(tr("Hello"));
> layout->addWidget(button);
>
> connect(text,SIGNAL(valueChanged()),this,SLOT(onEntryChanged());
> connect(button,SIGNAL(pressed()),this,SLOT(onButtonClick());
> }
>
> void onEntryChanged()
> {
> std::cout<<text->getText()<< std::endl;
> }
>
> void onButtonClick()
> {
> std::cout<< "Button Pressed"<< std::endl;
> }
>
> }
I'm trying to make my code readable as well. I changed my initial
proposal a little,
but I think that you didn't realize it. Look at it.
And it's easy to follow once you understand the mini-language:
auto gui_def =
Window(title="Hello,world")[
VBox(expand=true)[
HBox[Label(text="Dollars:") |
Entry(changed=BINDING(dollars))],
HBox[Label(text="Euros:") |
Entry(changed=BINDING(euros))]
]
];
I think that it's easy to follow. You just have to read once what
operators do (| to separate in boxes).
It's readable, very readable indeed. And it makes a lot of work in very
few lines of code == less bugs.
Of course I must think a lot about many problems I will find along the
way before making a proposal,
but being declarative and making code as short as possible while keeping
readability are
two choices I think are right. The average programmer just would have to
learn a mini-language which, compared to the alternative (learning an
imperative API) is much better.
Of course, I must think a lot about bindings, signals, slots and all
that stuff, but my starting point is a
DSEL and after that I'll try some sort of runtime equivalent to make
possible dynamic polymorphism.