Re: [Texmacs-dev] Re: Compiling TexMacs on OSX

[Henri Lesourd]

David Allouche wrote:

> On Mon, Jun 16, 2008 at 9:31 PM, Abdelrazak Younes <address@hidden> wrote:
>  
>
> > Henri Lesourd wrote:
> >    
> >
> > > It seems to me that a part of your problems
> > > stem from the fact that you did not followed
> > > a 100% strict policy of designing *simple*
> > > and *platform-independent* APIs for the
> > > purpose of isolating the core, platform-dependent
> > > part of the GUI from the rest of the reuseable,
> > > platform-independent code.
> > >      
> > Oh we did that (not me actually), but decided to scrap it all. I just wanted
> > to warn you of the possible consequence, that's all. But you seem to be
> > pretty convinced of your case so I won't insist :-)
> >    
>
> I do not have a lot of authority here anymore, but as a formerly
> active texmacs developer with a bit of experience in GUI programming,
> I lean strongly towards Abdelrazak's position: the right way around is
> to have a platform-specific GUI drive a platform-independent core.
>
>  
Everything depends on what you mean by this.

I'm pretty sure that if we look at the details,
what you want is to implement an API which can
be used to implement *NEW* components.

That's what I *DON'T* want to do: my business
is only in defining a way to encapsulate *USUAL*
components which already exist.


> For TeXmacs, the core would be the
> document-interpreter-typesetter-renderer-editor system.
>
> That means that some stuff like menu generation and front-end
> keyboard-handling ends up in the platform-specific part. They would
> use a portable APIs to the back-end to produce the keychord
> functionality or find how the toolbars and menus need to change
> according to the document context.
>
> In other words, texmacs developers should be in the business of
> definining APIs for the unique things texmacs does, instead of trying
> to invent a nth portable GUI toolkit API.
>
>  
Yes, but then you end up having to reimplement much
more platform-dependent code behind your "API for the
unique things TeXmacs does".

Once you are here, of course you are logically driven
to the approach Abdelrazak advocated: namely using only
one toolkit.