[boost] Re: GUI sublanguage ?
[EMAIL PROTECTED] wrote: [...] After having followed this thread I wander if we are trying to reinvent the wheel. By googling a bit one can find plenty of Gui Toolkits and here I saw little of them. Not a word on Qt, for example. I never used it for an important project but they give a (good ?) solution for example to the layout issues discussed so far. If I should criticize them (as a lazy user who is in troble finding his way among all those features) if the fact that there are huge classes that probably need further decomposition of resposibilities. Anyway Qt make life simple for simple apps and provides something that scales quite well for larger projects (I haven't used it but I can use KDE as witness). So I would like to have a clearer idea of the difference between the goal of this thread and existing solutions (i.e. Qt). At some degree it becomes political issues. I doubt Boost would want to take the same risky path I took (Corel). Philippe ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: GUI sublanguage ?
Philippe A. Bouchard [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Bohdan wrote: [...] There are a lot of good reasons why we would not always want to have total control. Not always means sometimes not ? According to this logic your gui language is layer built on top of interface proposed by me ... just for convenience. Right ? I looks like a competition between the two of you... No. My apologises, if my posting were too offensive for somebody. Unfortunately my english is far from being perfect. Everything i want is to clarify the idea of incoming modern gui library and particularly 'gui sublanguage'. I'm very interested in this library and this is the only source of emotions. No wars, only questions, doubts and ideas. I want my applications to be as simple as possible, and to all look the same. Generally GUI applications are semantically complicated. Forget about universal cure from this. Everithing you can do is to symplify development in some cases. It doesn't make sense to start positionning every widget manually like this. What if you find you're interface ugly (p = 0.90) the first time and you have found a better idea? You are going to retype the position of every widgets in the whole application?!? No. Look at Borland VCL lib. It handles autosizing/alignment without significant problems. Anyway, i agree there a lot of interesting ideas for improvements in this field. If you are planning to do this, I suggest to use another GUI application which will generate the spaghetti part of you're code. Another GUI application may require much more complicated behavior than gui-sublanguage can propose. regards, bohdan ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: GUI sublanguage ?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bohdan Sent: Wednesday, August 06, 2003 5:46 PM To: [EMAIL PROTECTED] Subject: [boost] Re: GUI sublanguage ? [...] There are a lot of good reasons why we would not always want to have total control. Not always means sometimes not ? According to this logic your gui language is layer built on top of interface proposed by me ... just for convenience. Right ? Yes, but I wouldn't underestimate the value of 'convenience' in the form of simpler code. [...] Have you invented universal algorithm for window size/position ? It works surprisingly well. I know I described it in detail in an earlier post, I can sum it up again if you like. It works well especially if you need complete resizability. Anyway, it would be easy to write your own algorithm. The point is that every programmer shouldn't have to implement one for every window. [...] A real world application needs much more sophisticated positioning mechanisms than this. The tiny snippet above (in my code) hides some pretty good positioning logic. Don't be boring, this is just simple example ... without details in mind. sophisticated positioning mechanism can be implemented by control/window class methods too. Even more, such interface allows changing behavior in runtime. Sorry if I didn't state that well. My point is just that part of the purpose of the sub-language would be to make it much simpler to specify positions. Again, these values should be picked automatically. Only if you are satisfied by default values. Believe me, this is very rare situation. Especially for progress bar control :)) But there has to be some sort of logic in what values you pick. Is the step size related to the number of ticks? You could codify your logic as the default behaviour in your applications. Now, it might be cool to be able to change my above code to: gui::showmy_company_gui_traits( sample boost application, ... Generally runtime gui styles (flat, 3d ...) can be more helpful, because changing look-and-feel in application options is very frequent situation for serious GUI applications. Please don't be too obsessed by compile time, it is not very good way for GUI toolkit. I agree that we need to be able to change look and feel at run time. It might be easier to do compile time only in the earlier phases of our design. [...] - GUI code is difficult, tedious, and error prone even for simple tasks, I want to make it simple (for simple tasks) Agree! But only for simple tasks. Right now it can be complicated to develop large GUIs even if the actual logic is pretty simple. Furthermore, it might be possible to simplify complicated tasks that are common (like positioning). Now things are clear. My conclusion is following : 1. Such interface is ok for no-so-compicated gui and/or controls. I mean situations when you are satisfied by default values for properties or properties differ from default ones not so much. Yes. You couldn't write MS Excel with it, but you could write a pretty large number of business applications. The programmer will be able to specify most of the default behaviour, the usefulness will be determined by how frequently he needs behaviour that differs from his own defaults. 2. It should be implemented on to of more functional, runtime, interface ( used in most gui libs). - control positioning is especially difficult If you mean MFC or pure win32, most probably it is true. But don't forget there are a lot of other GUI libs around which can handle this problem without significant problems. Maybe so. The only other systems I've seen are VB, BCB and Java, each of which have built in positioning mechanisms that are better than MFC's on the surface, but which still fail (as in need much manual coding) for real world applications - especially when the windows may be sized dynamically. - Consistency in GUI applications is difficult. Give ten programmers a lower level GUI API and they'll turn out ten applications each with a different look and feel. I don't want to have to remember that step size for our company is always '5', for instance. Interface proposed by me can and should have default values as well. That is where I was headed with the traits mechanism. If we head in the direction we've been talking we would also provide a cross platform lower level API where you could get more control and do things like what you describe below. I hope that most programmers would find it unnecessary though. IMHO this interface is must. I think it will also be important that elements of this low-level interface integrate seamlessly with the upper level on - you can use the higher level abstracts but do some things manually. Brock
[boost] Re: GUI sublanguage ?
Brock Peabody [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Because for a pretty large number of applications you can really
simplify your code a lot by relying on the GUI system to 'do the right
thing':
using boost::gui;
void my_action() {...}
void progress_action(int tick) {...}
gui::show( sample boost application,
column ( button (click it, my_action),
progress (100, progress_action)));
There are a lot of good reasons why we would not always want to have
total control.
Not always means sometimes not ?
According to this logic your gui language is
layer built on top of interface proposed by me
... just for convenience. Right ?
I want my applications to be as simple as possible, and
to all look the same.
Generally GUI applications are semantically complicated.
Forget about universal cure from this. Everithing you can
do is to symplify development in some cases.
If the GUI library picks the 'best' settings for
the platform automatically, the individual programmer doesn't have to
think about it. Everything just works like it should. To take a few
things from your snippet that are suspect to me:
w.width( 400 );
w.height( 200 )
Where do 400 and 200 come from? This seems arbitrary to me. The GUI
system should be able to tell how to size itself.
Have you invented universal algorithm for window size/position ?
b.align( alignment::vcenter | alignment::hcenter );
A real world application needs much more sophisticated positioning
mechanisms than this. The tiny snippet above (in my code) hides some
pretty good positioning logic.
Don't be boring, this is just simple example ... without details in mind.
sophisticated positioning mechanism can be implemented by
control/window class methods too. Even more, such interface allows
changing behavior in runtime.
pb.min( 0 );
pb.max( 100 );
pb.step( 5 );
pb.smooth( true );
Again, these values should be picked automatically.
Only if you are satisfied by default values. Believe
me, this is very rare situation. Especially for progress bar
control :))
Now, it might be cool to be able to change my above code to:
gui::showmy_company_gui_traits( sample boost application,
...
Generally runtime gui styles (flat, 3d ...) can be more helpful, because
changing look-and-feel in application options is very frequent situation
for serious GUI applications. Please don't be too obsessed by compile
time, it is not very good way for GUI toolkit.
Where you can have specified such things as whether or not your progress
bars are smooth and what the step size is. Maybe you could even do it
at run-time.
get_my_company_gui_traits().show(sample boost application,
...
My motivation for the design of this again:
- GUI code is difficult, tedious, and error prone even for simple tasks,
I want to make it simple (for simple tasks)
Agree! But only for simple tasks.
Now things are clear. My conclusion is following :
1. Such interface is ok for no-so-compicated gui and/or controls.
I mean situations when you are satisfied by default values
for properties or properties differ from default ones not so much.
2. It should be implemented on to of more functional, runtime,
interface ( used in most gui libs).
- control positioning is especially difficult
If you mean MFC or pure win32, most probably it is true. But don't
forget there are a lot of other GUI libs around which can handle this
problem without significant problems.
- Consistency in GUI applications is difficult. Give ten programmers a
lower level GUI API and they'll turn out ten applications each with a
different look and feel. I don't want to have to remember that step
size for our company is always '5', for instance.
Interface proposed by me can and should have default values as well.
If we head in the direction we've been talking we would also provide a
cross platform lower level API where you could get more control and do
things like what you describe below. I hope that most programmers would
find it unnecessary though.
IMHO this interface is must.
regards,
bohdan
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: GUI sublanguage ?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Philippe A. Bouchard Sent: Thursday, August 07, 2003 4:04 PM To: [EMAIL PROTECTED] Subject: [boost] Re: GUI sublanguage ? [EMAIL PROTECTED] wrote: [...] After having followed this thread I wander if we are trying to reinvent the wheel. By googling a bit one can find plenty of Gui Toolkits and here I saw little of them. Not a word on Qt, for example. I never used it for an important project but they give a (good ?) solution for example to the layout issues discussed so far. If I should criticize them (as a lazy user who is in troble finding his way among all those features) if the fact that there are huge classes that probably need further decomposition of resposibilities. Anyway Qt make life simple for simple apps and provides something that scales quite well for larger projects (I haven't used it but I can use KDE as witness). So I would like to have a clearer idea of the difference between the goal of this thread and existing solutions (i.e. Qt). At some degree it becomes political issues. I doubt Boost would want to take the same risky path I took (Corel). Qt is a commercial library for one thing. For another, developing a platform independent GUI environment is only half of our purpose. The other is to leverage modern C++ techniques to simplify making GUIs. A quick glance at Qt's class hierarchy should be enough to see that they are not using such a design: http://www.trolltech.com/images/classchart.gif. Brock ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: GUI sublanguage ?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joel de Guzman Sent: Wednesday, August 06, 2003 5:51 PM To: Boost mailing list Subject: Re: [boost] Re: GUI sublanguage ? Brock Peabody [EMAIL PROTECTED] wrote: Have you invented universal algorithm for window size/position ? It works surprisingly well. I know I described it in detail in an earlier post, I can sum it up again if you like. It works well especially if you need complete resizability. Please do. I've lost track of the thread and I want to catch up. When we first started doing GUIs, we put things exactly where we wanted them :) We would either disallow or ignore resizing. This is the type of sizing logic that is promoted by RAD tools. Eventually you find that you can't ignore the issue. Our first attempt at a sizing 'algorithm' was that everything in a window was sized proportionally as the window grew and expanded. This led to cartoonish screens at large sizes. The reason is that some controls benefit from increased size and others don't. More specifically, each type of control usually has a minimum and maximum desired size for each dimension (sometimes the maximum is unlimited). Examples: static text - fixed size horizontally and vertically line edit - fixed size vertically. Minimum of one character horizontally and unlimited size horizontally. masked edit - both horizontal and vertical sizes can be fixed based on the mask. The earliest version of this library was concerned strictly with laying out controls. Each layout composition function returns an object that can be positioned in a rectangle, and can tell you what its desired size is for each dimension. If you pass a plain window to one it will 'wrap' it for you. The objects returned by the composition functions can in turn be passed to other composition functions (or themselves recursively). row(x, x1, ... xn) - positions its components one after another horizontally. Space is allocated first for 'minimum sizes'. Left over space is split evenly among components with no maximum, or with maximums that are greater than their minimums. column(y, y1, ... yn) - same as row but vertically gridnumber of columns(c0, c1, ... cn) - sometimes it is important for the elements in subsequent rows to 'line up'. You can use the grid function impose more strict sizing than is possible with combinations of rows and columns. I realize that this scheme won't solve all the world's problems, but it comes close :) You can imagine that one could come up with more composition functions, I just haven't needed any yet. This positioning library began evolving into a complete GUI library when I realized that I could allow the inline definition of static text controls, and get rid of them completely: row (label: , some_control); After that I wanted to get rid of more controls and define them all inline. I hope I explained that well. My communication skills could be improved :) Brock ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: GUI sublanguage ?
Adobe has a tool called ADM - Adobe Dialog Manager, which is used in many of their programs. You can see the docs for ADM in (for example) the Acrobat SDK, since you can use ADM when writing plugins for Acrobat. In ADM, you define your dialogs in a text-based format, giving control types, sizes, and text, and ADM lays out the dialogs, and passes information back to you based on what the user does. The big advantage here is that all the layout smarts are in one place, and they match the IU guidelines of the platform that the program is running on. The disadvantage is that if you want to do something that is not supported by ADM, you have to call the platform APIs, and your portability is shot. After having followed this thread I wander if we are trying to reinvent the wheel. By googling a bit one can find plenty of Gui Toolkits and here I saw little of them. Not a word on Qt, for example. I never used it for an important project but they give a (good ?) solution for example to the layout issues discussed so far. If I should criticize them (as a lazy user who is in troble finding his way among all those features) if the fact that there are huge classes that probably need further decomposition of resposibilities. Anyway Qt make life simple for simple apps and provides something that scales quite well for larger projects (I haven't used it but I can use KDE as witness). So I would like to have a clearer idea of the difference between the goal of this thread and existing solutions (i.e. Qt). regards ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: GUI sublanguage ?
Bohdan wrote: [...] There are a lot of good reasons why we would not always want to have total control. Not always means sometimes not ? According to this logic your gui language is layer built on top of interface proposed by me ... just for convenience. Right ? I looks like a competition between the two of you... I want my applications to be as simple as possible, and to all look the same. Generally GUI applications are semantically complicated. Forget about universal cure from this. Everithing you can do is to symplify development in some cases. It doesn't make sense to start positionning every widget manually like this. What if you find you're interface ugly (p = 0.90) the first time and you have found a better idea? You are going to retype the position of every widgets in the whole application?!? If you are planning to do this, I suggest to use another GUI application which will generate the spaghetti part of you're code. If the GUI library picks the 'best' settings for the platform automatically, the individual programmer doesn't have to think about it. Everything just works like it should. To take a few things from your snippet that are suspect to me: w.width( 400 ); w.height( 200 ) Where do 400 and 200 come from? This seems arbitrary to me. The GUI system should be able to tell how to size itself. Have you invented universal algorithm for window size/position ? It is possible to use horizontal / vertical / grid layout recursively which will deduce the position of your widgets given your criterias. Another container-like widget; i.e. container oriented design. With experience it becomes easy. [...] Generally runtime gui styles (flat, 3d ...) can be more helpful, because changing look-and-feel in application options is very frequent situation for serious GUI applications. Please don't be too obsessed by compile time, it is not very good way for GUI toolkit. I agree, you should draw some line between compile-time / run-time. Not to much run-time though. [...] - GUI code is difficult, tedious, and error prone even for simple tasks, I want to make it simple (for simple tasks) Agree! But only for simple tasks. You mean the opposite... The time required for complex applications would be exponential. [...] Philippe ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI sublanguage ?
Brock Peabody [EMAIL PROTECTED] wrote: Have you invented universal algorithm for window size/position ? It works surprisingly well. I know I described it in detail in an earlier post, I can sum it up again if you like. It works well especially if you need complete resizability. Please do. I've lost track of the thread and I want to catch up. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
