--- 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.
thread<win32Traits> thread;
thread<win32FiberTraits> 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::button<gui::win32> into a
> gui::dialog<gui::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< control<ImplTraits> > 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::window<MyTinyTraits> 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
};
dialog<QtTraits> qtDlg;
dailog<MyQtTraits> 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::dialog<gui::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
