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. _______________________________________________ Texmacs-dev mailing list Texmacs-dev@gnu.org http://lists.gnu.org/mailman/listinfo/texmacs-dev
