RE: [boost] Re: GUI/GDI template library
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of E. Gladyshev Sent: Wednesday, August 06, 2003 5:21 PM To: Boost mailing list Subject: Re: [boost] Re: GUI/GDI template library --- Bohdan [EMAIL PROTECTED] wrote: 2. Finally your lib may become non-template ( i mean cpp files) ... If it becomes not-template, I'll stop working on it :). cpp files are allowed for the layer 1 code and compilation-time optimization wrappers only, that's it! Both has little to do with the library itself. It may not be necessary to templatize some of the lower levels of the implementation. The interface will almost certainly be all templates. What about simple boost::gui ? I would like to have an unique name without the boost prefix. I think the boost namespace is a requirement for any boost library. Brock ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
E. Gladyshev [EMAIL PROTECTED] wrote: The notus project has been setup on sf. http://sourceforge.net/projects/notus It has several public forums including the Design forum. No mailing list? IMO, I would highly suggest a mailing list instead of a web based forum. Easier to post-to, maintain, archive, etc. -- 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
RE: [boost] Re: GUI/GDI template library
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Deyke Sent: Wednesday, August 06, 2003 12:32 PM To: [EMAIL PROTECTED] Subject: [boost] Re: GUI/GDI template library Brock Peabody wrote: Method 1 - common underlying representation method layer 1 - target GUI API layer 2 - low level GUI API interface wrapper. There is one implementation of this wrapper that compiles for all target platforms, using standard cross-platform development methods. This layer may be private to boost (in namespace detail). layer 3 - high level boost GUI API. This is the public interface to our GUI 'domain specific sublanguage'. It is implemented on top of layer 2. Like I said before, I would need to use a custom layer 1. This means that I also have to write a custom layer 2 under both methods. If boost::gui is to be useful for me at all, it has to provide layer 3, and the interface between layers 2 and 3 has to be public. If layer 2 is platform independent there is no reason not to make it public, other than to promote the use of the higher level abstractions at layer 3. Oh, and I really want the ability to select layers 1 and 2 at runtime, in a single place in my code, on a per top-level window basis. Let's just try to get it working first. I don't doubt that we could do this but is it worth the cost in increased complexity to both the implementation _and_ the interface? ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: GUI/GDI template library
--- Brock Peabody [EMAIL PROTECTED] wrote: Oh, and I really want the ability to select layers 1 and 2 at runtime, in a single place in my code, on a per top-level window basis. Let's just try to get it working first. I don't doubt that we could do this but is it worth the cost in increased complexity to both the implementation _and_ the interface? If decide to use method 1, I think the ability to use different layer1 implementations in the same program will come as a natural benefit w/o any additional complexity. Actually it is true for method 2 as well. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
--- Bohdan [EMAIL PROTECTED] wrote: 2. Finally your lib may become non-template ( i mean cpp files) ... If it becomes not-template, I'll stop working on it :). cpp files are allowed for the layer 1 code and compilation-time optimization wrappers only, that's it! Both has little to do with the library itself. What about simple boost::gui ? I would like to have an unique name without the boost prefix. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: GUI/GDI template library
--- Brock Peabody [EMAIL PROTECTED] wrote: What about simple boost::gui ? I would like to have an unique name without the boost prefix. I think the boost namespace is a requirement for any boost library. Sorry, I didn't mean to put the library out of the boost namespace. The namespace will be boost::sgtl. I just wanted the name itself to be uniq w/o attaching boost:: to it. Eugene Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
It might not be too hard to make the GUI objects 'serialize' themselves into a native resource file but this would be useless without something to convert a resource file back into C++ code. Something like this could be written on top of a pure C++ solution with the help of a serialization library. Indeed, that would be cool! I suppose you're talking about something that will write ALL GUI objects from a OS-independent resource file to a native resource file. Best, John ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
--- David Abrahams [EMAIL PROTECTED] wrote: E. Gladyshev [EMAIL PROTECTED] writes: Is MPL a modern TEMPLATE library, in your opinion? I ask because compilation time is a very serious issue in the design of MPL. In my opinion MPL is a great example of a tool for creating modern C++ programs/libraries. The h/w and compiler designers will have to deal with the compilation time issues. It is their job. When you are writing music the last thing that you should be thinking about is how these guys are going to play it :). IMO it's nutty to think that people won't use every bit of compilation bandwidth they can stand, once they start to do computation at compile time. Why should it be any different from cycles at runtime? By people you mean developers. The developer's time is a tricky issue. If you have a better library with a long compilation time and not so good library with a better compilation performance, which one do you choose? If you choose the bad library, you can be saving on the compilation time but loosing on the development time. How do you count it? Do you care how much effort/time did it take to build you car? I don't. Personally I care about creating a beauty, not the compilation time. In many ways, the more modern a C++ library is, the more of a concern compilation times have to be. I agree, but the other guys have to deal with it. However you still can be saving on the development time. By the development time, I mean the average development time of the industry. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
It's obviously wrong to say that compile time performance does not matter. On the other hand, it's not wise to optimize the compile or run time performance of a library prematurely - start with the most beautiful design and make it more ugly as necessary :) I think we're drifting far from the topic with the whole traits (hidden or templatized) discussion. Does anyone remember the message Mr. Dawes posted where he described three levels of sophistication for the library (http://aspn.activestate.com/ASPN/Mail/Message/boost/1752449)? In my opinion, if we try to create anything beyond a simplistic, level (1) library on our first try, we're going to fail. The problem that Eugene is trying to solve with the ImplTraits mechanism may be legitimate, but I don't feel that it is part of the simplistic level 1 solution. We need to start talking about what the interface to this library should like like (a domain specific sub-language, as Mr. Abrahams said), and worry about the implementation details (a pimpl is certainly an implementation detail) afterwards. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
--- Rainer Deyke [EMAIL PROTECTED] wrote: For a GUI library to be useful to me, it would need to support custom physical GUI layers. I would then write my own [...] full-screen multimedia. I realize that my needs are unusual, and boost::gui may be unable to accomodate them. It seems strange to me, why are you willing to give up on your requirements. What is so unusual about them? I believe boost::gui must accomodate them and it can. Your requirements are very reasonable IMHO. Nonetheless I also dislike the idea of PhysicalGUILayer as a template parameter to all GUI elements. PhysicalGUILayer is great for your requirements. Why do you dislike it? It violates the principle of Once and Only Once. You can use a default template parameter for the PhysicalGUILayer and define it only once in your program. (and NativePhysicalGUILayer should be one of the options). That way the actual structure of the GUI does not depend on the physical GUI layer, and the physical GUI layer can even be selected at runtime. Exactly my point. Thanks for your post. Finally we have a set of requirements from someone who is doing custom GUI development. IMO boost::gui must be able to accomodate them. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: GUI/GDI template library
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Abrahams Sent: Wednesday, July 30, 2003 6:31 PM To: [EMAIL PROTECTED] Subject: [boost] Re: GUI/GDI template library [...] I think so. See Boost.Python and Boost.Spirit for examples. I think Spirit was on my mind while doing this. Anyway, I guess I have developed the beginnings of a sublanguage. This example shows just a few elements that I have so far extracted from my work environment. This example compiles under MSVC 6.0. I probably have lots of missing typenames right now. I know that the implementation is not boost ready - it was violently ripped from my libraries and jumbled together. The interface is demonstrated in boost_gui_test/dialog.cpp. Notice that in dialog.h and dialog.cpp there are no direct references to any MFC/Win32 objects. I have uploaded the code into the yahoo files section. It's called boost_gui.zip. All of the functions in the library deal with what I'll term GUI objects. Some of the things you can do to a GUI object are: copy it position it in a Rectangle call set() on it with a user defined object. In this example I use an employee object. It loads component controls with the employee call get() on it with a user defined object. It extracts data from the controls into the UDT register a function object for change notification by calling set_on_change() query the GUI for data errors ask the GUI what its size requirements are tell the GUI to clear itself. There are more things than just these. Most of the time the system will take care of calling all of the necessary functions. In my example the only call is to set(). Here are some of the 'composition' functions that can be used to build GUI's that are included in the example. row(x0, x1, ... xn) Row takes 1 to a macro defined number of GUI objects. It returns a GUI object that manages the GUIs it contains and arranges them horizontally. column(y0, y1, ... yn) Just like row but arranges objects vertically. group(std::string label, GUI g); Group returns a GUI object that draws a box around the one it is passed, and puts the given label at the top. I also use three types of GUI 'atoms'. static text. If you pass an item that is convertible (I literally use boost::is_convertible) to std::string to a GUI composition function, it will generate a static text object inline. edit(data exchange information) edit() generates an inline edit control. You have to tell edit (and other GUI atoms) how they will exchange data with the UDT. I've got the system set up to handle three ways right now. I know there is a better(more general) way to do this but am limited by VC 6. 1) pointer to member - edit(employee::ssn) 2) pointer to get and set functions - edit(employee::get_pay_rate, employee::set_pay_rate) 2) pointer to mutable and const get functions. Usually used when an object has complex subobjects which are accessed by functions that return mutable and const references when the parent object is mutable or const, respectively. I do not include an example of this because the interface is (much) less than ideal under VC 6.0. date_time(data exchange information) This actually is only capable of exchanging dates right now. We pass dates around as integers in the form of mmdd. This should be changed to use the boost date_time library, but you get the idea. There are some atoms that are included in the example library but not demonstrated. If there is interest I will do some more thorough examples: control_container - a structure that adapts a more standard windows derived class (from my controls library or user defined) into a GUI object: control_containercontrols::callback_edit my_edit; exchange() - adapts a GUI object to a different exchange interface: exchange(my_edit, employee::ssn) - edit(employee::ssn) control() - makes it easier to construct control containers: controlbenefits_window(employee::benefits); There are a lot of concepts I have not included in the example but have implemented: grids of GUIs check_boxes, buttons, radio buttons tying the above to GUI's so that their enabled states can be changed automatically. vector/map based combo boxes vector/map based list boxes vector/map based list controls vector/map based grid controls masked edits easily defining/integrating sub-windows Anyway, if there is any interest I can make better documentation and examples. Is anyone interested in this direction for a GUI library? I would certainly want to rework the implementation from the ground up, but even the way it is, it's pretty powerful. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
Pimpl definitely has its place.
I agree, but boost::threads and boost::gui would be
much better of with ImplTraits, in my opinion.
If you buy Doug G.'s argument that no application
will use two
GUIs at once
No I don't buy Doug's argument at all.
Here is an example.
//customize the edit control to be an eleptical shape.
class ElepticalShapeWin32Impl : public gui::win32
{
//overload edit control stuff.
};
main()
{
gui::dialoggui::win32 myStandardDlg;
...
gui::dialoggui::ElepticalShapeWin32Impl
myFancyDlg;
...
}
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
On Fri, 1 Aug 2003, E. Gladyshev wrote:
Pimpl definitely has its place.
I agree, but boost::threads and boost::gui would be
much better of with ImplTraits, in my opinion.
Because one might use multiple threading models in a single program? Since
we already have a boost::threads design to compare against, could you
explain how the ImplTraits idiom would improve it? I'm not attempting to
deflect: the problem with examples like the one you give below is that
it's all too easy to gloss over details that can sink a design.
If you buy Doug G.'s argument that no application
will use two
GUIs at once
No I don't buy Doug's argument at all.
Here is an example.
//customize the edit control to be an eleptical shape.
class ElepticalShapeWin32Impl : public gui::win32
{
//overload edit control stuff.
};
main()
{
gui::dialoggui::win32 myStandardDlg;
...
gui::dialoggui::ElepticalShapeWin32Impl
myFancyDlg;
...
}
Eugene
Ah, so here's a question: what sort of relationship exists between
myStandardDlg and myFancyDlg? They will likely be similar semantically,
because we can still place widgets in each of them, show/hide them, etc.,
but they'll show up differently for the user.
Can I put a gui::buttongui::win32 into a
gui::dialoggui::EllipticalShapeWin32Impl? Or a
gui::buttongui::EllipticalShapeWin32Impl into a gui::dialoggui::win32?
If so, how do the button and the dialog communicate, e.g., for adjusting
to a window resize event? I see two communication options:
1) One communication system common to all GUI implementations?
Then we are stuck translating every message into and out of this
communication system. Not very clean, IMHO.
2) Communication through the ImplTraits? This seems the natural
route, but now we have O(n^2) combinations of translations. What if I want
to stick a Qt button into a Win32 dialog? Or a gtk+ button into a Qt list
box in a Motif dialog?
In a cross-platform framework, how deeply ingrained should our
platform-specific decisions be? How does one write a truly portable GUI
app: by starting with gui::dialoggui::win32?
Doug
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
--- Douglas Paul Gregor [EMAIL PROTECTED] wrote:
On Fri, 1 Aug 2003, E. Gladyshev wrote:
Because one might use multiple threading models in a
single program? Since
we already have a boost::threads design to compare
against, could you
explain how the ImplTraits idiom would improve it?
The benefits are obvious. For instance if I had my
toy operating system, I could use boost::treads by
defining ImplTraits for my toy OS w/o going to the
boost sources. Another example is that Win32 already
has two different threading models, normal threads and
fibers that can be used at the same time in one
application. Theoritically boost::threads can be used
there as well.
threadwin32Traits thread;
threadwin32FiberTraits fiber;
Ah, so here's a question: what sort of relationship
exists between
myStandardDlg and myFancyDlg?
They can have a relationship on the data level only.
Can I put a gui::buttongui::win32 into a
gui::dialoggui::EllipticalShapeWin32Impl?
No, you cannot. The dialog class is just an example of
a high level object that manages lists of other
controls.
template typename ImplTraits
class dialog
{
std::list controlImplTraits m_contols;
//do stuff
};
NOTE: In my example, buttons in the
EllipticalShapeWin32Impl will look a behave the same
as in win32. Remember EllipticalShapeWin32Impl is
derived from win32 and overloads only edit box
functions. This is the beauty of ImplTraits you can
customize only a portion of it. Another big advantage
is that ImplTraits allows you to implement only stuff
you want to use. For example if all that you are
intending to use in your app is gui::window you don't
have to worry about contorl functions in your
ImplTraits. For example:
class MyTinyTraits
{
//simple window management
}
gui::windowMyTinyTraits window;
ImplTraits is a very scaleable solution as well.
1) One communication system common to all GUI
implementations?
Then we are stuck translating every message into and
out of this
communication system. Not very clean, IMHO.
2) Communication through the ImplTraits? This seems
the natural
route, but now we have O(n^2) combinations of
translations.
Good points, but I don't really think that we have to
go that far.
What if I want
to stick a Qt button into a Win32 dialog? Or a gtk+
button into a Qt list
box in a Motif dialog?
You can accomplish it at compile-time only by
overloading Qt traits for all buttons.
class MyQtTraits : public QtTraits
{
//overload button functions
};
dialogQtTraits qtDlg;
dailogMyQtTraits qtDlgWithGtkButtons;
In a cross-platform framework, how deeply ingrained
should our
platform-specific decisions be?
It is a very good question. I think we should design
it based on our common sense and development
experience. I don't think that there is a simple rule
to answer this question.
How does one write a
truly portable GUI
app: by starting with gui::dialoggui::win32?
Actually gui::dialog is closer to the end, not the
start. It is a high level class that should have a lot
of policy/rules template parameters that will define
how the dialog behaves. The question of the
customization level and what type of polices it should
have, is related to you prev. question.
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
But localisation should be orthogonal to the GUI library. By all means let's have (eventually) a resource loading library that understands native resource files, but there's no reason for that library to be on intimate terms with the GUI library Localization is not just changing a set of labels and strings. I had some localization experience at InstallShield. Sometimes you need to change the GUI layout as well. The problem is that the approach suggested by Brock and Philippe is a compile-time GUI design. If you want to be able to use the GUI library with resource files, the GUI library should be more oriented toward the run-time design. In this case you can make the GUI library orthogonal to external GUI scripts. It is a very important trade off. I don't know what is the best way to go. It is a critical issue from my standpoint. BTW: I really like Philippe's approach. It is very basic and inherently scaleable but it is not a run-time design. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
At 02:24 AM 7/30/2003, E. Gladyshev wrote: ...[compile-time or run-time?] I don't know what is the best way to go. It is always hard to know the best way to go if you don't know where you are going. A GUI/GDI library might fill one or more needs: 1) A conceptually clean library, easy-to-use, good for teaching GUI principles, and useful for real applications where the emphasis is on portability. Controlling the look-and-feel on different platforms not a concern. Access to platform specific features not a concern. 2) An adaptable library for applications which do need a certain amount of control over look-and-feel on different platforms. Portability is quite important, but so is ability to adapt look-and-feel to different platforms. Access to some platform specific features may be a concern. 3) Totally controllable library for applications which need to manage every aspect of look-and-feel, and need access to every feature the platform provides. Portability not a concern. (That's an oversimplification, but good enough for discussion.) Baring a stroke of genius (although on Boost that isn't totally impossible), it seems very hard to fill all of those needs. It seems to me that most people who need (3) (or think they need (3)) aren't going to use a portable library anyhow. I'd write-off (3) as a target. Once you get over the mental hurtle of being willing to say this library doesn't try to fill every possible need, then (1) starts to look very attractive. It is a niche many other GUI libraries seem to have ignored. If you concentrate on a conceptually clean and elegant design, then it may turn out that it can also accommodate (2) fairly well. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: GUI/GDI template library
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Beman Dawes Sent: Wednesday, July 30, 2003 7:09 AM To: Boost mailing list Subject: Re: [boost] Re: GUI/GDI template library At 02:24 AM 7/30/2003, E. Gladyshev wrote: ...[compile-time or run-time?] I don't know what is the best way to go. It is always hard to know the best way to go if you don't know where you are going. A GUI/GDI library might fill one or more needs: 1) A conceptually clean library, easy-to-use, good for teaching GUI principles, and useful for real applications where the emphasis is on portability. Controlling the look-and-feel on different platforms not a concern. Access to platform specific features not a concern. 2) An adaptable library for applications which do need a certain amount of control over look-and-feel on different platforms. Portability is quite important, but so is ability to adapt look-and-feel to different platforms. Access to some platform specific features may be a concern. 3) Totally controllable library for applications which need to manage every aspect of look-and-feel, and need access to every feature the platform provides. Portability not a concern. (That's an oversimplification, but good enough for discussion.) Baring a stroke of genius (although on Boost that isn't totally impossible), it seems very hard to fill all of those needs. It seems to me that most people who need (3) (or think they need (3)) aren't going to use a portable library anyhow. I'd write-off (3) as a target. Once you get over the mental hurtle of being willing to say this library doesn't try to fill every possible need, then (1) starts to look very attractive. It is a niche many other GUI libraries seem to have ignored. If you concentrate on a conceptually clean and elegant design, then it may turn out that it can also accommodate (2) fairly well. --Beman I agree completely. Just getting (1) done will be enough work and we'll learn a lot. I think the focus should be on a clean and elegant interface. My suspicion is that applications generated with (1) will look more 'typical' for their platform than those making applications that need (3). They'll be portable, and at the same time exhibit more platform specific run time behaviour. Programmers using (3) need more control because they are not making an application that has a GUI typical for their platform. If you want all of your application's list boxes to behave exactly the same on all platforms, you are going to have to do a lot more work than if you want windows list boxes to behave like windows list boxes, and Mac list boxes like Mac list boxes, etc... We had a programmer who was resistant to using our GUI libraries because they limited his ability to add his own custom look and feel to each of his applications. His applications looked cool - but not like standard windows programs. They also tended to take a long time to produce and debug. The code was complicated and his custom logic had to be reimplemented for each new application. We don't want complicated applications with a custom look and feel. We want simple applications with a uniform look and feel. This need can be filled by (1) and I suspect many others will feel the same. Brock ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
...[compile-time or run-time?] I don't know what is the best way to go. It is always hard to know the best way to go if you don't know where you are going. A GUI/GDI library might fill one or more needs: ... [Controlling the look-and-feel] Setting aside the poster's philosophical comments. What does look-and-feel have to do with the compile-time or run-time question? As for the look-and-feel, again the library simply doesn't have to care about how a control looks and feels. If you want to control look-and-feel, you can always do it, if not, you can use one of the standards Win32, X, etc. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: GUI/GDI template library
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of E. Gladyshev Sent: Wednesday, July 30, 2003 10:50 AM To: Boost mailing list Subject: Re: [boost] Re: GUI/GDI template library ...[compile-time or run-time?] I don't know what is the best way to go. It is always hard to know the best way to go if you don't know where you are going. A GUI/GDI library might fill one or more needs: ... [Controlling the look-and-feel] Setting aside the poster's philosophical comments. What does look-and-feel have to do with the compile-time or run-time question? Every design will have both run-time and compile-time aspects. In my opinion, you should defer until run-time only things that cannot be determined at compile-time - why wait? The simpler the system, the more decisions we will be able to make at compile-time. As for the look-and-feel, again the library simply doesn't have to care about how a control looks and feels. If you want to control look-and-feel, you can always do it, if not, you can use one of the standards Win32, X, etc. The problem is that a simple solution may not provide adequate support for those who do care about (non-standard) look and feel. It will necessarily provide support for various standards, which should be enough for an important number of applications. Brock ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: GUI/GDI template library
Every design will have both run-time and compile-time aspects. I agree. Where do you draw the boundary? What is the correct mix of these two aspects? That's the tradeoff I was talking about. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: GUI/GDI template library
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of E. Gladyshev Sent: Wednesday, July 30, 2003 11:57 AM To: Boost mailing list Subject: RE: [boost] Re: GUI/GDI template library Every design will have both run-time and compile-time aspects. I agree. Where do you draw the boundary? What is the correct mix of these two aspects? That's the tradeoff I was talking about. If a decision is based on information that cannot be known at compile-time then you must make that decision at run-time. There is no choice. We don't know the sequence of keystrokes a user will type into an edit control, for instance. If you have enough information to decide something at compile time, do it then - you gain nothing by waiting and gain an increased ability to catch mistakes earlier by doing it immediately. The question then becomes how much run-time flexibility you want to incorporate into your design. With increased flexibility comes increased complexity. For phase (1) of Beman's I would shoot for the bare minimum. Often, we will be able to add in the more flexible run-time logic seamlessly without affecting the compile-time framework: row(name: , edit(employee::name); Could later become: row(string_resource(name_string_identifier), edit(employee::name)); Is this a better answer to your question? Brock ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: GUI/GDI template library
If a decision is based on information that cannot be known at compile-time then you must make that decision at run-time. How do you decide what information can and what cannot be know at compile-time. For instance if you want to use an external fullblown scripting definition of the GUI layout, almost no information is know at compile-time. I put my question another way, how much of POTENTIAL scripting functionality the library should provide? Note: The option to generate C++ code and rebuild the app when changing the GUI script is not considered at this momement. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
I believe that MS has. They have CDHtmlDialog in MFC. You can script dialog layouts just like web pages. Eugene --- David Abrahams [EMAIL PROTECTED] wrote: Has anyone given thought to the design of a domain-specific sublanguage for dialog layout specification? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: GUI/GDI template library
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of E. Gladyshev Sent: Wednesday, July 30, 2003 1:27 PM To: Boost mailing list Subject: RE: [boost] Re: GUI/GDI template library If a decision is based on information that cannot be known at compile-time then you must make that decision at run-time. How do you decide what information can and what cannot be know at compile-time. For instance if you want to use an external fullblown scripting definition of the GUI layout, almost no information is know at compile-time. I put my question another way, how much of POTENTIAL scripting functionality the library should provide? I think that the scripting environment should be built on top of the coding library. The 'basic' platform independent GUI library would provide unlimited potential to be used as the foundation for a scripting library. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: GUI/GDI template library
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Abrahams Sent: Wednesday, July 30, 2003 1:54 PM To: [EMAIL PROTECTED] Subject: [boost] Re: GUI/GDI template library Has anyone given thought to the design of a domain-specific sublanguage for dialog layout specification? Do you mean an external scripting language, or a language within C++? I'd never thought of designing a library like a language but it sounds like the right kind of idea for this library, since the interface will essentially be a domain-specific sublanguage with a large domain specific vocabulary, and especially since interface will be the key problem to solve for this library. Is this what you meant? ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: GUI/GDI template library
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bohdan Sent: Tuesday, July 29, 2003 11:29 AM To: [EMAIL PROTECTED] Subject: [boost] Re: GUI/GDI template library Hi, Looks like that most ideas about GUI library are spinning around spirit- like interface. What about simple resource files ? XML? Despite this approach is old enough, it has a lot of advantages : 1. Resouce files can be easily edited by hand, contrary to inline GUI-building code. I don't think custom resource files would be any easier to edit that inline C++ code. I think they would be much less easy to edit and read. 2. GUI-building code for complicated UI will be poor for compiler perfomance and in most cases code size. As example you can look at spirit c++ parser ... Writing (for lack of a better term) spirit-like code will make your compile times increase if you are not careful. You need to break complicated GUI's into less complicated parts that can be compiled separately. 3. It is possible to create some kind of resource-editor which can dramatically increase development time. This is certainly possible (and has been done many times) but I would debate its positive effects on development time. It's the interface between the resource world and the 'real' code world that is so difficult. As you suggested, you'll have to solve many of the same problems involved in serialization - why bother doing that if your problem domain doesn't explicitly require that type of solution? Whether it's a good idea or not, I think if you were going to go to the trouble of generating a resource script language and editor that you wouldn't necessarily want to tie it to one programming language (i.e. c++). ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
On Tuesday, Jul 29, 2003, at 12:25 America/Denver, Brock Peabody wrote: ... I don't think custom resource files would be any easier to edit that inline C++ code. I think they would be much less easy to edit and read. It's been a few years, but the last time I was writing a GUI application for an international market the shops in Japan, Korea, and Ireland that we paid to localize the application required platform-native resource files as their starting point. Neither custom resources nor C++ code would have been acceptable. And before that, when I was at XVT, we put a lot of work into supporting native resource files in our portable GUI toolkit. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: GUI/GDI template library
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gregory Colvin Sent: Tuesday, July 29, 2003 1:15 PM To: Boost mailing list Subject: Re: [boost] Re: GUI/GDI template library On Tuesday, Jul 29, 2003, at 12:25 America/Denver, Brock Peabody wrote: ... I don't think custom resource files would be any easier to edit that inline C++ code. I think they would be much less easy to edit and read. It's been a few years, but the last time I was writing a GUI application for an international market the shops in Japan, Korea, and Ireland that we paid to localize the application required platform-native resource files as their starting point. Neither custom resources nor C++ code would have been acceptable. And before that, when I was at XVT, we put a lot of work into supporting native resource files in our portable GUI toolkit. It might not be too hard to make the GUI objects 'serialize' themselves into a native resource file but this would be useless without something to convert a resource file back into C++ code. Something like this could be written on top of a pure C++ solution with the help of a serialization library. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
Philippe A. Bouchard [EMAIL PROTECTED] wrote:
// ScrollViews, ButtonGroups, ListBox, ...:
typedef listwidget container;
struct container : listwidget { ... };
Uh. I would not recommend inheriting from STL. I think that template
policies would be rather more appropriate solution:
typedef boost::gui::liststd::liststd::string,
boost::gui::win32::listbox, boost::gui::fast_signals mylistbox;
myWindow.create_widgetmylistbox(myapp::ENUM_ID_LIST_OF_ITEMS,
boost::gui::position(30, 30));
myWindow(myapp::ENUM_ID_LISTOFITEMS).append(myData.begin(),
myData.end());
(just an idea)
B.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
Uh. I would not recommend inheriting from STL. I
think that template
policies would be rather more appropriate solution:
I agree with that.
myWindow.create_widgetmylistbox
(myapp::ENUM_ID_LIST_OF_ITEMS,
Just a note.
Ideally, the library won't have to deal with the
numeric control ID's. You create a widget object and
from now on you use the object's pointer/reference to
access it (no need for an ID). One exception would be
dialog boxes. Usually resource files are ID-based so
we'll probably need to use the ID's.
boost::gui::dialog dlg(IDD_HELLO);
boost::gui::edit* hello_edit(
dlg.getboost::gui::edit(IDC_EDIT_HELLO) );
Under the covers the get function would do something
like this:
template typename T, typename ID = int
T* dlg::get( ID id )
{
dlg::const_iterator it;
for( it = begin(); it end(); ++it )
{
if( it-getid() == id )
return static_castT*( *it );
}
return NULL;
}
It'd be nice to get rid of numeric id's completely.
Any ideas?
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
3. I believe almost everything can be done using the following ingredients: a. The ability to create, destroy, size, position, show and hide a rectangular window with no children and no decorations. b. The ability to draw an image (bitmap, png, etc.) at a particular point in a window c. The ability to perform simple drawing, possibly limited to filling rectangles and drawing straight lines, but possibly including more sophisticated constructs. d. The ability to draw text, with simple formatting. (Here I am thinking of text only for labels and simple edit controls. Word processing documents would not be supported.) e. A timer facility. f. The ability to harness UI events, such as mouse movements, and direct them to the appropriate widgets. I see your point. My concern is that there are many GUI frameworks like Win32, X, etc. They already have their own look and feel for the standard UI controls (buttons, etc.) I believe that the library should provide a way to use the standard controls as is. So we'll need to define a much bigger set of ingradients. I agree that one can derive other required ingradients from the ones that you listed, but it'll be your own look and feel. In any case the proposed libary should not be focusing on the drawing issues at all. For example if it needs to create a list control. It should just call the GuiTraits::create_listconrol(...) function. It won't care how it is implemented. On the side note. It seems that there is a significant interest in such a library. I'll try to setup a sourceforge project. I invite anyone to join. Stay turned. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: GUI/GDI template library
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of E. Gladyshev Sent: Monday, July 28, 2003 6:34 PM To: Boost mailing list Subject: Re: [boost] Re: GUI/GDI template library I agree that one can derive other required ingradients from the ones that you listed, but it'll be your own look and feel. In any case the proposed libary should not be focusing on the drawing issues at all. For example if it needs to create a list control. It should just call the GuiTraits::create_listconrol(...) function. It won't care how it is implemented. I agree! Though I would prefer a syntax more like: boost::gui::list_control list; //creation details hidden I also like another poster's idea of tying data types to controls. Perhaps implemented on top of boost::gui::list_control - boost::gui::typed_list_controlemployee employee_list; employee_list.add_column(name, employee::name); Brock ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
Microsoft has a Windows Template Library, WTL, for Windows specifically, which is template-based but which they barely support for their VC++ users. The main point of the proposed library is not a wrapper. WTL is just a Win32 wrapper. The main idea is to simplify the use of STL containers as data sources for UI widgets (in a portable way). See my ListControl sample in a prev. message. Also the proposed library will help to organize the GUI/GDI elements and controlling data structures in a consistent (with the C++ standard) way using the 'iterator' paradigm. It seems to me that in our practicle life, we ended up with two different worlds in our hands. One is the nice and clean C++ template world which works great to program algorithms and data strucures and another one is the dirty GUI world that we have to use to present our nice data structures. Most of the time when we try to bring these two together, the nice structure of C++ template programming doesn't look so nice anymore. It is a big project but at the end, it should bring these two worlds together (at least bit). __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
