[Texmacs-dev] Re: Compiling TexMacs on OSX

[Abdelrazak Younes]

Henri Lesourd wrote:
> Abdelrazak Younes wrote:
>
> > > > 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.

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.


> > 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. I think we have a communication problem here... 
we should probably switch to French as nobody is reading us I guess :-)


> > > > 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).

Good, I was afraid that you would not accept alternatives.


> > 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).
Well if you use Qt, the interface can already be defined in an XML file, 
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. And my point again is 
that you should create a new toolkit if you want to do that and let 
Texmacs use this toolkit.


> 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 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. And I would also dare to say that 
the user doesn't care about dynamically loaded interface, he/she just 
want something to work.

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

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

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

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

Do you mean that the user can create widget with buttons, check boxes, 
etc via some kind of macro in the TeXmacs editor canvas?

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

My opinion: change the C++ code, recompile and release a new version. 
But I already said that :-)

Henri, I think I understand now better your position. But, from a 
pragmatic point of view, if you are interested in the evolution of 
Texmacs on the GUI side, you should reconsider it. But this is of course 
just a friendly advice, nothing more, nothing less.

Abdel.