Subject: Re: XP code (take 2)
From: Hubert Figuiere (hfiguiere@teaser.fr)
Date: Tue Feb 13 2001 - 16:07:30 CST
At 11:17 -0500 13/02/01, Dom Lachowicz wrote:
>>event if functionnally it is XP. So why not, for each XP class that is
>>abstract to provide platform FE don't we declare a static method (for
>>example XAP_Class::constructPlatformObject()) that we will implement in the
>>platform code (ie we provide declaration un XP code and implementation in FE
>>code) thus allowing to instantiate this object from XP code. This have been
>>made for some, but not for all. Or I am missing something.
>
>We already have this, but it needs to be propegated up a layer for
>it to be of use to us. It's the static_constructor() method that
>every FE dialog has, but it doesn't exist as a prototype in the XP
>base dialog. So if we make the declaration of this method one level
>higher and make it a pure virtual function (virtual fun() = 0;) we
>should be able to do this.
Static and virtual are purelly incompatible. And the way
static_constructor are done are nice to store a constructor within
some static struct, but they are not for the way I wanted to do. Here
an example:
foo.h
-----
class foo {
public:
foo ();
virtual ~foo ();
static foo * newPlatformFoo ();
};
platformFoo.h
-------------
#include "foo.h"
class platformFoo
: public foo
{
public:
platformFoo ();
virtual ~platformFoo ();
};
platformFoo.cpp
---------------
#include "platformFoo.h"
foo * foo::newPlatformFoo ()
{
return static_cast<foo *>(new platformFoo ());
}
main.cpp
--------
#include "foo.h"
#include "plaftormFoo.h"
void main ()
{
foo * myFoo = foo::newPlatformFoo();
}
>
>My only concern is how this might affect the Gnome build, since in a
>lot of cases, there would be GTK_Dialog::static_constructor() lying
>in front of the GNOME_Dialog::static_constructor()
That is something we have to think about. But #ifdef can be enough
since Gnome is a platform at all :-)
>Let me say this now: Implementing our own "widget set" is a *very
>bad* idea. If you're thinking about doing this, port us to wxWindows
>instead. However, making our current design easier to use XP is a
>worthwhile cause, esp. if we can cut down on code duplication and
>dialog creation time. Please note the crucial difference.
I'm not talking about something like WxWindows. Just some helpers
that provide widget level granularity to help manage dialogs in XP
code. Just because currently we have HWND for Win32, GtkWidget * for
UNIX, BControl * for BeOS, ControlHandle for MacOS, and so on. And
this prevent doing functionnal management of these inside XP code.
The XAP_Frame use specific classes for the different widgets inside,
so why not for dialogs. Note that this still implies that each
platform porter implement dialog creation, and link beeween the real
widget and our abstract classes.
I volunteer to build the XP classes along with their MacOS implementation.
>Wouldn't anyone like to go tackle a few bugs in bugzilla or work on
>some of our performance issues instead?
I'd like, but I prefer to make MacOS platform work first.
Hub
This archive was generated by hypermail 2b25 : Tue Feb 13 2001 - 16:07:29 CST