[gui] Help with a little experiment.
Hello. I'm trying to implement a little experiment of what I see should be the future of c++ guis. For that I'm going to need a handful of proto and fusion, and I have some questions. Besides that, there have been many times that a GUI for boost has been discussed. As I have some questions and something to expose, I thought it would be a good idea to post this message in both boost users and boost developers. I don't have an entire proposal for this, but for now I'm experimenting how a GUI framework should look like in my opinion. My opinion is that it should be AS declarative as possible, so, taking as a backend the gtk framework, I came with a syntax like the following one: #define CONTROLLER_CLASS GuiController #include <Gui/Layout.h> #include <iostream> class GuiController { void onEntryChanged(Entry & entry) { auto text = entry.getText(); std::cout << text << std::endl; } void onButtonClick(Button & button) { std::cout << "Button was clicked" << std::endl; } }; 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); The properties are mapped to objects like title corresponding to the gtk properties. The << operator means insert into and the << End(WidgetName) means that no more widgets should be inserted inside that closed widget. The && operator means put widgets at the same level. Regarding signals, they're put inside operator[]. That gui definition would be used like this template <class UI, class Controller> ?? createGUI(UIDefinition & ui_def, Controller & controller); int main(int argc, char * argv[]) { GuiController controller; auto window = createGUI(gui_definition, controller); window.show_all(); window.run(); } The function createGUI would generate a GUI from the definition and it would bind SLOTS automagically. It's very little code making use of a DSEL. The problem is that I must learn a lot of proto to code this, but if it works, do you think it would be an improvement? It's all compiler-checkable and the code is very short. After this first step I could start thinking beyond gtk and separate the library in backend and frotend so that not just gtk+ is used. My question is: Can I make something like End(VBox) work with boost.proto? I mean if it's possible to close the expression for a VBox with end and insert the next widget to the same level that the HBox. Thanks for your time and feedback is welcome.
Germán Diago wrote:
Hello. I'm trying to implement a little experiment of what I see should be the future of c++ guis. For that I'm going to need a handful of proto and fusion, and I have some questions. Besides that, there have been many times that a GUI for boost has been discussed. As I have some questions and something to expose, I thought it would be a good idea to post this message in both boost users and boost developers.
I don't have an entire proposal for this, but for now I'm experimenting how a GUI framework should look like in my opinion.
My opinion is that it should be AS declarative as possible, so, taking as a backend the gtk framework, I came with a syntax like the following one:
#define CONTROLLER_CLASS GuiController #include <Gui/Layout.h> #include <iostream>
class GuiController { void onEntryChanged(Entry & entry) { auto text = entry.getText(); std::cout << text << std::endl; }
void onButtonClick(Button & button) { std::cout << "Button was clicked" << std::endl; } };
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);
The properties are mapped to objects like title corresponding to the gtk properties. The << operator means insert into and the << End(WidgetName) means that no more widgets should be inserted inside that closed widget. The && operator means put widgets at the same level. Regarding signals, they're put inside operator[]. That gui definition would be used like this
template <class UI, class Controller> ?? createGUI(UIDefinition & ui_def, Controller & controller);
int main(int argc, char * argv[]) { GuiController controller; auto window = createGUI(gui_definition, controller);
window.show_all(); window.run(); }
The function createGUI would generate a GUI from the definition and it would bind SLOTS automagically. It's very little code making use of a DSEL. The problem is that I must learn a lot of proto to code this, but if it works, do you think it would be an improvement? It's all compiler-checkable and the code is very short. After this first step I could start thinking beyond gtk and separate the library in backend and frotend so that not just gtk+ is used.
Hi, while reading your post I remembered XMLTalk : [1] http://tinyurl.com/6fv9oqf. XmlTalk is a Java FRAMEWORK FOR AUTOMATIC GUI RENDERING FROM XML SPECS based on the MVC. Apologies if this this could be considered old technology now but that inspired me long time ago. Note that I'm not used to make GUI. Even if you provide a DSEL for GUI definition you should provide another DSL (XML or something else) for people that are not familiar with C++. Maybe XmlTalk would inspire you also.
My question is:
Can I make something like End(VBox) work with boost.proto? I mean if it's possible to close the expression for a VBox with end and insert the next widget to the same level that the HBox.
Thanks for your time and feedback is welcome.
What about using [] as scope operator 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); Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/gui-Help-with-a-little-experiment-tp36076... Sent from the Boost - Dev mailing list archive at Nabble.com.
Can I make something like End(VBox) work with boost.proto? I mean if it's possible to close the expression for a VBox with end and insert the next widget to the same level that the HBox.
Should be. Now, here is a small PoC of DSEL for GUI I had in mind for quite a while. Everythign in there is proto-ifable. windows<dialog, some_tag_for_selecting_gui_backend> w; w = frame("Choose a File to Open") [ listbox<columns,no_icons>(pos_x,pos_y) [ on_select = ... , on_move = ... ] , button("&OK", on_click =&do_ok) | button("&Cancel", on_click =&do_cancel) ]; where the on_xxx are terminal where = awaits for any callable object. Using [ ] to construct nesting is easier than << I think.
----- Original Message ----
Should be. Now, here is a small PoC of DSEL for GUI I had in mind for quite a while. Everythign in there is proto-ifable.
windows<dialog, some_tag_for_selecting_gui_backend> w;
w = frame("Choose a File to Open") [ listbox<columns,no_icons>(pos_x,pos_y) [ on_select = ... , on_move = ... ] , button("&OK", on_click =&do_ok) | button("&Cancel", on_click =&do_cancel) ];
where the on_xxx are terminal where = awaits for any callable object.
Using [ ] to construct nesting is easier than << I think.
Please tell me how is this better, more readable, maintainable then this code: http://doc.qt.nokia.com/4.3/tutorial-t5.html But it rises many issues: 1. Where button is created and who owns it? 2. How do I connect signals afterward? 3. How would an average programmer would understand a error codes you would see? Making a GUI library is not about providing nice syntactic sugar for building layout. Syntactic sugar is the last thing that should interest your. For GUI you need a core... Once you get it running on Windows/Unix/Mac OS X have full Unicode support, that handles layouts provides nice sets of widgets. This is what you should work... This ^^^ would only the library less useful for average programmer who actually needs to write a real code for real application... Not in a fancy world of Proto... --------------------------------------------------- And to be honest, there are two very good libraries that already do it: Qt and GTKmm... Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/
On 18/06/11 09:55, Artyom Beilis wrote:
Please tell me how is this better, more readable, maintainable then this code:
No specific GUI API calls.
1. Where button is created and who owns it?
It is a lazy function buildign up the AST of describing the window dialog. There is nothign to own there. The window::operator= take care of the marshalling of data inside this.
2. How do I connect signals afterward?
I can't see why we cant have an iterator coming from window over its widget and said internal widget to have a way to do so.
3. How would an average programmer would understand a error codes you would see?
By writing this right so error at caugth at proper level. That's a long time we have tool for that (first being proto grammar validation). See Eric post on the subject on cppnext.com
Making a GUI library is not about providing nice syntactic sugar for building layout.
It is. There is aplenty core GUI stuff around. If anything, if Boost should have a GUI library it should be just this: thin, synatxically nice layer on top of a generic view of existing core GUI stuff.
This ^^^ would only the library less useful for average programmer who actually needs to write a real code for real application... Not in a fancy world of Proto...
Proto world is not fancy, it is rather real.
On 6/18/2011 10:24 AM, Joel falcou wrote:
Boost should have a GUI library
From a previous discussion on the matter, I would say that what is needed is not one GUI library but rather several that are specific to a certain area of creating the interface. For example: - A library for designing dialogs and forms - A library for specifying bindings between the interface and the application's data (or creating a view of it). - A library for 'themes' that provides support for making controls look like native controls (including custom ones) and creating custom looks. - A library of widgets. - A core library that provides a platform independent back end for creating widgets. After all, the best way for writing a widget may not be the best way to design a dialog. Also, ideally each library should be general enough that it can be made usable with other GUI libraries (e.g. it should be possible for a library for designing dialogs to be made to work with the GTK library).
Thank you all for your feedback. 2011/6/19 Gwenio <urulokiurae@gmail.com>:
On 6/18/2011 10:24 AM, Joel falcou wrote:
- A library for designing dialogs and forms - A library for specifying bindings between the interface and the application's data (or creating a view of it).
I think I will start by these two fundamental libraries on top of gtk. I want that the specification of the gui can directly be embedded in C++ at compile time and that signals and bindings can also be given at runtime by name. I'll start by the compile-time way of doing things and I'll see if I can extend it later for runtime. The layout generated with the DSEL will contain widgets with the exact same type that given in the interface. This is not desirable sometimes, so I'm planning to give a way to override it. Now I'm trying to design a little currency converter as a proof of concept. The goal is to be able to specify a layout with its bindings and its logic. I came up with a solution like this for the example (C++0x syntax all). It felt more natural to follow a MVVM model. For now this is just fiction because I want to figure out how to make a specification that meets the goals described, namely: 1 - Library for designing dialogs and forms. 2 - Library for data binding (compile-time). After that: 3 - To be able to bind data and signals at runtime by name (difficult in c++) 4 - To be able to make layout more flexible by specifying that where a Button was put, for example, could go any Widget. I've also changed the syntax for the layout based on feedback: #define VIEWMODEL_NAME ViewModel #include <gui/layout.hpp> #include <gui/bindings.hpp> //My Model class CurrencyConverter { public: float euros_, dollars_; }; //My View Model class ViewModel { CurrencyConverter & converter_; Binding<float> euros_ = converter_.euros_; Binding<float> dollars_ = converter_.dollars_; ViewModel(CurrencyConverter & converter) : converter_(converter) {} void convertCurrency(Button & button); }; //This is my View Class auto gui_def = Window(title="Currency converter")[ VBox[ HBox[Label(text="dollars") | Entry(changed=BINDING(dollars_)], HBox[Label(text="euros") | Entry(changed=BINDING(euros_)] ] HBox(expand=true)[ Button(align=Align::Right, clicked=SIGNAL(convertCurrency) ] ]; int main(int argc, char * argv[]) { CurrencyConverter converter; ViewModel viewmodel(converter); auto gui = instantiate(gui_def, viewmodel); gui.showAll(); gui.run(); return 0; } As always, feedback is welcome.
German wrote on Sunday, June 19, 2011 at 21:31:01:
- A library for designing dialogs and forms - A library for specifying bindings between the interface and the application's data (or creating a view of it).
I think I will start by these two fundamental libraries on top of gtk.
I want that the specification of the gui can directly be embedded in C++ at compile time and that signals and bindings can also be given at runtime by name.
perhaps my opinion is biased by qt framework influence but it's a very mature product with 15 years of development history so i think they know what they are doing i think it's a mistake to try to do everything at compile time let's say half of the time the gui elements are dynamic in runtime sense so the compile-time-magic code would be used only roughly in 50% of cases while the runtime api should be there anyway once you start speaking about model-view-controller and variations you should drop the static (i.e. compile time) thing because the model, for instance, may be changed not only from the "gui end" but from some other place (e.g. from a non-gui-message handler) and the view may or may not be notified of this change and everything is setup at runtime in non trivial case i can't imagine a compile time code that will manage all the combined cases which may appear so my point is that primarily you should provide the "runtime" api rather than try to make a compile time dsel or the like (which means, yes, inheritance, virtual functions etc.) sorry for lengthy message, i hope you got my point but let me add that for me a portable gui library should be that with "qt spirit" which is, in fact, qt itself -- Pavel P.S. if you notice a grammar mistake or weird phrasing in my message please point it out
On 6/20/2011 11:25 AM, pavel wrote:
perhaps my opinion is biased by qt framework influence but it's a very mature product with 15 years of development history so i think they know what they are doing
i think it's a mistake to try to do everything at compile time
let's say half of the time the gui elements are dynamic in runtime sense
so the compile-time-magic code would be used only roughly in 50% of cases while the runtime api should be there anyway On the other hand, if the compile time bindings are well done then it should be possible to tie them to facilities capable of changing dynamically at runtime allowing the library to provide the best of both.
2011/6/20 Gwenio <urulokiurae@gmail.com>:
On 6/20/2011 11:25 AM, pavel wrote:
perhaps my opinion is biased by qt framework influence but it's a very mature product with 15 years of development history so i think they know what they are doing
i think it's a mistake to try to do everything at compile time
let's say half of the time the gui elements are dynamic in runtime sense
so the compile-time-magic code would be used only roughly in 50% of cases while the runtime api should be there anyway
On the other hand, if the compile time bindings are well done then it should be possible to tie them to facilities capable of changing dynamically at runtime allowing the library to provide the best of both.
And that's what I think. I want to make possible to override compile-time behaviour, but let's start with simple things first. And I also thought of mapping the compile time to a spirit language, but that's very far from what I'm thinking now because first I want to see how it behaves an embedded language in C++.
On Jun 21, 2011 12:26 AM, "pavel" <paul.cpprules@gmail.com> wrote:
German wrote on Sunday, June 19, 2011 at 21:31:01:
- A library for designing dialogs and forms - A library for specifying bindings between the interface and the application's data (or creating a view of it).
I would also rank highly a library that has good internationalization support.
I think I will start by these two fundamental libraries on top of gtk.
Seems like a move in the right direction, but managing dependencies for different platform is going to be complicated, no? Sylvain
I want that the specification of the gui can directly be embedded in C++ at compile time
I'm not sure why you want that so much. I like the possibility of having GUI specification in a separate file in order to adapt my application's look to the need of the customer (optimize it for a particular screen size or use a particular type of font, etc) without the need to recompile it. I would not use something that set the GUI layout in stone once it has been compiled. My 2cents, Sylvain
On Jun 21, 2011 12:26 AM, "pavel"<paul.cpprules@gmail.com> wrote:
German wrote on Sunday, June 19, 2011 at 21:31:01:
- A library for designing dialogs and forms - A library for specifying bindings between the interface and the application's data (or creating a view of it). I would also rank highly a library that has good internationalization support. I don't have enough expertise to try that, sorry. It's better to get focused on what I
I think I will start by these two fundamental libraries on top of gtk. Seems like a move in the right direction, but managing dependencies for different platform is going to be complicated, no? Yes, but for now I'm focusing just in a proof of concept that works. I want that the specification of the gui can directly be embedded in C++ at compile time I'm not sure why you want that so much. I like the possibility of having GUI specification in a separate file in order to adapt my application's look to the need of the customer (optimize it for a particular screen size or use a particular type of font, etc) without the need to recompile it.
I would not use something that set the GUI layout in stone once it has been compiled. My 2cents, Sylvain I think it should be possible to serialize that UI. Anyway, it's just a starting point. My view is
El 21/06/11 04:55, Sylvain Bougerel escribió: think I could be able to achieve, which is a proof of concept on how it feels a library like this with minimal features for now. that this must be overridable. By overridable I mean that once you have this, you will be able to make it as polymorphic as you want. I haven't thought how I will do it yet, but that's a thing to think about after my first steps.
Making a GUI library is not about providing nice syntactic sugar for building layout.
It is. There is aplenty core GUI stuff around. If anything, if Boost should have a GUI library it should be just this: thin, synatxically nice layer on top of a generic view of existing core GUI stuff.
Why should I use that gui framework if I can use an original one? Why should I use boost.gui if I already know gtk and gtkmm?
El 21/06/11 11:02, Giorgio Zoppi escribió:
Making a GUI library is not about providing nice syntactic sugar for building layout. It is. There is aplenty core GUI stuff around. If anything, if Boost should have a GUI library it should be just this: thin, synatxically nice layer on top of a generic view of existing core GUI stuff. Why should I use that gui framework if I can use an original one? Why should I use boost.gui if I already know gtk and gtkmm.
I want my framework to be FAR easier to use and consequently more productive. Less error prone is also a goal. In gtk+ you can connect signals in any way without noticing. Gtkmm goes the other way around, losing all the flexibility given by runtime signal connection. I think both things are good: when you can type-check, type-check and when you want flexibility, defer to runtime but throw exceptions if something goes wrong. After having the DSEL and bindings, more flexibility will be added, but this requires more work. Something like DynamicAny in the POCO libraries would be useful for this goal. One can think even further (serialization of widgets, etc.) but that's still quite far away.
After having the DSEL and bindings, more flexibility will be added, but this requires more work. Something like DynamicAny in the POCO libraries would be useful for this goal. One can think even further (serialization of widgets, etc.) but that's still quite far away.
Ability to create/move widgets to another container (dialog, window) at runtime or ability to disconnect/reconnect signals at runtime is a must have. Generally speaking, the features specifications & the runtime API design is something that should come ages *before* considering using a DSEL way of expressing stuffs, no? Looks like you somewhat take the problem backward to me, because even if you agree on which DESL to take connecting this DESL to the runtime api will likely be problematic as everyone one this list will bikeshed about how the runtime api will look, what features the lib must have, etc... and by the time those specs & runtime API are written in stone the DESL will likely be meaningless :) My 0.02$ Philippe
2011/6/21 Germán Diago <germandiago@gmail.com>:
El 21/06/11 11:02, Giorgio Zoppi escribió:
Making a GUI library is not about providing nice syntactic sugar for building layout.
It is. There is aplenty core GUI stuff around. If anything, if Boost should have a GUI library it should be just this: thin, synatxically nice layer on top of a generic view of existing core GUI stuff.
Why should I use that gui framework if I can use an original one? Why should I use boost.gui if I already know gtk and gtkmm.
I want my framework to be FAR easier to use and consequently more productive.
I am so selective in asking you because I would like to have a more productive gui. A thing that a GUI developer want is easy prototyping. I want to + design the forms/botton quickly and bind the events in a sort of automatic way. + create custom gui components quickly from current components. It should make little sense to me having to code all the GUI in C++. We are in 2011, processors with CMP and parallel graphics processors, even in embedded world (Cortex A9). +i would aspect a language easy for non programmers gui (ie. qml, xml). This will move the focus from programmers to graphic designers doing a gui. This could be a straightforward step to give them more work and free smart programmers for hard stuff. -- Quiero ser el rayo de sol que cada día te despierta para hacerte respirar y vivir en me. "Favola -Moda".
El 21/06/11 14:03, Giorgio Zoppi escribió:
It should make little sense to me having to code all the GUI in C++. We are in 2011, processors with CMP and parallel graphics processors, even in embedded world (Cortex A9).
+i would aspect a language easy for non programmers gui (ie. qml, xml). This will move the focus from programmers to graphic designers doing a gui. This could be a straightforward step to give them more work and free smart programmers for hard stuff. The point for me is the same. I don't want to have a DSEL exclusively. I want to have a runtime language as well (resembling the DSEL probably).
If the DSEL is declarative, I don't see much difficulty for a non-programmer to learn it. And of course, I agree with all you say. My use case for embedding a GUI is that I can use a gui file in C++ as a resource without a precompilation step. But it's not a substitute for a C++ file. On top of the dsel you could make a gui designer easily, but if you want to generate that one at runtime, it should be possible as well. So the thing is to be able to do both things and use the more convenient for the use case. I think that having the gui embedded in c++ at compile time is bad as long as it's easy to use. Even you could make a designer use the "runtime" DSEL which would be identical to the compile-time api and later, when deploying, replace that with the embedded dsel. But as I said before, this proof of concept still requires a lot of thought.
2011/6/21 Germán Diago <germandiago@gmail.com>:
El 21/06/11 14:03, Giorgio Zoppi escribió:
It should make little sense to me having to code all the GUI in C++. We are in 2011, processors with CMP and parallel graphics processors, even in embedded world (Cortex A9).
+i would aspect a language easy for non programmers gui (ie. qml, xml). This will move the focus from programmers to graphic designers doing a gui. This could be a straightforward step to give them more work and free smart programmers for hard stuff.
The point for me is the same. I don't want to have a DSEL exclusively. I want to have a runtime language as well (resembling the DSEL probably).
If the DSEL is declarative, I don't see much difficulty for a non-programmer to learn it. And of course, I agree with all you say.
My use case for embedding a GUI is that I can use a gui file in C++ as a resource without a precompilation step. But it's not a substitute for a C++ file. On top of the dsel you could make a gui designer easily, but if you want to generate that one at runtime, it should be possible as well. So the thing is to be able to do both things and use the more convenient for the use case. I think that having the gui embedded in c++ at compile time is bad as long as it's easy to use. Even you could make a designer use the "runtime" DSEL which would be identical to the compile-time api and later, when deploying, replace that with the embedded dsel. But as I said before, this proof of concept still requires a lot of thought.
So something like VRML, and engine that interprets directives. Do i catch it? Giorgio.
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. For this reason, most Boost-related efforts for GUIs have not been to create a robust library with lots of features, but rather to provide a "better" way to make GUIs built on top of an existing widget engine. I believe the Adobe Adam&Eve project is the most popular approach for GUIs in the Boost community. The way to go may be to do a Eve-like C++ DSEL.
On 2011-06-20 11:09, Mathias Gaunard wrote:
Moreover, writing GUIs is very tedious and uninteresting. It would be nice if it were possible to automate more things.
You mean stuff like this? http://www.eecs.harvard.edu/~kgajos/research/supple/ Cheers, Rutger
On 20/06/2011 17:59, Rutger ter Borg wrote:
On 2011-06-20 11:09, Mathias Gaunard wrote:
Moreover, writing GUIs is very tedious and uninteresting. It would be nice if it were possible to automate more things.
You mean stuff like this?
No I didn't think of tailoring it to the user (other than with a stylesheet of some kind).
on Mon Jun 20 2011, Mathias Gaunard <mathias.gaunard-AT-ens-lyon.org> wrote:
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.
+1 -- Dave Abrahams BoostPro Computing http://www.boostpro.com
windows<dialog, some_tag_for_selecting_gui_backend> w;
w = frame("Choose a File to Open") [ listbox<columns,no_icons>(pos_x,pos_y) [ on_select = ... , on_move = ... ] , button("&OK", on_click =&do_ok) | button("&Cancel", on_click =&do_cancel) ];
Hi all, Yeah, I've thought of making a GUI-Framework using Proto too, however, there are a few problems that came to my mind. 1.) It needs a consistent Syntax. Grouping AND actions with [ ] is no good. 2.) It must be possible to generate some sort of MVC (or better MVP) layout, which can later be used to modify the layout and access data. 3.) Backends should be interchangeably easily, but not dynamically. So what I thought of was something like that: namespace gui = name_me::gtk::gui; gui::handle<bool> checked; gui::button but; gui::window wnd; gui::toggle check(&checked); wnd = window(title="just an example", resizeable=false) [ label("click me:") | check = checkbox() - but = button("Close") ]; but.clicked() = [&]() { std::cout << "window " << wnd.title() << " closed!\n"; std::cout << "The checkbox was " << checked << std::endl; wnd.hide(); }; | can be used to place widgets side by side (HBox), - places them in an vertical container (VBox). Grouping is done using [ ]. gui::xyz are controllers that can be used to change the gui and can be bound to specific values (like checked above). Every controller can be used as if it was the real widget and any change is transmitted immediately. If a controller is assigned to a new widget (following polymorphic rules, so a toogle_button can be assigned to a gui::button), the widget is replaced. The Widget-Properties can be set using the DESL and (name=xyz) or using the controllers accessor (ctr.name()). So far for my ideas, michi7x7
On Sat, Jun 18, 2011 at 7:05 AM, Germán Diago <germandiago@gmail.com> wrote: At Adobe we designed an Eve-like (see http://stlab.adobe.com/group__asl__overview.html) DSEL, that would make the Eve example: layout clipping_path { view dialog(name: "Clipping Path") { column(child_horizontal: align_fill) { popup(name: "Path:", bind: @path, items: [ { name: "None", value: empty }, { name: "Path 1", value: 1 }, { name: "Path 2", value: 2 } ]); edit_number(name: "Flatness:", digits: 9, bind: @flatness); } button(name: "OK", default: true, bind: @result); } } look something like this: View * MyClass::create_clipping_path { return dialog(name = "Clipping Path") [ column(child_horizontal = align_fill) [ popup(name = "Path:", bindto = &m_path, items = _ [ _(name = "None", value = nullptr), _(name = "Path 1", value = 1), _(name = "Path 2", value = 2) ], edit_number(name = "Flatness:", digits = 9, bindto = &m_flatness) ], button(name = "OK", def = true, bindto = &m_result) ]; } And your example:
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);
I think would be: View *MyClass::hello_world() { return Window(title="Hello, world!") [ VBox(expand=true) [ HBox(expand=true) [ Label(text="Name:"), Entry(onChange = onEntryChanged) ], Button(text="hello", onClick = onButtonClick) ] ]; } Note that the syntax closely modeled XML, but without the verbosity. ie it has unique, unordered, attributes (inside the brackets) and non-unique, ordered elements, [inside the square brackets]. It also, given a "mapping struct", figured out which attributes could be passed to a widget constructor, and which needed to be set separately. ie for Button, if its constructor took a std::string, but not an "onClick" function, the Button would be constructed via, essentially: button = new Button("hello"); button->set(onClick, onButtonClick); Tony
I missed a bracket: On Sat, Jun 18, 2011 at 10:39 PM, Gottlob Frege <gottlobfrege@gmail.com> wrote: ...
popup(name = "Path:", bindto = &m_path, items = _ [ _(name = "None", value = nullptr), _(name = "Path 1", value = 1), _(name = "Path 2", value = 2) ]), ...
ie a ) to close the end of popup(...) Tony
2011/6/19 Gottlob Frege <gottlobfrege@gmail.com>
On Sat, Jun 18, 2011 at 7:05 AM, Germán Diago <germandiago@gmail.com> wrote:
At Adobe we designed an Eve-like (see http://stlab.adobe.com/group__asl__overview.html) DSEL, that would make the Eve example:
Hi Gottlob, is such DSEL library available to the public? Or is it purely imaginary? IIUC, Eve is a DSL, but not embedded in C++.
On Sun, Jun 19, 2011 at 1:33 AM, TONGARI <tongari95@gmail.com> wrote:
2011/6/19 Gottlob Frege <gottlobfrege@gmail.com>
On Sat, Jun 18, 2011 at 7:05 AM, Germán Diago <germandiago@gmail.com> wrote:
At Adobe we designed an Eve-like (see http://stlab.adobe.com/group__asl__overview.html) DSEL, that would make the Eve example:
Hi Gottlob, is such DSEL library available to the public? Or is it purely imaginary?
It is not imaginary, but it is not public. Maybe someone could convince Sean Parent to put it into ASL. I was written before Proto. I would probably be a bit easier to write it on top of Proto (and some of the introspection libraries would help as well).
IIUC, Eve is a DSL, but not embedded in C++.
Correct. We just tried to make our DSEL be as close to Eve as possible (since both projects were written at Adobe). Tony
2011/6/18 Germán Diago <germandiago@gmail.com>:
Hello. I'm trying to implement a little experiment of what I see should be the future of c++ guis. For that I'm going to need a handful of proto and fusion, and I have some questions. Besides that, there have been many times that a GUI for boost has been discussed. As I have some questions and something to expose, I thought it would be a good idea to post this message in both boost users and boost developers.
I don't have an entire proposal for this, but for now I'm experimenting how a GUI framework should look like in my opinion.
My opinion is that it should be AS declarative as possible, so, taking as a backend the gtk framework, I came with a syntax like the following one:
#define CONTROLLER_CLASS GuiController #include <Gui/Layout.h> #include <iostream>
class GuiController { void onEntryChanged(Entry & entry) { auto text = entry.getText(); std::cout << text << std::endl; }
void onButtonClick(Button & button) { std::cout << "Button was clicked" << std::endl; } };
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);
The properties are mapped to objects like title corresponding to the gtk properties. The << operator means insert into and the << End(WidgetName) means that no more widgets should be inserted inside that closed widget. The && operator means put widgets at the same level. Regarding signals, they're put inside operator[]. That gui definition would be used like this
template <class UI, class Controller> ?? createGUI(UIDefinition & ui_def, Controller & controller);
int main(int argc, char * argv[]) { GuiController controller; auto window = createGUI(gui_definition, controller);
window.show_all(); window.run(); }
The function createGUI would generate a GUI from the definition and it would bind SLOTS automagically. It's very little code making use of a DSEL. The problem is that I must learn a lot of proto to code this, but if it works, do you think it would be an improvement? It's all compiler-checkable and the code is very short.
Ok. I would prefer a XAML mapping.It has been used with success in the .NET world and it is standard. It seems that you are reiventing gtkmm:).
Ok. I would prefer a XAML mapping.It has been used with success in the .NET world and it is standard. It seems that you are reiventing gtkmm:). Gtkmm is the API which I'm not satisfied with as a linux user mainly. Connections are compile-time and a little to verbose for signal connections. Besides that,
there's no option to resolve signal connections at runtime.
participants (15)
-
Artyom Beilis -
Dave Abrahams -
Germán Diago -
Giorgio Zoppi -
Gottlob Frege -
Gwenio -
Joel falcou -
Mathias Gaunard -
michi7x7 -
pavel -
Philippe Vaucher -
Rutger ter Borg -
Sylvain Bougerel -
TONGARI -
Vicente Botet