Question about Linux Builder Requirements

[A.C.T.]

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