Re: [boost] [gui] Help with a little experiment.
----- Original Message ----
From: Mathias Gaunard <mathias.gaunard@ens-lyon.org> To: boost@lists.boost.org 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; } } The second is more verbose but it is much readable, clear, intuitive code for an average C++ programmer. My $0.02 Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/
On 21.06.2011 10:14, Artyom Beilis wrote:
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.
But that's a general issue of C++ DSELs, not something new to this library. It is all about the expectations - most C++ programmers don't expect code that isn't imperative to do anything. Once you get over that misconception, I find that well-designed DSELs are very easy to read. That said, the original snippet is not well-designed IMO. The one that uses [] to delineate the contents of a widget is far better. Sebastian
El 21/06/11 10:14, Artyom Beilis escribió:
----- Original Message ----
From: Mathias Gaunard<mathias.gaunard@ens-lyon.org> To: boost@lists.boost.org 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.
It too complex for me. It will simpler in the following way: <StackPanel> <StackPanel.Children> <!--<UIElementCollection>--> <Button Click="ButtonClick1">First Button</Button> <Button Click="ButtonClick1">Second Button</Button> <!--</UIElementCollection>--> </StackPanel.Children> </StackPanel> And then in your glue code handles the event. 2011/6/21 Germán Diago <germandiago@gmail.com>:
El 21/06/11 10:14, Artyom Beilis escribió:
----- Original Message ----
From: Mathias Gaunard<mathias.gaunard@ens-lyon.org> To: boost@lists.boost.org 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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Quiero ser el rayo de sol que cada día te despierta para hacerte respirar y vivir en me. "Favola -Moda".
On 21/06/2011 10:14, Artyom Beilis wrote:
If you want an easy and fast declare GUI there are many RAD tools like QtCreator
or Glade that do this job well.
That kind of thing is IMO more interesting: http://labs.qt.nokia.com/2009/05/13/qt-declarative-ui/
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.
The idea is to have a language dedicated to declaring a GUI and the various properties of the components (which may be dependent or not). Whether that language is parsed and interpreted or is embedded within C++ itself is not much of a difference.
participants (5)
-
Artyom Beilis -
Germán Diago -
Giorgio Zoppi -
Mathias Gaunard -
Sebastian Redl