[Texmacs-dev] Re: Compiling TexMacs on OSX

[Henri Lesourd]

Abdelrazak Younes wrote:

> Henri Lesourd wrote:
>
> > Because you need them in the situations where
> > the widget can be moved and/or resized, of
> > course.
>
>
> This is because you are creating a GUI toolkit of course. FYI, Dock 
> widgets and Mac Drawers _do_ move, it's just that Qt is responsible 
> for the movement, not the user.
Qt is responsable of the movement only when the widget
is docked. Otherwise, the user should be in control.


> > > 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 ?
>
>
> Because the size and position of such widget should and cannot change 
> in every possible ways. A vertical dock widget can be resized 
> vertically but not horizontally, it cannot move unless the user undock 
> it, etc. You will have to encapsulate all these behaviour in your 
> toolkit if you want to do the things well.
Absolutely not. As I said in a previous message, when
the state of the widget is such that the methods move()
and resize() do not apply, these methods just do nothing.

But still, when the widget is floating, you *need* the
methods (and as a whole, this subthread is uninteresting,
we are pinpointing trivialities, here).


> > 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).
>
> Well if you use Qt, the interface can already be defined in an XML file

Yes, but it's *their* XML file. Rather, we would in
fact simply use a toplevel TeXmacs document: thus we
don't need using one more (redundant) parser, thanks.

Once again, these kinds of "features" don't help,
because here, the otherwise quite talented Qt people
tend to force you in using their way. What I want
is control, and no redundancy in my software.


> , that's the ui file that the Qt designer is producing. Have a look at 
> the syntax, it's pretty well organized and clear. If you want 
> something that is loadable at runtime instead of using the Qt uic 
> compiler, you can have a look at XML syntax that KDE people are using 
> for their application. There are other alternatives that are cross 
> platform of course. This kind of things has already been done.

I want none of these alternatives, all these things
look like it would bloat the software rather than
helping.

Frankly, writing a simple XML parser is a matter of
some days and some dozens of kilobytes, I don't need
any "designer" to bloat my code.


And in any case, loading at runtime needs *compiling*
some C/C++ code in a DLL, if you want to be completely
general. To do this, you must proceed in a specific
way, namely, encapsulating your C++ classes behind
a C API, for otherwise, you cannot link the C++
without recompiling the whole application.

What you need is not use things as an external
tool, because for specific purposes, it doesn't
works: what you need is look at the details
and understand clearly the underlying mechanisms,
and what is necessary to use these. Once you
know that, writing the code is not that much
difficult.


> > 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.
>
>
> I always do programming with performance and efficiency in mind. Some 
> developer would tell you "design first, optimize later";

I don't speak about performance here: the problem with
object-oriented programming is that it very easily leads
to a sophisticated kind of spaghetti code.


> I think this is wrong, a good design should always take the 
> performance factor into account. Statically compiled interface are 
> faster than Dynamically loaded interface, as simple as that.

This is false.

Dynamically typed *languages* are slower. But whether
the code of the function you call has been statically
linked or dynamically loaded by means of dl_open(),
the timing is exactly the same.


> And I would also dare to say that the user doesn't care about 
> dynamically loaded interface, he/she just want something to work.
In the case of TeXmacs, things could be different,
for a user could be developing an application on
top of TeXmacs. In such a case, the ability to develop
your own Qt components, then dynamically loading them
inside TeXmacs (without the need of recompiling TeXmacs)
could be interesting, and even, important.


> > 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 ?
>
>
> Of course yes. But I don't see that as a limitation.

We differ here, as for me I consider this as a huge
limitation.


> This is open source, if the need arise for a new function, we add it, 
> we recompile and we release a new version, that's it.
It means that you don't consider LyX in the tradition
of emacs, i.e. as a platform that you can morph to
anything. Otherwise you would not say that.


> > 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.
>
> Backward compatibility is a decease that prevents any evolution! Just  
> kidding :-)
> More seriously, we do not change the formats and the protocol for 
> minor versions (1.5.x) but we change them extensively for major 
> versions (1.X). And we only ensure backward and forward conversion of 
> the file format, not the protocol. We document the change in protocol 
> in the Release notes, that's all.
Then you enjoy the benefits of more scriptability for
your software, but as far as the original question is
concerned (i.e.: better maintenability of APIs), you
get null benefit, it seems.


> > TeXmacs is also a programmable editor, thus in our
> > case, plugins is a more important topic.
>
>
> Do you mean that the user can create widget with buttons, check boxes, 
> etc via some kind of macro in the TeXmacs editor canvas?
What I meant is that the TeXmacs window (at the root
level) could be defined by a TeXmacs document and
that the user could also define and load new Qt widgets
without ever recompiling TeXmacs.

What I also meant is that once TeXmacs is started,
you should be able to run scripts inside it which
completely change the interface, create and destroy
widgets, move and resize, and/or detach widgets, etc.


> > No, but if the language is extremely statically/compilation
> > time oriented, there are things you simply cannot do with
> > the standard/usual way.
>
>
> My opinion: change the C++ code, recompile and release a new version. 
> But I already said that :-)
That's not what we need, we want something rather
like Javascript. What makes the problem tricky is
that still, the components are implemented in C++.


> But, from a pragmatic point of view, if you are interested in the 
> evolution of Texmacs on the GUI side, you should reconsider it.
Apart from not very clear arguments about the fact
that there are some "more complex" widgets, I don't
see really where my approach doesn't work.

In fact, you are not the first person I discussed
with to come to me with arguments like this: but
till now, nobody really came with a convincing
example to really dismiss my approach efficiently.