[Texmacs-dev] Re: Compiling TexMacs on OSX

[Abdelrazak Younes]

Henri Lesourd wrote:
> Abdelrazak Younes wrote:
>
>
> > It's even possible possible to have non-rectangular widget :-)
>
> Fine. If you are interested in those ones, it's
> great.

I am not. This was just an example.

> > By keeping the control of such things as widget placement and size 
> > you are limiting yourself to widget with windows.
>
> Absolutely not: in case I would need a widget which
> cannot be moved and/or resized, then the methods move()
> and resize() will do nothing, and that's all.

Then why defining these methods at all? FYI, docked widget can be 
undocked (by the user with his mouse) and they can be transformed to 
drawer on Mac.

> A too much extreme use of object-oriented programming
> blinds you, here.

A too much extreme use of generic programming blinds you ;-)


> > In essence, you are forcing the frontend API to a common denominator
>
> Exactly.
>
> In fact, I follow the sanity rules of UNIX, which is able
> to implement filesystems by means of only four main API
> calls: open, read, write, and close.
>
>
> Do you think that a filesystem is a much simpler beast
> than a GUI toolkit ? I don't.

Come on! These are two very fundamentally different things. A GUI is 
user bound and a filesystem is system bound. You can predict what a 
system requires, you simply cannot predict what the user will do with 
your GUI, the user is unpredictable :-). Reusing already proven GUI 
components to make the user interface smoother, simpler, easier to use, 
is common sense to me, this is not rocket science.

> > The frontend will just provide a canvas where the core can draw onto. 
> > A virtual interface to the painting operations will of course be needed.
> You should not forget to mention that there will
> also be an awful *LOT* of detailed design work
> for cloning the native look for each one of
> the platforms.

??? We try to avoid platform dependant code, that's what the 
cross-platform toolkit do for us. Of course, we have here and there some 
specificities but most are configurable at runtime. For example the Mac 
version has special handling of multiple windows but this is a runtime 
setting that can be set for all platforms.


> > I mean, unless you are a GUI toolkit expert yourself and you think 
> > you can do better... In this case you should simply say that you are 
> > implementing a simple GUI toolkit limited to dialogs and buttons on 
> > top of Qt :-)
>
> That's *exactly* what I am doing !
>
> The only supplementary (but important) point is
> that I claim that with my simple API, I can in
> fact wrap most of the existing Qt components.
>
> This latter is not a matter of opinion, it is
> a matter of fact: and I don't need more than
> this (and neither LyX, I'm pretty sure).

I am not going to argue since you are sure of your case.

> > That's how we do it in LyX, the only thing that the core knows about 
> > is the text canvas that we call the Work Area. the core doesn't know 
> > anymore about menubars, toolbars and dialogs. We are not 100% clean 
> > yet but coming close.
> This is exactly the same in TeXmacs: the core
> rendering engine only knows the drawing API
> and the canvas.
>
> But the core has nothing to do with the GUI,
> anyway: in fact, the core, i.e., the "editor"
> is one of the GUI components.

So you already have a clean "editor" and you insist on going through all 
this just for the pleasure of being sure that you control every aspect 
of your application down to the button click event? That looks like 
masochism to me :-)


> That's precisely my point from the beginning: break
> the mental barriers in your head, and stop thinking
> by means of this insane object-oriented approach
> which leads you to think *HIERARCHICAL*, by means
> of "specializing" and adding more and more methods
> for the purpose of implementing a more specific
> component.

Woa! It seems that you are very serious when you say that. The 
discussion is a bit too much philosophical at this point. As I said, 
even though I take pleasure in programming, this is not rocket science. 
It's perfectly fine with me that you use the Texmacs source code as an 
experimental platform for your programming theories but please don't say 
that pragmatic programming is worth nothing. "pragmatic programming" is 
to me the way to get the thing done in the most elegant way, not 
necessarily the one, unique, elegant way.

> > You can put in place a communication protocol for that kind of stuff. 
> > No need to encapsulate the GUI API. In LyX we just use what we call a 
> > function request which is an object that is understood by the core 
> > and the frontend.
>
> Then it's more complex and tedious to maintain, for
> no real benefit besides the hypothetic possibility
> of augmenting the API later.

Not much actually. And the real benefit is that, thanks to Function 
Requests, everything in LyX can be commanded by the user or an external 
programme via a pipe or socket based communication. You can find more 
information here if you are interested: http://wiki.lyx.org/LyX/LyxFunctions
I'll grant you that we probably have many functions that are not really 
needed but if a need arise for a new function, it's very easy to add, 
there is no API to augment as this is not about a programming API to 
begin with but about a command interface.

> Much better to know what you need in the first place.

I am repeating myself but you simply cannot predict all what the user 
needs. We have hundreds of user requests for LyX that we did not think 
of but are very valid requests that would improve the productivity. 
Should we just ignore them because well, the user doesn't know what he 
talks about?

> > But you could also really split the application in two process and 
> > use socket or pipe based communication between the two if you truly 
> > want to be Qt independent.
> That's the first solution I tried, and by the way, you
> can use my toolkit in such a multithreaded mode. But
> there is an overhead due to messaging and synchronization,
> and btw, this issue is quite orthogonal.

Right.

> Another point is that you still need a fine-grained
> control of the Qt event loop, because in order to
> be able to modify dynamically the widgets, you can
> only do it from inside a handler, thus in practice,
> because the function calls come from the other
> thread, you somehow need to stop the Qt event
> loop first (that's the kind of little b!@@#$t
> which is not explicitely said in the Qt documentation,
> but that's the way it is).

I think Qt has made some progress WRT multithread programming lately. 
But we are diverging from our subject...

> No, because:
>
> 1. I don't want to be forced to use C++ inheritance
>   in my code, and especially not directly from
>   a Qt class ;
>
> 2. I don't want to be forced to put all the code of
>   my event handlers into Qt handlers: what I want
>   is clean, Qt-independent messages that I can
>   simply read from my C code ;

I simply cannot answer that :-)

> Of course, I don't know if it will finally be
> done in TeXmacs, but the possibility of implementing
> and compiling a Qt component independently, and
> then loading it into TeXmacs without the need
> for recompiling TeXmacs is one of the important
> reasons which lead to this choice of wrapping Qt
> behind a C API.
>
> But perhaps you don't want to do this.

You mean for LyX? No I don't want to do that. There are thousands of 
more pressing needs than coding support for plugins.

> In any
> case, this little thought experiment reveals
> the limits of C++-based designs: if you use
> C++ without specific care, such designs are
> usually very static.

Design evolve, this is open source code, nothing is set in stone, code 
will be rewritten. IOW you don't have to design everything perfectly 
from the very beginning.

Abdel.