"Arnd Hanses" <[EMAIL PROTECTED]> writes:
| This is more or less what I want. It might even be better to have a
| default setup where libtool isn't involved at all, i.e. only
| --enable-shared would call libtool.
That complicates the Makefile.am's so if it is not needed I won't do
it.
| > Also, I am not going to work on making shared work on other archs
| >than ix86/Linux (and that already work). We will slowly move to have
| >better module/library api's and dependencies but do not expect much.
|
| As long as static linkage works...
|
| Well, in the old dll version I had to export some uninitialized
| globals, what I did not like.
Do you have a list of them? We should not have uninitialized globals.
| Nevertheless, cleaning up this structure
| would be great for all LyX platforms, I think, not only Linux. And I
| like very much the old idea of SMiyata: Put the whole LyX kernel, with
| the exception of main(), into shared modules. This would give us
| several instances (windows) of LyX without additional overhead and with
| crash protection in separate processes.
On most operating systems (eg. unix) you get that with statically
linked binaries too. Dynamic libs are only a gain when several
_different_ applications want to use the libs.
| * ditch completely fork() syscall: This is easy to implement for the
| syscalls class, did this already, I don't see a problem to port it to
| the new branch. This is certainly not a top priority, but as it is not
| so much work, I think I can do it easily.
agree, child processes should be made witht eh syscalls class.
| * ditch figinset.C: I could not make it work on my box, probably a
| problem of gs403, which I must use here. You use some forked workhorse
| process clones; this is not always guaranteed to work with emx a.out
| and is guaranteed not to work in a DLL. So: Reimplement this in a
| thread safe re-entrant way (protect variables and other resources
| against mutual competition, etc.), but do not call (i.e. select) the X
| server in the work horse at all; unfortunately, the emx select() call
| is not thread safe :-/.
There are other ways to do this when you use threads.
Notifiers f.ex.
You let the spawning thread block on a read from the Notifier Queue,
and the spawned threads will write a notify on the Notifier Queue,
this will wake up the spawning thread.
| I experienced crashes when using the
| _beginthread() work-horse. This is too difficult for me to implement,
| I'm afraid. Putting thew module into the exe is not an alternative:
| There are too many shared ressources, so this won't help.
|
| What about instead using a widely used and widely portable library,
| like 'IMLIB'??! Who knows more?
That is the idea. The idea is to have a InsetGraphics that requests a
pixmap given a filename.
InsetGraphics
^ |
| |
pixmap filename
| |
| v
ImageContainer
The ImageContainer is a module that knows how to create pixmaps out of
different image types. And we really don't care what method is used to
create the pixmaps, if is gs, IMLIB, toolkit native functions, or whatever.
(in the case of gs...we do it without letting it connect to the
Xserver)
The InsetGraphics knows about the display, ImageContaner does not.
I would like the ImageContainer to store the converted files on disk
in stead of in memory.
|
| >
| >btw. did you try --enable-shared on OS/2? How severly did it bomb?
|
| SMiyata recently reported his experiences here, he knows much better
| the OS intrinsics than I do. (Only used it with a much simpler thing
| than LyX and this was difficult enough. BTW: I just released 104/2,
| need a little pause; a friend even said I became a LyX maniac and this
| list with all the C++-stuff would spoil me completely ;-)
Ok, you can leave early this week.
Relax during the weekend, and come back next week :-)
| (who has been severely hit by this incurable LyX virus infection)
Good!
Lgb
