[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Texmacs-dev] Re: Compiling TexMacs on OSX
From: |
Henri Lesourd |
Subject: |
Re: [Texmacs-dev] Re: Compiling TexMacs on OSX |
Date: |
Mon, 16 Jun 2008 15:16:27 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 |
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.
- Re: [Texmacs-dev] Compiling TexMacs on OSX, (continued)
- Re: [Texmacs-dev] Compiling TexMacs on OSX, Andreas Körner, 2008/06/09
- 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 <=
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Abdelrazak Younes, 2008/06/16
- 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