[Top][All Lists]
[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.
- Re: [Texmacs-dev] Compiling TexMacs on OSX, (continued)
- Re: [Texmacs-dev] Compiling TexMacs on OSX, m . gubinelli, 2008/06/11
- Re: [Texmacs-dev] Compiling TexMacs on OSX, Andreas Körner, 2008/06/11
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Abdelrazak Younes, 2008/06/14
- Re: [Texmacs-dev] Re: Compiling TexMacs on OSX, Alvaro Tejero Cantero, 2008/06/14
- Re: [Texmacs-dev] Re: Compiling TexMacs on OSX, Henri Lesourd, 2008/06/15
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Abdelrazak Younes, 2008/06/16
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Henri Lesourd, 2008/06/16
- [Texmacs-dev] Re: Compiling TexMacs on OSX, m . gubinelli, 2008/06/14
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Abdelrazak Younes, 2008/06/15
- Re: [Texmacs-dev] Re: Compiling TexMacs on OSX, Henri Lesourd, 2008/06/16
- [Texmacs-dev] Re: Compiling TexMacs on OSX,
Abdelrazak Younes <=
- Re: [Texmacs-dev] Re: Compiling TexMacs on OSX, David Allouche, 2008/06/17
- Re: [Texmacs-dev] Re: Compiling TexMacs on OSX, Henri Lesourd, 2008/06/17
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Henri Lesourd, 2008/06/17
- Message not available
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Abdelrazak Younes, 2008/06/17
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Henri Lesourd, 2008/06/17
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Abdelrazak Younes, 2008/06/17
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Henri Lesourd, 2008/06/18
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Abdelrazak Younes, 2008/06/18
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Henri Lesourd, 2008/06/18
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Abdelrazak Younes, 2008/06/19