Question about Linux Builder Requirements
A.C.T.
albrecht at act-net.com
Sun Apr 4 14:36:50 EDT 2004
Hi, John,
> I am not sure why you have responded to this since you have not even
> been able to run your stand-alones in Linux yet...were you basing your
> comments on general Linux experience, or just 'theory'?
sorry, I was trying to - eventually - narrow down the area where to look
for solutions for your problems, while mine remain unresolved. My
comments where based on my (limited) Linux experience and theory and the
will to help.
>>That may be related to Windows and MacOS using a different windowing
>>system than X, which is "client-server".
>
> No, it was related to a 'mouseMove' handler that just didn't work in Linux.
> I was able to work around it though...
Maybe because in a client/server architecture like X you do not get
every mouse move (which is handled on client side) if you (the
application, to be precise) do not ask for it, but only messages from
objects? That's what I meant: I tried to find an explanation for what
you experienced, which might have helped you in finding a workaround.
Fine that you do have a workaround!
>>I would expect the working directory to be the "Default Folder".
>
> No, it returns the current 'login' user folder (for me it is '/root'...it
> should be '/root/MetaCard/'). This was the same in Mandrake RedHat, KDE and
> Gnome.
I would expect the user's home directory TO BE HIS WORKING DIRECTORY,
naturally. So your "No" actually means "Yes" and it is the natural
behaviour of all UNIX flavors I know: Without setting a new working
directory you do get your home directory.
>>Unix (Linux) "loves" Spaces, but they have to be backslash-escaped if
>>you use shell tools.
>
>
> My comments are centered around the understanding that I am working from the
> RunRev environment...Linux itself may 'love' spaces, but the RunRev (MC 2.5
> engine) file dialog does not (returns an error). The only work around is to
> NOT have spaces in your file names...folder names with spaces works fine.
Ok, that is a hint for me (as soon as I have working Linux apps built
from Revolution) since my customers _do_ have spaces in filenames and
there is no way around having them spaces in their filenames. I will
have to find a way to either deal with that or forget using Revolution
on Linux completely - thanks for pointing this out.
>>[Support for TrueType] This surely isn't a problem of Revolution/RunRev:
>
> Yes, it definitely is. TrueType fonts that I have installed myself show up
> in other application like OpenOffice, Gimp, etc. (and some 'do' show up in
> the font menu for the RunRev/MC engine), but they have no affect on text in
> RunRev/MC other than 'italic' style (and 'italic' selects 'plain' for the
> TrueType font selected). They work fine in all other apps...
To my knowledge KDE (as an example) uses freetype. Is freetype used by
Revolution as well? Are there any environment variables to be set for
Revolution to do (necessary) font name translations? Qt (as an example)
is known to have such requirements, specific applications need to set
env parameters to "activate" their TrueType awareness.
My sentence above was targeted towards helping you tracking down the
source of the problem. It is not said that Revolution has got a problem
with TrueType, it is possible that you need to configure your system to
actually LET it use TrueType. If there is any information about how
Revolution accesses the system font rendering engine it should be more
easy to switch TrueType rendering on.
Other applications may "know" how to deal with the situation. There are
issues with TrueType that many "older" rendering engines cannot deal
with: TrueType fonts may use more space than their kerning tables tell
the application, which has lead to severe rendering problems in the
past. The advantages of TrueType (like antialiasing etc) is the
"benefit" from these issues. So a (possible, not necessarily correct)
explanation might be: TrueType rendering is switched off for "stability"
reasons and you have to switch it on manually.
>>It is possible that calls for font rendering inside the Revolution engine
>> is not up-to-date but would not call this a bug.
>
> I never called it a bug...
Again: Sorry, I simply tried to help tracking down where to look at, I
did not mean to "teach" you something.
Marc Albrecht
A.C.T. / level-2
Glinder Str. 2
27432 Ebersdorf
Deutschland
Tel. 04765-830060
Fax. 04765-830064
More information about the use-livecode
mailing list