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

[Henri Lesourd]

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.

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.

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).

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.

> 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 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.


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 free_widgel(widgel *w,bool b);
byte widgel_type(widgel *w);
word32 widgel_winId(widgel *w);
widgel *widgel_fromId(word32 id);
char *widgel_title(widgel *w);
void widgel_setTitle(widgel *obj,const char *title);
void widgel_setIcon(widgel *obj,const char *fpath);
void widgel_setShortcut(widgel *obj,const char *defn);
char *widgel_text(widgel *w);
void widgel_setText(widgel *obj,const char *text);
widgel *widgel_parent(widgel *w);
int widgel_nchilds(widgel *w);
widgel *widgel_child(widgel *w,int i);
void widgel_raz(widgel *w);
void widgel_add(widgel *parent,widgel *w);
int widgel_pos(widgel *w);
void widgel_set(widgel *parent,int pos,widgel *w);
void widgel_move(widgel *obj,int x,int y);
int widgel_x(widgel *w);
int widgel_y(widgel *w);
void widgel_resize(widgel *obj,int w,int h);
int widgel_width(widgel *obj);
int widgel_height(widgel *obj);
void widgel_scrollMove(widgel *obj,int x,int y);
int widgel_scrollX(widgel *w);
int widgel_scrollY(widgel *w);
void widgel_scrollResize(widgel *obj,int w,int h);
int widgel_scrollWidth(widgel *w);
int widgel_scrollHeight(widgel *w);
bool widgel_scrollHidden(widgel *w,int bar);
void widgel_show(widgel *obj);
void widgel_hide(widgel *obj);
bool widgel_hidden(widgel *obj);
void widgel_raise(widgel *w);
void widgel_lower(widgel *w);
void widgel_focus(widgel *obj);
void widgel_refresh(widgel *obj);
void widgel_setFlag(widgel *w,int f,bool b);


bool widglib_event_pending();
void widglib_wait_event();
void widglib_read_event(widgel **w,widgev **e);

bool widglib_finished();
widgel *widglib_start(int argc,char **argv,int threadit=1,int forkit=0);
void widglib_step();
void widglib_stop(widgel *win);
void widglib_exit();
void widglib_finish();


The API above is completely polymorphic, i.e., it
can be used to manipulate any type of widget, and
there are (and there will be) *no* other methods
added when we will enrich the library and add
other kinds of widgets.


It should also be noted that while being *very*
close to what any GUI toolkit should provide (in
such a way that implementing most of the functions
above is usually straightforward), the API above
does absolutely *NOT* depends on Qt: you could
wrap it easily around any other GUI toolkit,
and *this* very property of the API was the
hard point in designing it.

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.


> And you should not. But working with others is more fun and you will 
> learn more in the process than if you stay alone. For me, personally, 
> this opensource business is not about giving yourself but about having 
> fun and learning in a very selfish and egocentric way :-)
Granted.