[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: |
Wed, 18 Jun 2008 00:58:07 +0200 |
User-agent: |
Thunderbird 2.0.0.14 (Windows/20080421) |
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.
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? FYI, docked widget can be
undocked (by the user with his mouse) and they can be transformed to
drawer on Mac.
A too much extreme use of object-oriented programming
blinds you, here.
A too much extreme use of generic programming blinds you ;-)
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.
The frontend will just provide a canvas where the core can draw onto.
A virtual interface to the painting operations will of course be needed.
You should not forget to mention that there will
also be an awful *LOT* of detailed design work
for cloning the native look for each one of
the platforms.
??? We try to avoid platform dependant code, that's what the
cross-platform toolkit do for us. Of course, we have here and there some
specificities but most are configurable at runtime. For example the Mac
version has special handling of multiple windows but this is a runtime
setting that can be set for all platforms.
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.
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 :-)
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.
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.
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?
But you could also really split the application in two process and
use socket or pipe based communication between the two if you truly
want to be Qt independent.
That's the first solution I tried, and by the way, you
can use my toolkit in such a multithreaded mode. But
there is an overhead due to messaging and synchronization,
and btw, this issue is quite orthogonal.
Right.
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...
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 :-)
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.
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.
Abdel.
- [Texmacs-dev] Re: Compiling TexMacs on OSX, (continued)
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Henri Lesourd, 2008/06/16
- [Texmacs-dev] Re: Compiling TexMacs on OSX, m . gubinelli, 2008/06/14
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Abdelrazak Younes, 2008/06/15
- Re: [Texmacs-dev] Re: Compiling TexMacs on OSX, Henri Lesourd, 2008/06/16
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Abdelrazak Younes, 2008/06/16
- Re: [Texmacs-dev] Re: Compiling TexMacs on OSX, David Allouche, 2008/06/17
- Re: [Texmacs-dev] Re: Compiling TexMacs on OSX, Henri Lesourd, 2008/06/17
- [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 <=
- [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, 2008/06/19
- [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