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::show( "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
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
grid(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
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
