[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Texmacs-dev] Re: Compiling TexMacs on OSX
From: |
Abdelrazak Younes |
Subject: |
[Texmacs-dev] Re: Compiling TexMacs on OSX |
Date: |
Thu, 19 Jun 2008 09:11:15 +0200 |
User-agent: |
Thunderbird 2.0.0.14 (Windows/20080421) |
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.
- [Texmacs-dev] Re: Compiling TexMacs on OSX, (continued)
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Henri Lesourd, 2008/06/17
- Message not available
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Abdelrazak Younes, 2008/06/17
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Henri Lesourd, 2008/06/17
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Abdelrazak Younes, 2008/06/17
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Henri Lesourd, 2008/06/18
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Abdelrazak Younes, 2008/06/18
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Henri Lesourd, 2008/06/18
- [Texmacs-dev] Re: Compiling TexMacs on OSX,
Abdelrazak Younes <=
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Henri Lesourd, 2008/06/19
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Abdelrazak Younes, 2008/06/19
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Henri Lesourd, 2008/06/20
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Abdelrazak Younes, 2008/06/20
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Henri Lesourd, 2008/06/20
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Abdelrazak Younes, 2008/06/20
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Henri Lesourd, 2008/06/20
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Abdelrazak Younes, 2008/06/20
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Henri Lesourd, 2008/06/21
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Abdelrazak Younes, 2008/06/21