[Texmacs-dev] Re: Compiling TexMacs on OSX

[Abdelrazak Younes]

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

OK, I always forget that you are creating a GUI toolkit, not a word 
processor :-)

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

These things could help you saving some time to concentrate on the word 
processor thing but that's not your business, I understand that now.


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

This, some days, plus that, add a few more days, oh and that too, plus a 
bit of that... as I said, it's perfectly fine to educate yourself by 
reinventing these things if that interests you.

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

That's absolutely not true, I can dynamically link LyX with Qt C++ dlls 
without any problem. And LyX only loads the dlls that it needs at 
runtime depending of the mode of operation.

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

Any programming method can lead to spaghetti code and C-ish procedural 
method is not the least one in this category. The reality is that you 
should adapt the method to the problem at hand. C++ supports generic, OO 
and procedural programming hence is the perfect language for *me*. This 
is just a matter of style, a good C++ programmer will be a good C 
programmer and vice-versa; you can also do OO with C but you need a lot 
of glue code. So no, I don't bye this argument if you are a good 
programmer. Anyway, let's not engage in a language flame war :-)

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

We are not talking about the same thing here, see above the dll argument.

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

Interesting, certainly but in 2020 when you have finished with this it 
might loose a bit of its importance :-)

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

Oh I know Emacs (I prefer XEmacs), it's an excellent text editor and 
very good for programming. At least that was the case 15 years ago. I 
remember the good old time when I had to modify unintelligible lisp code 
in order to have good C++ highlighting... Now I use free version of MSVC 
and -blasphemy- I am pretty happy with it :-) Oh I also tried the 
various embedded apps in Emacs-the-OS (totally against the Unix 
philosophy) and, quite frankly, the special purpose apps was always more 
powerful and simpler to use with less occasion to fuck up everything. 
That is my personal experience... nothing more. Maybe many people still 
use the list apps within Emacs but I would be very surprised. But I am 
very sure that many people still use Emacs for its core competence 
namely source-code editing.

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

When you say "we" I am not sure you speak for a lot of people and you 
are very numerous in this way of thinking. Maybe you should ask the 
TeXmacs users (and some developers too I guess). Maybe they will tell 
you that they you that they first and foremost want a WYSIWYG scientific 
editor that has the same typesetting quality as TeX. Maybe they are not 
that much interested in writing documents that embeds dialogs and buttons.

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

Never said that it doesn't work. Please don't get me wrong, it is 
perfectly fine (and good) that you do the things that interest you 
personally. It is also perfectly fine that you create a full programming 
platform, a bit like XUL by the way. When you finish it, it will 
certainly be a very powerful application.


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

I don't want to dismiss your approach, I was just not aware of your more 
important goals with TeXmacs. I was just trying to tell you that, if it 
was me, I would concentrate on providing a good GUI that would help the 
user to use the excellent typesetting capabilities of TeXmacs, that's 
all. But you are the developer, so only you can decide what is your 
priority.

That was a fun discussion anyway, good luck and have fun with this 
project, this is certainly the most important thing :-)

Abdel.