Re: [Foxgui-users]FXScintilla-1.42fox1

Neil Hodgson wrote:
> 
>    Hi Gilles,
> 
> > I've updated FXScintilla to the last Scintilla version (1.42).
> 
>    Thanks for the porting.
> 
>    I have integrated some of your changes into the main Scintilla and SciTE
> code bases.
>    All of your changes in scite/src are merged in.
> 
Thanks a lot. It will save me some work.

>    For Platform.h:
>    The PLAT_FOX definition is included.
>    The definition of TickerID in Platform.h is made for all platforms and
> some corresponding casts make this work on Windows.
>    However, I don't like the definitions of FX* like FXFont and FXDrawable.
> I'm trying to reduce the use of platform types within Scintilla and so now
> use typedefed void*s for the Scintilla and GTK+ handle types, so I think it
> is reasonable for FOX to also use typedefed void*s with casting in PlatFOX
> and ScintillaFOX.
My opinion is that writing
	class FXFont;
	typedef FXFont *FontID;
actually costs *nothing* more than :
	typedef void *FontID;
because the compiler needs to know about FXFont only when processing the
PlatFOX.cxx source.
And I see two more advantages :
	- safe typechecking (no need to typecast from void* to FXFont)
	- better readability of the source code (again, no need to typecast).
The only drawback I see is that it clutters platfrom.h with as many
definition as platforms. But well... I think it doesn't matter since it
does not require including platform dependent headers. See below also.

> In the future, I'd like to move in the direction of only
> having interfaces defined in Platform.h without any data fields, changing
> the code in the same way as was done for Surface recently. If you want to
> continue with your own version of Platform.h that defines FX* then that is
> fine, but there are advantages to only having one definition.
I agree with you on this point.
FontID, WindowID and co are implementation details. They shouldn't be
used by the interfaces. They shouldn't even appear in platform.h.
I'd like to keep my own xxxID definitions until these changes are done.

>    Defining a method called Show in ListBox when there is already a Show in
> its superclass Window is confusing. I think the correct change here is to
> make Show virtual in Window and give it the same argument in ListBox as in
> Window. I'll just define it to call Window::Show on the GTK+ and Windows
> platforms.
> 
OK. But you don't need to redefine ListBox::Show on the GTK+ platform
since the superclass' method Window::Show would be appropriate in this
case.

>    Neil
> 
_gilles.