texmacs-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Texmacs-dev] Re: Compiling TexMacs on OSX


From: Abdelrazak Younes
Subject: [Texmacs-dev] Re: Compiling TexMacs on OSX
Date: Mon, 16 Jun 2008 21:31:28 +0200
User-agent: Thunderbird 2.0.0.14 (Windows/20080421)

Henri Lesourd wrote:
Abdelrazak Younes wrote:

Of the user? A lot! I mean, IMO a user would prefer a complete app instead of a half baked one, even if it is not fully integrated with the system with bells and whistles. Recently we questioned ourself if it was better to have multiple version of the menubar depending of the platform. A Mac tailored menubar would indeed provide a better initial experience to the Mac user. But, and this a big *but*, we decided that it was better for user support to distribute the same menubar on all platforms.

It looks like one of the root causes of why you feel
it's difficult to support multiple toolkits is that
you are trying to design *too much fine-grained* APIs.

Hum well, the API you are describing below is *very fine-grained* :-), more details below.


The fact remains that I agree with you that supporting
multiplatform software is hard. But there are ways
to turn this easier by means of designing the APIs
carefully, especially: thru your API, you should
*not* try to give control on details which, as a
matter of fact, are platform-dependent.

Much of the API I see below is platform-dependent IMO.


Otherwise, you end up having to support the whole
functionality on multiple platforms, rather than
having to support only a wrapper on the many platforms
you want to target (which *is* feasible and not
too hard, if you do it well).

You seem to miss my point: those indirections caused by your encapsulation is not worth it. Maybe you think that you'll be able to factorize some code between frontend because a dialog is a dialog and a button is a button. But I am forecasting that the glue code necessary to fit into your defined API will be bigger than the toolkit code to define the dialog and the buttons.


Still, there remain hard cases, especially for
features you absolutely need, but are not well
standardized across toolkits, and thus are platform
dependent. A chief example of such features is
how to encapsulate the main loop of the underlying
GUI toolkit in a portable way.

And that's exactly why you should try to avoid it. We had a lot of problem managing the event loop in LyX; I cleaned up that so that the core doesn't know about the event loop, literally.


But we make it easy for the advanced user to modify his menubar at will. So a Mac menubar is possible without any compromission.

In my opinion, trying to give too much control to
the user is a mistake, or at least, it is something
which will easily cost you a lot of (neverending)
effort. I would rather advocate sketching the basics
of what you really need as precisely as possible,
then *stop* the work in providing more and more
details in your API.

I was only talking about a menu description file. This is not something you want to hard-code. Most users won't modify this file, only pretty advanced users do.


I am not sure. I had a look at the GUI API you are creating and I can tell you that this will prove inefficient because that's exactly how we did it with LyX. You are creating a set of virtual interface that can be implemented by the different frontend. In a way that means that the 'kernel' drives the 'frontend'. This is the wrong way, the 'frontend' should drives the core. Ideally, two frontends should not have anything in common, no virtual interface, no predefined way to launch a dialog or move the scrollbar. The 'frontend' should use the core typesetting function as a library. That's the change we did in LyX-1.6 and I can assure you that it's an awful lot simpler.

No: the reality is that designing a portable API (i.e., what
you call the "virtual interface") is *hard*. But if you do
it well, i.e., if you capture the real nature of what a widget
is, then you can succeed.

And your locking yourself in your portable API. Most of this portable API will need to be reimplemented by the frontend. This is what I called glue code, at application level, we are not (IMHO) in the toolkit API business.



Of course, if in the same time, you maintain irrealistic
demands as far as control on the details is concerned,
then you put yourself in a difficult situation.


Another point is that actually, the concrete situation
is a little bit more sophisticated than this in my Qt
port: as a matter of fact I had to design another, more
low-level API to encapsulate the underlying GUI, i.e.:

widgel *new_widgel(byte type,widgel *parent);
[...]
void widglib_finish();

Sorry but this looks to me like a lot of work for basically not much gain.

[...]
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 :-)

Thanks for sharing your thought,
Abdel.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]