[Texmacs-dev] Re: Compiling TexMacs on OSX

[Henri Lesourd]

Abdelrazak Younes wrote:

> 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.
I don't think there are so many examples like
that (or either, you end up doing something
else than widgets).


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

Because you need them in the situations where
the widget can be moved and/or resized, of
course.

I don't see how you could do otherwise, in fact.


> FYI, docked widget can be undocked (by the user with his mouse) and 
> they can be transformed to drawer on Mac.
And why does this imply that you don't need methods
for moving and resizing it ?


> > A too much extreme use of object-oriented programming
> > blinds you, here.
>
>
> A too much extreme use of generic programming blinds you ;-)
I like this kind of blindness ;-)


> > > 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.
This is precisely because, as you say, there can be reuse,
than the API can in fact known more or less completely in
advance.


> > > 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.
Eh, you could look at my API and prove me wrong,
being sure of my case is not a guarantee of being
right. I simply tend to consider my point of view
as solid, because I had a look at alternatives,
but I don't know everything (otherwise there
would be no need for discussions, btw).


> > > 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 :-)
The "editor" widget is the one which needs programmability
on the side of the "canvas" widget, but still, we need the
other widgets, i.e. menubars, filechoosers, color chooser,
etc.

For assembling all these widgets in a generic way (e.g.,
we could describe the interface by means of a little XML
document), we need to define an API to wrap around the
GUI toolkit (currently: Qt and Cocoa).


> > 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.
I'm serious because in my experience, I repeatedly observed
how much object-oriented programming mindset leads teams
to waste their time and write not very reuseable code
which sooner or later must be refactored.

It's not a matter of philosophy: it's the matter of the fact
that the insane use of inheritance and of thinking by means
of hierarchies of classes has drawbacks and leads to inefficience.

Perhaps you don't really do that, by the 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.
Either everything is done by means of an interpreter, or
either I do not believe you, for otherwise, adding a new
request requires adding more C/C++ code somewhere. In such
a case, the communication protocol is not a real benefit,
for still, you need to recompile LyX. Or not ?

I'm OK with you on the side of the RPC, if you want RPC,
of course you must pack and unpack function calls.

But implementing a communication protocol just for avoiding
the API problem doesn't solves it, it just moves the
problem farther: you need to implement the functions
somewhere, thus there is an API somewhere, and on the
other hand, the problem of maintaining a public API
is not obviated, for now your protocol becomes the
public API: we are thus back to the starting point,
you need to be clever in designing the protocol,
otherwise you will have to break compatibility
later when devising the next versions.


> > 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?
This has nothing to do in the discussion: we are speaking
about defining an API for the GUI. In this respect, you
can quite well plan things in advance, because GUI component
design is a well-explored field. Thus, if you do things well
it's unlikely that you need to revolutionize your API for a
such well-defined thing. What can happen is that user requests
suggest new kinds of components, or the need for developing
other parts of LyX (in such cases it rather leads to *other*
APIs, not to changing the ones which exist for already well
defined parts of the software).

And yes, of course, you cannot predict all the new ideas
the users can bring. But this is besides the point.


> > 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...
Let's hope they did. As far as I remember, in 4.3.2,
some tricky hacks were still badly needed.


> > 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 :-)
These are choices which have consequences on the
architecture of your software.


> > 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.
TeXmacs is also a programmable editor, thus in our
case, plugins is a more important topic.


> > 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.
No, but if the language is extremely statically/compilation
time oriented, there are things you simply cannot do with
the standard/usual way.