Re: Linux installation

2007-04-09 Thread Rishi Viner
On Saturday 07 April 2007 09:14, Richard Gaskin wrote:
> I'm aiming to write my own.  So what I'm looking for is info on what
> each of the window managers (KDE, Gnome -- other popular ones?) requires
> for an app to:
>
> - Set up document file type associations
> - Assign icons for the app and the documents
> - Add shortcuts to the Start menu

KDE filesystem hierarchy:
http://techbase.kde.org/SysAdmin/KDE_Filesystem_Hierarchy

KDE development tutorials:
http://techbase.kde.org/Development/Tutorials

Freedesktop.org Specifications:
http://freedesktop.org/wiki/Specifications
(icons, menus applinks etc)

The KDE Kmenu follows this specification:
http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html

A bunch of links on standards and documentation here:
http://vlug.org/linux/links/Documentation/Standards/index.html

-- 
Rishi 
--
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2007-04-07 Thread Bob Warren

Richard wrote:

>Thanks for the info, Bob. But rather than using an existing installer 
I'm aiming to write my own. So what I'm looking for is info on what each 
of the window managers (KDE, Gnome -- other popular ones?) requires for 
an app to: - Set up document file type associations - Assign icons for 
the app and the documents - Add shortcuts to the Start menu



Wow! I bow to greater courage!
There are quite a few clever people in this world, but I'm not one of 
them, so I'll let the more technically-minded colleagues help if they can.
For my own applications at present (which are surely different in their 
demands to yours), I'm very happy to go in the other direction: a simple 
folder on the Desktop and end of story! No "Registry", no setup, nothing 
in the menus, a simple manual operation for file/app associations if 
necessary, and no hassle.


However, if you manage to make headway in your attempt, I'm sure that 
there will be many people who appreciate it.


For ideas on the general approach required to do the things you want, 
you might like to see how it is done (albeit not 100% successfully yet) 
in Gambas. If the IDE is not installed, all Gambas progs require a 
setup. "Standalones" (as in Rev and Rebol for example) cannot be 
produced in Gambas, so the production of a setup (which in Gambas is 
achieved through the IDE itself) becomes essential.


Bob



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2007-04-06 Thread Richard Gaskin

Bob Warren wrote:
I can't give you any details, but I might have a tip that leads you in 
the right direction. This year, for the first time, my wife did our 
income tax declarations using Linux, and as you know, Linux has been 
officially adopted by the Brazilian government. The software was 
installed using InstallShield, and it was very impressive.


You might also like to look at the installer used by Xara which is also 
very impressive, though this might be their own rather than a 
commercially-available installer (I can't quite remember).


Thanks for the info, Bob.  But rather than using an existing installer 
I'm aiming to write my own.  So what I'm looking for is info on what 
each of the window managers (KDE, Gnome -- other popular ones?) requires 
for an app to:


- Set up document file type associations
- Assign icons for the app and the documents
- Add shortcuts to the Start menu


--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-06-08 Thread Mark Wieder
Bob-

Thursday, June 8, 2006, 12:43:20 AM, you wrote:

> So that neither of us need to repeat ourselves:

> I have run into an RB problem! It is not a Rev problem!

Point taken. I think we're arguing the same issue from the same point
of view, just in different words, so I'll back out. I don't feel
either defensive or antagonistic on the subject, and I appreciate the
work you've put into trying to come up with something workable. It
would be nice if all the built-in rev commands worked in linux the way
they're supposed to, and I don't have a 100% good way to deal with the
specialFolder either.

-- 
-Mark Wieder
 [EMAIL PROTECTED]

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-06-08 Thread Bob Warren
Sorry about the spelling mistakes (bugs!). I thought that my picture was 
straight, but now I see that it is crooked. No sleep for me tonight.


Bob

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-06-08 Thread Bob Warren

Mark Wieder wrote:
>
Whoa! That's taking things a bit personally there. You *did* ask if I
was getting tired of this thread, right? I never said I was getting
tired of *you*. Or did you not really mean to offer that option?



First of all, if ever I meet you, I will buy you that round of drinks 
together with the other great guys on this List. What we have here is a 
gross misunderstanding. I would have preferred to finally have a good 
laugh and to change the subject, but since you have now resumed the 
thread I am bound to answer.


You had already contacted me off-list and told me that the discussion 
was OT: "not really rev stuff". On-list, you later said "It's not quite 
OT, since it does have to do with building linux standalones". In fact, 
my discussion has not deviated from the question of Linux installation 
for one minute as far as I can see, so the implication of "OT" is not 
accurate in my opinion. People very often say this when they really 
disagree strongly and they want to censure the person speaking or 
writing, but they don't have the courage to say it directly. Could it be 
because I had the audacity to attempt solve my Rev problem using 
RealBasic, and worse still, discuss this on the UR-List? All I want to 
do is to be able to write programs in Linux, which I cannot do properly 
in Rev at the moment. Rev for 2.6.1 for Linux is too incomplete and 
unstable for use - at least on my machine - and even Metacard suffers 
from engine problems which prevent me using it in Ubuntu Linux. Much of 
my discussion has centred around the crucial specialFolderPath function, 
which as you know has not been implemented in Linux. All I wanted to do 
was to find a substitute, and although I failed, the spinoff was highly 
interesting, except to you it seems. Part of the problem perhaps is that 
I have too much time on my hands, without the slightest sign of an ETA 
for Rev Linux 2.7.


In reply to your post, I'll do some clipping, but please don't take this 
as being unfriendly as it can sometimes imply. It's just a convenient 
was of answering what you have said.


>>You *did* ask if I was getting tired of this thread, right?

If a woman asked you "Am I ugly?" and she looks like the back of a 
horse, would you simply and seriously say "Yes"? Of course you wouldn't. 
You'd find some compromise between respecting the truth and avoiding 
hurting her feelings, e.g. "Well, I'm not sure whether or not you would 
win the Miss World beauty contest, but I think you're nice". Or another 
way of solving the problem if you know her well enough would be to say 
"Yeah, you look like the back of a horse", which translated means "You 
should know better than to ask me questions like that, so please don't". 
In my previous post I was anxious that perhaps I was rattling on a bit 
and in danger of trying some people's patience. I was anxious not to do 
that, or at least to be forgiven for it. Your "I am tired of this 
thread" is as shocking as the blunt "Yes" illustrated above.


>>Basically I *am* getting tired of repeating myself

Another example of the above. But since you mention it, so am I.

>>I think what you've run into is a RB problem, not a runrev
problem.

Not only are you preaching to the converted, I was the one to do the 
converting! And that's ironic! What on earth has given you the fixed 
idea that I didn't understand that? Worse still, Jacque seems to have 
picked up your idea and also got the impression that I didn't understand 
my own thesis! I am not going to spend more time analysing it here, but 
it dawned on me the very moment that you told me that the RB application 
did not run on your Kubuntu. What happened was this. I have tried using 
for the first time my free Linux edition of Standard RealBasic. When you 
save an "application" as they put it, the only thing in the "Build 
Settings" is the name of the OS. Different to Rev, I could find no 
provision for including libraries, etc. I first assumed that my 
application was a "standalone", but when I saw that it failed on your 
Kubuntu I concluded that it was simply an "executable" requiring OS 
libraries much in the manner of a Windows ".EXE" that needed a setup. I 
therefore abandoned this "application" immediately and had no intention 
of further recommending its use. I thought this was clear, but it seems 
not. Could it also be that you have not always appreciated the 
significant difference between "RR" and "RB" in my posts? Of course it 
is an RB problem. As for it being a RunRev problem, far from it. As I've 
said before, if my diagnosis of the RB limitation is correct, the Rev 
"standalones" are infinitely better, and I have NEVER encountered a Rev 
standalone that crashes (because of lack of libraries or any other 
reason) on any of the Linux distros I have tried.


So that neither of us need to repeat ourselves:

I have run into an RB problem! It is not a Rev problem!

All the best,
Bob



__

Re: Linux installation

2006-06-07 Thread Mark Wieder
Bob-

Wednesday, June 7, 2006, 9:41:37 AM, you wrote:

> Wow! Would someone like to tell me what I said or did to deserve that?

Whoa! That's taking things a bit personally there. You *did* ask if I
was getting tired of this thread, right? I never said I was getting
tired of *you*. Or did you not really mean to offer that option?

Basically I *am* getting tired of repeating myself, but I'll do it
once again: I think what you've run into is a RB problem, not a runrev
problem. If they're going to require that the GIMP libraries be
installed (and a particular version at that) then their code won't run
without those libraries. Read Jacque's response about OS resources.

This isn't particularly a linux problem, or a runrev problem, or even
a RealBasic problem - it's a design issue. It's no different from you
writing an application that requires the BobWarrenSpecialLibrary
module, and then it won't run without that module being present.

-- 
-Mark Wieder
 [EMAIL PROTECTED]

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-06-07 Thread Bob Warren

Jacqueline Landman Gay:
>
I don't think you understand how truly intertwined all applications are
with the OS they run on. It is okay that they do that. The only other
alternative would be for you to have to write all your own routines to
do all the above and more -- which apparently lots of Linux people have
decided to do, giving you the headaches you started out with at the
beginning of this thread.

Thanks very much for your truly marvellous explanation Jacque. I accept 
it. And just to prove the thesis in practice, would someone using a very 
different Linux distro to mine (Ubuntu, Debian, Gnome), say Red Hat or 
something, be kind enough to download my file/picture chooser widget 
standalones from:-


http://www.howsoft.com/runrev/stacks.htm

- in the hope that they do not work. If they do work by any chance, it 
is likely that icons for the CD-Rom and Floppy Diskette drives will not 
appear at the top, but apart from that everything should be normal. 
Please do not fail to let me know when these (Linux!) standalones fail 
to run successfully under any distro.


Thanks again, Jacque!

Regards,
Bob

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-06-07 Thread Bob Warren
Just for the record, Message 22 of the U-R Digest Vol 33, Issue 6 (4th 
June) makes it absolutely clear that:


1) The first 5 RB functions for deducing Linux system paths are 
unnecessary in Rev.


2) The last 3 functions are too unreliable for use.

Therefore, neither a GUI not a console application in RB would do the 
job. It is obvious that the idea was being abandoned.


On top of that, it has been established subsequently that these 8 
functions are insufficient.


Furthermore, what also becomes interestingly clear is that although RR 
standalones may or may not be 100% what they profess to be by their 
denomination, they appear to be far superior to RealBasic "Applications" 
which, as far as I can see would certainly require a real "setup" to 
make them work reliably. However, interesting though it is, that is a 
subject I do not intend to elaborate on here.


Bob

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-06-07 Thread Bob Warren

Mark Wieder wrote:
>
Yes, I'm getting a bit tired of this thread. It's not quite OT, since
it does have to do with building linux standalones, but apparently
what I've been saying to you hasn't been getting through. I'll try one
more time and that's all I'll have to say on this thread.
-
Wow! Would someone like to tell me what I said or did to deserve that?
I know I have defined myself as a "natural dummy", but there's no need 
to take it too literally. Dummies have their uses, which you are 
probably too young and inexperienced to appreciate.


Respectfully, Mark, is that really the way to encourage participation on 
this List?


> apparently what I've been saying to you hasn't been getting through.

Ditto.

There is nothing in your last e-mail that I didn't know already - way 
back. We all have difficulties in comprehension sometimes, and you are 
no exception.


But since other colleagues have shown a very different attitude in order 
to clarify these issues, and they have done an exceptionally good job, I 
am satisfied.


>that's all I'll have to say on this thread.

Problem solved.

Regards,
Bob


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-06-06 Thread J. Landman Gay

Bob Warren wrote:


These are my definitions, which you might like to challenge as being 
inappropriate:


1. An "executable" (e.g. a file produced by VB in Windows) is not a 
program, it's half a program. Nor is it executable. It finds its other 
half in the operating system it is running under (in the form of 
libraries), and when the 2 halves are put together, it can do something.


2. A "standalone" is a whole program, not half. It does not refer to any 
libraries at all in the runtime operating system**, and can be executed 
directly.


There are no programs that function as you describe in #2, on any 
operating system, written by any development platform.




[** except perhaps totally invariable ones - if such a thing exists??]

What Jacque seems to be trying to tell me is that in spite of the 
denomination, Rev "standalones" for Linux are not pure. They mainly have 
the characteristics of the 2nd category, but they have some of the 
characteristics of the 1st.


No, they are mainly like the first category. All 
applications/executables/standalones are like #1. I can't think of a 
single exception. They *all* rely on libraries embedded in the OS.


What's an OS? It is a series of libraries and resources available for 
common use by any program. The existence of common libraries ensures 
that all execuatables will look fairly similar and have similar 
behaviors. This is considerd desirable. It gives consistency to the user 
experience. All modern applications rely on them.


All Mac/Windows/Linux applications are the same regardless of whether 
they run with Revolution's engine or something else. You don't want to 
have to program your own window manager each time you create a program, 
or your own file I/O, or all the other thousands of interactions that an 
operating system provides for you with a single call. That's the whole 
purpose of an operating system. Your program asks it for data and it 
hands it back, or it draws a window for  you, or it manages data flowing 
through a socket. Your program just makes the calls that ask it to do 
those things.


There is no such thing as a "standalone" as you have defined it on any 
OS. All programs rely on system libraries.




Although this does not seem to fit in with an ideal situation, is it 
certainly true in Linux? Can anyone give me any examples of libraries in 
the OS certainly used at runtime by all Rev Linux programs?


Rev (or any other engine) on any platform needs the OS to execute 
thousands of commands and interactions. You need the OS libraries to:


read/write files or get a file listing
draw a window in any of several styles
manage menus
track and report the mouse position
recognize and report keyboard input
keep track of the time and date (seconds, ticks, date formats)
recognize mounted drives
work with networked drives and files
resolve aliases
do math operations
display color data
communicate with printer drivers and manage the print queue
translate and generate sounds
play multimedia (movies, music)
interact with COM and serial ports
display program icons
and on and on and on...


And if Rev 
does use such libraries in its "impure" standalones, is there any chance 
that either Rev will not find them in a particular distro or that they 
become outdated?


They aren't "impure". They are standard applications that act exactly 
like any other. Sometimes system libraries do become outdated. Every 
time a new OS is released on any platform, all applications that run on 
that OS usually have to be rewritten. Note that Runtime just released a 
new version to support Mac on Intel machines, for example. The Linux 
libraries also change; there have been several updates over the years to 
support those changes. When Windows releases Vista you will see another 
new update to support those changed libraries. It is the nature of 
software development.


I don't think you understand how truly intertwined all applications are 
with the OS they run on. It is okay that they do that. The only other 
alternative would be for you to have to write all your own routines to 
do all the above and more -- which apparently lots of Linux people have 
decided to do, giving you the headaches you started out with at the 
beginning of this thread.


--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-06-06 Thread Richard Gaskin

Bob Warren wrote:

1. An "executable" (e.g. a file produced by VB in Windows) is not a 
program, it's half a program. Nor is it executable. It finds its other 
half in the operating system it is running under (in the form of 
libraries), and when the 2 halves are put together, it can do something.


This is way OT, but folks here who enjoy what is usually a true 
standalone may get a kick out of what ToolBook makes as an executable: 
it adds only the tiniest stub of code to the stack file to help it find 
a collection of DLLs strewn all over three or more directories across 
the user's system.


Given this complex hodge podge, the boot sequence is so complicated that 
as of v6 it was not in the docs that came with the product.  I had to 
trace it out once for a project, and when I was done I submitted my 
summary to Asymetrix tech support who thanked me for what they described 
as the first time their complex boot sequence had been documented.


I'll take a self-contained executable file any day. :)

When I described my apps' structure to my VB developer friends, they 
almost fall out of their chair with disbelief at its simplicity and ease 
of installation (how many millions of hours are wasted each year 
resolving DLL conflicts among apps built with VB?).



2. A "standalone" is a whole program, not half. It does not refer to any 
libraries at all in the runtime operating system**, and can be executed 
directly.


[** except perhaps totally invariable ones - if such a thing exists??]

What Jacque seems to be trying to tell me is that in spite of the 
denomination, Rev "standalones" for Linux are not pure. They mainly have 
the characteristics of the 2nd category, but they have some of the 
characteristics of the 1st.


Although this does not seem to fit in with an ideal situation, is it 
certainly true in Linux?


This may be because the Linux GUI experience isn't an actual "thing", 
but really a collection of many different things, chiefly the kernel and 
the window manager.  KDE isn't Linux, Gnome isn't Linux, and KDE and 
Gnome use different APIs.


So while adding a GUI layer on top of Linux can provide a reasonably 
satisfying GUI, Linux itself is not a GUI per se, with the GUI being 
handled by these window managers delivered by different teams.


In contrast, while Apple's OS X is a window manager that rides on top of 
BSD, the vendor has assumed responsibility for integrating the two into 
a single cohesive experience.


If you take away the Finder and all the Aqua support from OS X, and 
allow anyone to make any number of alternative GUIs, OS X would provide 
the same level of confusion and fragmentation in the market, and 
developers would have as much difficulty delivering consistent 
appearances as they have with Linux.


I agree that it would be desirable for RunRev to come up with a scheme 
to have native appearances on all of the various incompatable Linux 
window managers, but it's not a simple task until those development 
teams start prioritizing Linux adoption higher than they value market 
fragmentation.


Admittedly this does raise a philosophical question of what constitutes 
"self contained" when it comes to Linux executables, but I'm not sure I 
would place any blame solely on RunRev, esp. given that RB has related 
issues.  It seems more fair to chalk it up to the inherently fragmented 
nature of GUI Linux.


--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-06-06 Thread Bob Warren
Sorry, but I'm still struggling with what Jacque has tried to tell me, 
which goes to prove how greatly related motivation and perception can 
be. There's a picture on my living-room wall, and if it's not straight I 
cannot sleep at night.


These are my definitions, which you might like to challenge as being 
inappropriate:


1. An "executable" (e.g. a file produced by VB in Windows) is not a 
program, it's half a program. Nor is it executable. It finds its other 
half in the operating system it is running under (in the form of 
libraries), and when the 2 halves are put together, it can do something.


2. A "standalone" is a whole program, not half. It does not refer to any 
libraries at all in the runtime operating system**, and can be executed 
directly.


[** except perhaps totally invariable ones - if such a thing exists??]

What Jacque seems to be trying to tell me is that in spite of the 
denomination, Rev "standalones" for Linux are not pure. They mainly have 
the characteristics of the 2nd category, but they have some of the 
characteristics of the 1st.


Although this does not seem to fit in with an ideal situation, is it 
certainly true in Linux? Can anyone give me any examples of libraries in 
the OS certainly used at runtime by all Rev Linux programs? And if Rev 
does use such libraries in its "impure" standalones, is there any chance 
that either Rev will not find them in a particular distro or that they 
become outdated?


Hoping for your patience and the benefits of your experience.

Bob

P.S. Interestingly, RB refers to "Applications" rather than 
"Standalones" as RR does.



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-06-06 Thread Richard Gaskin

Mark Wieder wrote:


The problem lies with that RB thing you created to return the folder
locations, and in particular with the fact that it's relying on the
GIMP toolkit libraries for some GUI presentations. Not knowing any
more details about what you did there I can't comment further on it.
But it WILL NOT RUN on any linux system that does not have the gtk
installed. Gnome by definition uses these libraries. Kde does not.

...

As I see it, there is no problem with creating a runrev standalone (or
executable, or whatever you want to call it) that runs on any flavor
of linux. The problem with your folder app is a problem with RealBasic
relying on the presence of the GIMP libraries for its GUI.


This is a problem I wouldn't mind having, but on balance it's noteworthy 
that KDE doesn't use GTK by default.


One issue with Rev on Linux is appearances -- it looks great, provided 
you like Motif. ;)


But seriously, how many people under 30 have ever seen Motif?

It might be a simple matter to just say "Let's use GTK", but if KDE 
doesn't use it then where would we be?


I suppose the upside is that KDE looks so much like Win 95 that setting 
Rev's lookAndFeel to "Win95" looks almost native there. :)


But of course that's a kludge, and it doesn't help those who would like 
to make one standalone for all x86 Linuxes.


So what's to be done?

It would be great if RunRev were to deliver an engine that took care of 
all of the window manager issues smoothly and easily for us, but on the 
other hand I'm pretty certain I wouldn't want them to take time away 
from XP enhancements -- and soon Vista as well, which is a much bigger 
undertaking (see the Vista User Experience Guidelines at 
 
-- it's almost as big a change as Mac's Platinum to Aqua).


Given Linux' desktop marketshare, and the complexity of Vista's Glass 
compositing/UI, if I were Mark Waddingham I'd find it hard to take time 
away from the latter for the former.


Is there any simpler approach RR could use to get native appearances on 
all Linux window managers?


Better still, any hope that we could lobby the window manager 
development teams to migrate toward a common API?


--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-06-06 Thread J. Landman Gay

Bob Warren wrote:

Thanks Jacque. If what you say is strongly true, then that's a sad day 
for Rev Linux users, since there is not one Linux but hundreds. But 
since I need to be a bit more optimistic, let me try another definition:


"The output program from Rev is as 'standalone' as the Rev development 
environment itself. If the Rev IDE runs on your particular flavour of 
Linux, then so will your standalones." [True or false in your opinion?]


Probably true, though it may depend on what your standalone does. But in 
general, I'd say yes.




The definition above simply refers to whether the program executes or 
crashes. I'm not sure what you meant by "certain features of the OS", 


The engine calls on the OS and its hardware to access or draw various 
components and features. If you don't have a window manager, you won't 
get any windows. If you don't have a sound card, you can't beep. And so 
forth. Every machine will be different.



So now I'll try a 2nd part of the definition:

"If you transfer your standalone program to another flavour of Linux, it 
will not crash upon intitialization. However, if your program attempts 
to access HD or network paths that are differently placed in the runtime 
environment, and appropriate error routines are not included, this might 
cause your standalone to crash." [True or false in your opinion?]


I don't think "crash" is the right word. Sometimes it may, sometimes it 
won't. Depends on what you are trying to do and how good your error 
checking is. As for the network and file paths, again, that will depend 
on the installation. You are correct that various flavors of Linux will 
have different requirements. Every machine will be different because 
Linux users can install components they want and omit others. You have 
no control over that. If a library your software depends on is missing, 
you'll have to ask the user to install it.


Trying to sum up a little on what has come out of this thread regarding 
the obtaining of fundamental Linux system info, I would like to point 
out that the apparently useful suite of functions provided by RB is 
insufficent, even if it were failproof and always correctly identified 
all 8 HD paths. A good example is the problem I mentioned above. If you 
want to use CD-Rom or Floppy Diskette drives in your program, they have 
to be "mounted" and you need to discover where in the file system this 
can be done. And what would I do in #2 of my file/picture chooser 
widgets if I wanted to access local network drives?


How about just asking the user to select the path via "answer folder"? 
Then store it for future reference.


--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-06-06 Thread Mark Wieder
Bob-

Monday, June 5, 2006, 4:24:01 PM, you wrote:

> I have just conducted 2 experiments using Rev standalone programs that
> were created in Ubuntu:

> 1. My Picture Chooser Widget
> (see http://www.howsoft.com/runrev/stacks.htm)

> 2. A new app consisting of a window and all the script/data base 
> support libraries available in the standalone settings

> They both ran perfectly in Kubuntu Live.

> Apart from possibly including external libraries (which I presume is the
> aim of the "externals" folder now accompanying Rev standalones), do you
> have any other type of Rev standalone you think is worth testing? If so,
> please send me the stack from Kubuntu and I'll try making a standalone
> in Ubuntu and running it in Kubuntu, or if you prefer, send me a 
> standalone from Kubuntu and I'll se whether it runs OK in Ubuntu, or
> none of the above if you are already fed up with this thread!!.

Yes, I'm getting a bit tired of this thread. It's not quite OT, since
it does have to do with building linux standalones, but apparently
what I've been saying to you hasn't been getting through. I'll try one
more time and that's all I'll have to say on this thread.



I have no doubt that the two standalones you created ran fine on the
Kubuntu live CD. I'm sure they would run fine on my installed system
as well. If they didn't then there would be serious problems creating
standalones for linux systems. I also have no doubt that I could boot
a Ubuntu live CD and run your app without problems.

The problem lies with that RB thing you created to return the folder
locations, and in particular with the fact that it's relying on the
GIMP toolkit libraries for some GUI presentations. Not knowing any
more details about what you did there I can't comment further on it.
But it WILL NOT RUN on any linux system that does not have the gtk
installed. Gnome by definition uses these libraries. Kde does not.

I seriously doubt that your folder app will run on your Kubuntu live
CD. I notice it's not on the list of apps you tested.

I could install the gtk (and I will as soon as I have a need to do
some serious graphics on my Kubuntu box) and then the problem will be
resolved. For my box, not for kde in general. Your RGB app should also
run properly on any linux system that has the libraries installed.
This is a development system for me, so I didn't install a bunch of
bloat I didn't need. For right now, that includes GIMP.

As I see it, there is no problem with creating a runrev standalone (or
executable, or whatever you want to call it) that runs on any flavor
of linux. The problem with your folder app is a problem with RealBasic
relying on the presence of the GIMP libraries for its GUI. As long as
it's clear that the app will only run on a kde box if the libraries
are installed, then that shouldn't be an issue. If you're going to
require certain libraries be present for your app to run, then you
should either a) include them, b) list them as requirements, or c)
test for their presence when your app starts up.

-- 
-Mark Wieder
 [EMAIL PROTECTED]

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-06-06 Thread Bob Warren

J. Landman Gay wrote:
>
In HyperCard, a standalone simply meant that the engine was embedded 
into the file on disk. And that is pretty much what Rev does too.


Revolution extends the process a bit by embedding as many resources from
the IDE as it can (script and image libraries, mostly,) but
"standalones" still depend heavily on certain features of the OS. If you
think of them as "executables" you will probably be more on-track.

-
Thanks Jacque. If what you say is strongly true, then that's a sad day 
for Rev Linux users, since there is not one Linux but hundreds. But 
since I need to be a bit more optimistic, let me try another definition:


"The output program from Rev is as 'standalone' as the Rev development 
environment itself. If the Rev IDE runs on your particular flavour of 
Linux, then so will your standalones." [True or false in your opinion?]


The definition above simply refers to whether the program executes or 
crashes. I'm not sure what you meant by "certain features of the OS", 
but when I wrote my first Linux programs (File/Picture Chooser Widgets: 
see http://www.howsoft.com/runrev/stacks.htm) I immediately came up 
against a lack of information about the file system, which has largely 
been the subject of this thread. Consequently - and this is only an 
example of what you might be talking about - although my widgets can 
successfully mount the CD-Rom and Floppy Diskette drives in Ubuntu Linux 
(Gnome) as they were designed to do, if you run the same widgets in 
Kubuntu Linux (KDE) the drives cannot be mounted using the same HD paths 
to obtain the necessary information. Nevertheless, this does not prevent 
my widgets from 'running'.


So now I'll try a 2nd part of the definition:

"If you transfer your standalone program to another flavour of Linux, it 
will not crash upon intitialization. However, if your program attempts 
to access HD or network paths that are differently placed in the runtime 
environment, and appropriate error routines are not included, this might 
cause your standalone to crash." [True or false in your opinion?]


Quite possibly, you will confirm the first part of the definition 
affirmatively. Regarding the 2nd part of the definition, you might tell 
me that you have insufficient experience of Linux to give a clear 
answer, particularly in relation to the first sentence. Am I right?

Or am I talking out of my hat?

Trying to sum up a little on what has come out of this thread regarding 
the obtaining of fundamental Linux system info, I would like to point 
out that the apparently useful suite of functions provided by RB is 
insufficent, even if it were failproof and always correctly identified 
all 8 HD paths. A good example is the problem I mentioned above. If you 
want to use CD-Rom or Floppy Diskette drives in your program, they have 
to be "mounted" and you need to discover where in the file system this 
can be done. And what would I do in #2 of my file/picture chooser 
widgets if I wanted to access local network drives? I have not even 
begun to discover how to do this for the distro I am using, let alone 
other distros. And what about if my program needs specific information 
about the distro it is running on? To know that the "platform" is 
"Linux" doesn't help very much. I need to know that it is "Ubuntu" for 
example, that the Gnome rather than the KDE interface is in use, that 
this is a Debian-based rather than a Red Hat-based distro, etc., etc.


Until more uniformity is established in Linux, or until Rev itself can 
be of much more help in establishing fundamental distro information, it 
seems that the ordinary programmer such as myself is condemned to 
programming for a single distro.


Regards,
Bob

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-06-05 Thread Bob Warren

Bob Warren wrote:
>
What I am going to do later on today is to take an Ubuntu Gnome Rev 
standalone I have created, load up the latest Kubuntu live CD, and see 
whether it runs. I'll let you know what happens.


Another experiment I could do later is to make sure I include libraries 
in my Gnome Rev standalone that I know do not exist in KDE, and see 
whether that runs.



Mark (Wieder):

I have just conducted 2 experiments using Rev standalone programs that 
were created in Ubuntu:


1. My Picture Chooser Widget
(see http://www.howsoft.com/runrev/stacks.htm)

2. A new app consisting of a window and all the script/data base 
support 	libraries available in the standalone settings


They both ran perfectly in Kubuntu Live.

Apart from possibly including external libraries (which I presume is the 
aim of the "externals" folder now accompanying Rev standalones), do you 
have any other type of Rev standalone you think is worth testing? If so, 
please send me the stack from Kubuntu and I'll try making a standalone 
in Ubuntu and running it in Kubuntu, or if you prefer, send me a 
standalone from Kubuntu and I'll se whether it runs OK in Ubuntu, or 
none of the above if you are already fed up with this thread!!.


Thanks,
Bob


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-06-05 Thread J. Landman Gay

Bob Warren wrote:

You may be right, and in fact what you recommend may represent a "safe" 
policy, but that is not exactly what I ran into. I produced a Realbasic 
module that I thought was a "standalone", but later discovered that it 
was an "executable" (i.e. not a "standalone").


You probably shouldn't get too hung up on the terminology. In general, 
"standalone" means "executable". The term is a holdover from the 
HyperCard days, and was invented 10 or 12 years ago to distinguish 
between stacks, which require a separate engine or Player, and 
applications, which "stand alone" because they do not need a Player. In 
HyperCard, a standalone simply meant that the engine was embedded into 
the file on disk. And that is pretty much what Rev does too.


Revolution extends the process a bit by embedding as many resources from 
the IDE as it can (script and image libraries, mostly,) but 
"standalones" still depend heavily on certain features of the OS. If you 
think of them as "executables" you will probably be more on-track.


--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-06-05 Thread Bob Warren

Mark Wieder wrote:
>
This issue that Bob ran into here is that you can't build a standalone
that relies on gnome GUI libraries and expect it to run in a kde
environment where those libraries don't exist. If I build a kde
standalone that used some specific features of my desktop environment
I'd expect that it wouldn't run on Bob's gnome desktop either.

--
Mark:

You may be right, and in fact what you recommend may represent a "safe" 
policy, but that is not exactly what I ran into. I produced a Realbasic 
module that I thought was a "standalone", but later discovered that it 
was an "executable" (i.e. not a "standalone"). In fact, this RB GUI 
program ran OK on some KDE versions of Linux, but (surprisingly) not on 
Kubuntu.


Within my limited experience of Rev/Linux, I have never had any trouble 
running/exchanging Rev standalone programs between Gnome and KDE, so far...


Has anyone ever had the experience of creating a Rev standalone in 
Linux, subsequently finding that it does not run successfully on another 
flavour of Linux, regardless of whether it is Gnome or KDE?


What I am going to do later on today is to take an Ubuntu Gnome Rev 
standalone I have created, load up the latest Kubuntu live CD, and see 
whether it runs. I'll let you know what happens.


Another experiment I could do later is to make sure I include libraries 
in my Gnome Rev standalone that I know do not exist in KDE, and see 
whether that runs.



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-06-05 Thread Mark Wieder
Ken-

Sunday, June 4, 2006, 4:09:44 PM, you wrote:

> The only clarification I'd make is that the Revolution engine itself (which
> is bundled together with your stack when you make a standalone) requires
> certain OS-level libraries on Linux, and if they are not available, your
> application won't run. This can be seen when trying to use Rev as a CGI on a
> Linux server without all the necessary Linux libraries in place (see
> http://www.sonsothunder.com/devres/revolution/tips/cgi001.htm for more
> info). I'm assuming that since the Rev executable can simply be dragged to a
> Linux web server for use as a CGI (or it *used* to, anyway) that the same
> thing is true - if you're missing "libXext.so.6" for example, it may not
> run.  (If anyone sees that I'm wrong, please let me know...)

And the issue of reliance on external libraries isn't confined just to
linux. You can't, for example, build an OSX standalone and expect it
to run under Windows. There are always going to be OS dependencies.
This issue that Bob ran into here is that you can't build a standalone
that relies on gnome GUI libraries and expect it to run in a kde
environment where those libraries don't exist. If I build a kde
standalone that used some specific features of my desktop environment
I'd expect that it wouldn't run on Bob's gnome desktop either.

> Other than that, I'd be kind of careful with your definition of "standalone"
> and the definition used by Revolution for "standalone". Rev applications
> built using "Save as Standalone" can either be self-contained, or can call
> on outside resources as necessary, based on how they were coded. So to be
> glib, sometimes standalones are "standalones", and sometimes they're
> "executables"... ;-)

A standalone could, for example, have a dozen QuickTime movies as
external files. It's not necessarily just a single file. As I see it,
the distinction between a stack and the standalone built from that
stack is that in the IDE the stack relies on resources from the IDE
(the rev engine, various libraries...) which are which are packaged
together into the standalone when it's built. So you end up with as
much of the IDE as you need without the actual IDE.

> Personally, I always use the word "exectuable" when talking about apps on
> Windows and Linux, and "application" when talking about apps on MacOS...

(MSWord's spelling checker didn't like "MacOS", and suggested that you
might have meant "maces"... of course, my email client didn't like
"MSWord's" and suggested "swords"...)

-- 
-Mark Wieder
 [EMAIL PROTECTED]

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-06-04 Thread Ken Ray
On 6/4/06 12:51 PM, "Bob Warren" <[EMAIL PROTECTED]> wrote:

> I AWAIT YOUR CORRECTIONS. Thanks.

The only clarification I'd make is that the Revolution engine itself (which
is bundled together with your stack when you make a standalone) requires
certain OS-level libraries on Linux, and if they are not available, your
application won't run. This can be seen when trying to use Rev as a CGI on a
Linux server without all the necessary Linux libraries in place (see
http://www.sonsothunder.com/devres/revolution/tips/cgi001.htm for more
info). I'm assuming that since the Rev executable can simply be dragged to a
Linux web server for use as a CGI (or it *used* to, anyway) that the same
thing is true - if you're missing "libXext.so.6" for example, it may not
run.  (If anyone sees that I'm wrong, please let me know...)

Other than that, I'd be kind of careful with your definition of "standalone"
and the definition used by Revolution for "standalone". Rev applications
built using "Save as Standalone" can either be self-contained, or can call
on outside resources as necessary, based on how they were coded. So to be
glib, sometimes standalones are "standalones", and sometimes they're
"executables"... ;-)

Personally, I always use the word "exectuable" when talking about apps on
Windows and Linux, and "application" when talking about apps on MacOS...

Why? Don't know, really...

:-)

Ken Ray
Sons of Thunder Software
Web site: http://www.sonsothunder.com/
Email: [EMAIL PROTECTED]

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-06-04 Thread Bob Warren
I first met the term "standalone" when I initially made contact with 
Rev. Before this, using Windows only, I had always dealt with "executables".
So now, in order to clarify certain issues connected with the subject of 
installation, I would like to make a series of statements about these 2 
types of binary files, and I would be grateful if you would correct me 
if I am wrong.


A "standalone" means what it says. It stands alone and is completely 
independent. It carries what might have originally been library 
information within itself, and uses this at runtime. It does NOT refer 
to what might be similar library routines already embedded in the 
operating system it later runs on, that could be more or less current or 
"up to date" in comparison. Consequently, if I produce a "standalone" as 
a single file in Rev, everything it needs is bundled with it and it 
should run on anyone's machine by simply copying it (almost anywhere) to 
the HD and double-clicking on it.


My recent little experiment of producing a GUI module in RB has been 
very instructive. It did not run on Mark Wieder's Kubuntu and complained 
about the unavailability of a certain library routine. To me, this seems 
to indicate that RB does not produce a "standalone" GUI program but an 
"executable" one in the traditional Windows manner. At runtime, on a 
different machine, if the libraries found in the operating system are 
not 100% compatible with the libraries present in the system where the 
program was created, it fails. Thus, such RB programs, different to Rev 
standalones, might require a "setup" in the traditional Windows manner, 
even under Linux.


If what I say is correct - AND PLEASE JUMP ON ME IMMEDIATELY IF I AM 
INCORRECT - then the question of "setting up" Rev programs in Linux is 
**normally** a relatively simple one. There is no damn "registry", and 
all you have to do is to copy (perhaps with decompression) the program 
and other files where you like on the HD, and to provide (if you can) 
icons on the desktop and/or in the start menu.


Here are a few more statements that I hope you will put me right on 
where necessary.


There are 8 HD paths that my little module hopes to deduce from the 
operating system. On my Ubuntu Linux, here is an example:


/home/bob/Desktop/(DesktopFolder)
/home/bob/(PreferencesFolder)
/usr/(SystemFolder)
/tmp/(TemporaryFolder)
/home/bob/(ApplicationSupportFolder)
failed(FontsFolder)
failed(StartupItemsFolder)
/home/bob/.Trash/(TrashFolder)

And here is another example on Gentoo (with KDE):

/home/rishi/Desktop/(DesktopFolder)
/home/rishi/(PreferencesFolder)
/usr/(SystemFolder)
/tmp/(TemporaryFolder)
/home/rishi/(ApplicationSupportFolder)
failed(FontsFolder)
failed(StartupItemsFolder)
failed (TrashFolder)

Of these, the first 5 are always the same under all distributions of 
Linux, except for the user name. Therefore, as Jacqueline Landman Gay 
suggested, the use of the global $HOME variable in Rev should be 
sufficient to deduce these paths.


Different distributions of Linux typically vary the paths to the last 3 
categories, and the RB functions for deducing them may or may not be 
successful, or in other words, they are unreliable for general Linux use 
and can only be employed perhaps for a limited set of distros where they 
are known to succeed.


And finally, considering the above, although it would be nice if Rev 
implemented the suite of reportable system path-deducing functions 
through specialFolderPath in Linux, or even extended them to provide 
reliable reports on the Fonts, Startup Items and Trash, there is no 
greatly imperative need for it at this very moment, unless you want to 
install new fonts, get your program executed automatically at OS 
startup, etc.


I AWAIT YOUR CORRECTIONS. Thanks.

Bob

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-06-03 Thread Mark Wieder
Bob-

Friday, June 2, 2006, 11:46:02 AM, you wrote:

> Further to what I have just said, if you are enthusiastic, you could
> look at what you have installed in Synaptic, and if the shared libraries
>   libgtk-x11-2.0.so.0 are there but have not been installed, you could
> try installing them. Or if they are there, they might need upgrading
> (see right click of the mouse button on the library name for this 
> option). Just a thought.

I don't want to prolong this on the list because it's starting to get
a bit off-topic, but I just want to mention that you have the gtk
libraries installed by default because they're part of the gnome
desktop. They're not necessary in kde, so you'll get that error about
the shared library not being found *unless* you specify that the gtk
is a required install under kde before running your app.

-- 
-Mark Wieder
 [EMAIL PROTECTED]

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-06-03 Thread Bob Warren


Bob Warren wrote:

>> And further to what I have just said further, note how this brings us
>> back to the whole question of real "installion" in Linux, the very
>> subject of this thread, which of course should take the
>> existence/upgrade of library routines into account. But as I said at 
the

>> beginning of the thread, perhaps that is a future dream, unless Richard
>> managed to find a piece of satisfactory 3rd party software for the
>> purpose. Somehow, I doubt it.

Richard Gaskin wrote:
>>>
Nope, I haven't.

Thus far what I've seen is that every window manager thinks their work
is the Ultimate Solution, without regard for compatibility with any other.

I'd like to be more supportive, but my experience thus far is that the
biggest thing holding Linux back from broad desktop adoption is the
Linux developer community.

If we get to a stage where they begin to regard their work as less
precious than the user experience, perhaps they'll prioritize
standardization higher than it's been thus far.

But until then, the issue with Linux is that there is no "there" there,
in the sense that Linux isn't a particular thing, but a collection of
things, and many of those things just don't play nice together.

Technologically I believe Linux is well poised to blow Micro$oft out of
the water.  Once the project leaders for the various window managers get
around to handling the work of compatibility for the basics, I suspect
we'll see a renaissance of Linux development.

Alternatively, it might be ideal for consumers if one window manager
began to reach the tipping point, the critical mass which makes it the
single clear choice, relegating all others to minor, specialized roles.
  At that point the complete Linux experience would become a single
thing,  something consumers can more readily wrap their collective head
around.

Until then, the whole thing is much harder than it needs to be

--
I agree with you completely, Richard, but I am perhaps a bit more 
optimistic. We have seen great improvements over the last year or two, 
and I believe we might perhaps be on the verge of a qualitive change. I 
have been involved with teaching/training all my life, and one of the 
great talents I have (or perhaps it is the only one!) is that I am a 
natural dummy. In my experience, technicians often cannot see the wood 
for the trees, and they revel in complexity. But ordinary people are not 
like that, and in the modern world they have a voice. People such as 
myself are now becoming involved in Linux for the first time. I don't 
want to know about DOS-like terminals, sudo, itsy-bits binary packages 
and what to do if they get broken, etc., etc. I want something which is 
simple, elegant, automatic and practical. And the Linux producers are 
listening. But it is early times yet. Give Linux one or two more years 
(just as Windows has had, for example), and we might see even greater 
improvements. What is perhaps involved here with Linux, different to the 
Microsoft and Macintosh dictatorial systems, is the question of the need 
for concensus, which is a widely social process that takes time. 
Personally, I would like to see it today, but if that is not possible 
then I am prepared to wait and to contribute. And for a great many 
people, the commitment to Linux is absolutely crucial.


By the way, Mr David Grogono has very kindly offered to compile the 
necessary console version of our temporary module for deducing the Linux 
system paths. I think his co-operation in this respect shows a great 
attitude.


Bob



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-06-02 Thread Bob Warren
That was quick, wasn't it? I've discovered that if I want to produce a 
console version of the module for reporting fundamental system paths in 
Linux, I need RB Pro.


That's as far as I can go, I'm afraid.

If anyone has RB Pro for Linux and would like to produce the console 
version of the module, or even offer it afterwards to the Rev community, 
here is the coding which is very simple:


-

  Dim t as TextOutputStream

  t = GetFolderItem("sys_info.txt").CreateTextFile

  if t = nil then quit //couldn't create text file, possibly
don't have permissions

  if DesktopFolder <> nil then t.WriteLine DesktopFolder.AbsolutePath 
else t.WriteLine "failed"


  if PreferencesFolder <> nil then t.WriteLine 
PreferencesFolder.AbsolutePath else  t.WriteLine "failed"


  if SystemFolder <> nil then t.WriteLine SystemFolder.AbsolutePath
else t.WriteLine "failed"

  if TemporaryFolder <> nil then t.WriteLine 
TemporaryFolder.AbsolutePath else  t.WriteLine "failed"


  if ApplicationSupportFolder <> nil then t.WriteLine 
ApplicationSupportFolder.AbsolutePath else  t.WriteLine "failed"


  if FontsFolder <> nil then t.WriteLine FontsFolder.AbsolutePath
else t.WriteLine "failed"

  if StartupItemsFolder <> nil then t.WriteLine 
StartupItemsFolder.AbsolutePath else  t.WriteLine "failed"


  if TrashFolder <> nil then t.WriteLine TrashFolder.AbsolutePath
else t.WriteLine "failed"

  t.close
  quit

-
Note that the "if-else" conditionals above should be all on one line, 
not broken as it is bound to appear in this e-mail.


Now I'll stop writing RB code on the UR-List before someone starts 
complaining!


Bob


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-06-02 Thread Bob Warren
Sorry about polluting the list with little items from my stream of 
consciousness, but a penny might have dropped.


The library file libgtk-x11-2.0.so.0 is concerned with Linux's graphical 
interface, and it is required because although my standalone application 
for discovering fundamental system info is invisible, it is still a GUI app.


If I produce a console version of the program, which was already in the 
pipeline anyway, that should certainly cure the dependence on such 
libraries.


I'll get back to you when it is ready.

Bob

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-06-02 Thread Richard Gaskin

Bob Warren wrote:
And further to what I have just said further, note how this brings us 
back to the whole question of real "installion" in Linux, the very 
subject of this thread, which of course should take the 
existence/upgrade of library routines into account. But as I said at the 
beginning of the thread, perhaps that is a future dream, unless Richard 
managed to find a piece of satisfactory 3rd party software for the 
purpose. Somehow, I doubt it.


Nope, I haven't.

Thus far what I've seen is that every window manager thinks their work 
is the Ultimate Solution, without regard for compatibility with any other.


I'd like to be more supportive, but my experience thus far is that the 
biggest thing holding Linux back from broad desktop adoption is the 
Linux developer community.


If we get to a stage where they begin to regard their work as less 
precious than the user experience, perhaps they'll prioritize 
standardization higher than it's been thus far.


But until then, the issue with Linux is that there is no "there" there, 
in the sense that Linux isn't a particular thing, but a collection of 
things, and many of those things just don't play nice together.


Technologically I believe Linux is well poised to blow Micro$oft out of 
the water.  Once the project leaders for the various window managers get 
around to handling the work of compatibility for the basics, I suspect 
we'll see a renaissance of Linux development.


Alternatively, it might be ideal for consumers if one window manager 
began to reach the tipping point, the critical mass which makes it the 
single clear choice, relegating all others to minor, specialized roles. 
 At that point the complete Linux experience would become a single 
thing,  something consumers can more readily wrap their collective head 
around.


Until then, the whole thing is much harder than it needs to be

--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-06-02 Thread Bob Warren

Mark:

And further to what I have just said further, note how this brings us 
back to the whole question of real "installion" in Linux, the very 
subject of this thread, which of course should take the 
existence/upgrade of library routines into account. But as I said at the 
beginning of the thread, perhaps that is a future dream, unless Richard 
managed to find a piece of satisfactory 3rd party software for the 
purpose. Somehow, I doubt it.


Bob

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-06-02 Thread Bob Warren

Mark:

Further to what I have just said, if you are enthusiastic, you could 
look at what you have installed in Synaptic, and if the shared libraries 
 libgtk-x11-2.0.so.0 are there but have not been installed, you could 
try installing them. Or if they are there, they might need upgrading 
(see right click of the mouse button on the library name for this 
option). Just a thought.


Bob


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-06-02 Thread Bob Warren

Mark Wieder wrote:

Wednesday, May 31, 2006, 1:56:47 PM, you wrote:


>> If any of you have non-Debian based Linuxes installed, would you mind
>> giving it a quick try? I would also be interested in knowing the
>> contents of the "sys_info.txt" output file under your different Linux
>> flavour.


Well, I know you said "non-Debian", but here's what I get under
Kubuntu 6.0.6 (Dapper Drake):

error while loading shared libraries: libgtk-x11-2.0.so.0:
cannot open shared object file: No such file or directory


-
Thanks Mark!
This is rather strange, because I am using Ubuntu 6.0.6 (Dapper Drake) 
and I have no problem at all running the program. (Please note folks, I 
am using the Gnome version - Ubuntu - and he is using the younger KDE 
version - Kubuntu.)


In fact, for the development of this little program, Mr David Grogono, 
REAL Software's Director of Engineering - who is also a Rev client since 
he participates on the UR-List - was an enormous help in putting me 
right (since I am an absolute novice in RB), and I am very grateful to 
him. However, since we were dealing with RB and not Rev, we were both 
greatly concerned about not creating any kind of confusion as a result 
of it, and I decided to deal with it off-list. So effectively, that is 
what I am going to do now. I've sent a copy of this reply to him, and if 
any kind of recommendation arises as a result, one of us will report 
back to you.


By the way, have you been accompanying the (almost) daily updates 
offered by Kubuntu for the Dapper Drake beta? My Ubuntu is completely up 
to date, but if your Kubuntu isn't, it might account for the discrepancy 
between the shared libraries. And we must remember that our distros are 
both still in beta.


Best regards,
Bob

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-06-01 Thread Mark Wieder
Bob-

Wednesday, May 31, 2006, 1:56:47 PM, you wrote:

> If any of you have non-Debian based Linuxes installed, would you mind
> giving it a quick try? I would also be interested in knowing the 
> contents of the "sys_info.txt" output file under your different Linux
> flavour.

Well, I know you said "non-Debian", but here's what I get under
Kubuntu 6.0.6 (Dapper Drake):

error while loading shared libraries: libgtk-x11-2.0.so.0:
cannot open shared object file: No such file or directory

-- 
-Mark Wieder
 [EMAIL PROTECTED]

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-06-01 Thread Bob Warren

Rishi Viner wrote:
>
On Gentoo (with KDE), I get:

/home/rishi/Desktop/
/home/rishi/
/usr/
/tmp/
/home/rishi/
failed
failed
failed

in my sys_info.txt
Under KDE it looks like you have trouble with FontsFolder, 
StartupItemsFolder,

TrashFolder.

I'm fairly sure the normal fonts location is: /usr/share/fonts/

My startup items folder is at: /home/rishi/.kde/Autostart/

My trash is at /home/rishi/Desktop/trash.desktop which is a shortcut 
with URL=trash:/

-
Thanks Rishi!

Unfortunately, there is nothing I can do about the success of these 
functions, since they come from RealBasic. But at least it seems that RB 
knows the difference between what it knows and what it doesn't know. The 
first 5 paths are correct, and in the case of the last 3, the paths 
couldn't be deduced although they might exist.


Another thing to be remembered is that this standard set of functions is 
used on all platforms, including Windows, so for example, I would 
imagine that "StartupItemsFolder" is more applicable to Windows than to 
Linux. Before my RB trial for Windows ran out (today, in fact), I ran 
the module for Windows and it gave me all 8 paths correctly.


With the hundreds of Linux distros out there, all with slightly 
different characteristics, I would be surprised if anyone could do much 
better than this in deducing the not-quite-so-fundamental paths such as 
e.g. the trash.


-
Rishi Viner wrote:
>
might get more info on this as freedesktop.org?
-
Great! Thanks again Rishi, I'll check it out.

Best regards,
Bob

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-05-31 Thread Rishi Viner
Hi Bob,

On Thu, 1 Jun 2006 06:56 am, Bob Warren wrote:
> If any of you have non-Debian based Linuxes installed, would you mind
> giving it a quick try? I would also be interested in knowing the
> contents of the "sys_info.txt" output file under your different Linux
> flavour.

On Gentoo (with KDE), I get:

/home/rishi/Desktop/
/home/rishi/
/usr/
/tmp/
/home/rishi/
failed
failed
failed

in my sys_info.txt

Under KDE it looks like you have trouble with FontsFolder, StartupItemsFolder, 
TrashFolder. 

I'm fairly sure the normal fonts location is: /usr/share/fonts/

My startup items folder is at: /home/rishi/.kde/Autostart/

My trash is at /home/rishi/Desktop/trash.desktop which is a shortcut with 
URL=trash:/  
I'm not sure how those KDE/Konqueror KIOslave URLs work in terms of file 
systems... might get more info on this as freedesktop.org?

HTH

-- 
Rishi Viner
--
Australia

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-05-31 Thread Bob Warren
Regarding the standalone module for discovering fundamental system path 
information in Linux, which you can download here:-


http://www.howsoft.com/runrev/sysinfo/get_sys_info_linux.zip

- I am pleased to say that I have managed to cure the little problem 
that made it necessary to give the prog "executable" status in its 
properties. The program should now run directly after extracting it.


If any of you have non-Debian based Linuxes installed, would you mind 
giving it a quick try? I would also be interested in knowing the 
contents of the "sys_info.txt" output file under your different Linux 
flavour.


Thanks!

Bob Warren

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-05-30 Thread Bob Warren

Hi Rev folks!

With (more than) a little off-list help, I have managed to improve my 
standalone module for discovering fundamental system path information in 
Linux. You can download it here:


http://www.howsoft.com/runrev/sysinfo/get_sys_info_linux.zip

When extracting the program from the ZIP file, please note that you may 
have to give it "executable" status by right-clicking the file and 
changing the properties. This is a little problem I am still working on.


It is still a GUI version, but now it really is 100% invisible! As 
before, the output file (sys_info.txt) contains the following paths, but 
you will see that if a path is not available in a particular distro, it 
is marked as such. Here's an example of what you get in Ubuntu 
(Debian-based, Gnome):-


/home/bob/Desktop/(DesktopFolder)
/home/bob/(PreferencesFolder)
/usr/(SystemFolder)
/tmp/(TemporaryFolder)
/home/bob/(ApplicationSupportFolder)
failed(FontsFolder)
failed(StartupItemsFolder)
/home/bob/.Trash/(TrashFolder)

- and here's what you get in Kurumin (Debian-based, KDE):

/home/kurumin/Desktop/(DesktopFolder)
/home/kurumin/(PreferencesFolder)
/usr/(SystemFolder)
/tmp/(TemporaryFolder)
/home/kurumin/(ApplicationSupportFolder)
failed(FontsFolder)
failed(StartupItemsFolder)
failed(TrashFolder)

[N.B. In the above, "kurumin" is also the default user name.]

This new version should not get hung up if a path is not available in 
the distro. Regardless of the paths available, the module should always 
quit after it has done its job.


For an example of how to shell this module (get_sys_info_linux) from 
your Rev handler, please refer to the demo stack for my File/Picture 
Chooser Widgets at:


http://www.howsoft.com/runrev/stacks.htm

In addition, you would be advised to delete the file "sys_info.txt" 
before calling the shell and also, after shelling, to set a timer on the 
appearance of the "sys_info.txt" file so that if in fact it does not 
appear for any reason, your Rev handler does not get stuck in an 
infinite waiting loop. This is another aspect that requires a little 
polishing.


There may be further improvements to this module, and it is possible 
that the next version will be a lighter console (i.e. non-GUI) rendering.


I hope that this temporary workaround is of some use to you. Please let 
me know if you have any observations.


Regards to all,
Bob Warren


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-05-29 Thread Bob Warren

Jacqueline Landman Gay wrote:
>
I know almost nothing about the 'nixes, but it seems to me that a script
could calculate most of these using the globals that are automatically
loaded when Rev starts up. All (or many? Not sure) of the standards are
there and can be used in any script; i.e., $USR, $HOME, $PATH, etc.
Maybe these can be used to calculate the necessary paths?

For example: $USER/Desktop/
Or: $HOME/.MyApp/

--
Here are the globals given by Rev under Ubuntu (Gnome) Linux:

$DBUS_SESSION_BUS_ADDRESS 
unix:abstract=/tmp/dbus-WiBK3s8pAR,guid=23217b440bef325962f5e40a61735d00

$DESKTOP_SESSIONdefault
$DISPLAY:0.0
$GDM_XSERVER_LOCATION   local
$GDMSESSION default
$GNOME_DESKTOP_SESSION_ID   Default
$GNOME_KEYRING_SOCKET   /tmp/keyring-hjWXCj/socket
$GTK_RC_FILES   /etc/gtk/gtkrc:/home/bob/.gtkrc-1.2-gnome2
$HOME   /home/bob
$LANG   en_AU.UTF-8
$LANGUAGE   en_AU:en_US:en_GB:en
$LOGNAMEbob
$PATH			 
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games

$PWD/home/bob
$SESSION_MANAGERlocal/bob-desktop:/tmp/.ICE-unix/4709
$SHELL  /bin/bash
$SHLVL  0
$SSH_AGENT_PID  4751
$SSH_AUTH_SOCK  /tmp/ssh-ThYkAa4709/agent.4709
$USER   bob
$USERNAME   bob

---
Obviously, $HOME, $USER and $USERNAME are useful since they give the 
user's name. How much of the rest could be calculated under different 
Linux distros is hard (for me) to say.

---
---
Rishi Viner wrote:
>
All Linux flavors should have su! They will also all have sudo if it is
installed (it is an application on its own). If sudo is not there it 
would be unusual and certainly very easy for the user to install, as 
long as they have the root password etc to set it up.

--
Yes, but in order to be able to automate sudo through Rev, you need to 
able to find sudo in the file system in the first place. Also, to be 
able to achieve certain things through sudo, the automation routine 
would have to be in possession of the root password - hardly practical.


Is that right in your opinion, or have I missed the point here?

Bob

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-05-29 Thread Bob Warren

Bob Warren wrote:
>
Richard (and others): Please let me know if this module is of any real
use to you. If so, I will try to improve my RB project to include error
handling, OK? But not tonight, Josephine!

Well, as usual Mr Ken Ray is all quiet there in the wings, and then BAM!
He comes up with a ready solution! Pity I didn't see it before working 
out the problems I was having with my own routine, but never mind, it's 
all good didactics. I also see that there are also other Linux wizards 
out there, but normally they keep quiet. Am I the only one with a big mouth?


Regardless of Richard's need of the module I produced, I'll include the 
error handling anyway just for good measure. But I have other stuff to 
do today - tomorrow perhaps. I'll let you know when the hopefully more 
reliable module is available.


Regards to all,
Bob

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-05-28 Thread Bob Warren
Just a little bit of follow-up on the use of the executable module 
"get_sys_info_linux". I have a Live CD (where you don't have to install 
anything on the HD) for the Brazilian Kurumin Linux (KDE). So I loaded 
it up and ran "get_sys_info_linux". This was the result in "sys_info.txt":


/home/kurumin/Desktop/
/home/kurumin/
/usr/
/tmp/

("Kurumin" is not only the name of the distro, but also the default user 
name.)


As you can see, the last parameter (TrashFolder) did not appear, and in 
fact the program module did not close as a result.


Richard (and others): Please let me know if this module is of any real 
use to you. If so, I will try to improve my RB project to include error 
handling, OK? But not tonight, Josephine!


Regards,
Bob


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-05-28 Thread Bob Warren
OK Richard, I think I might have just about cracked it. If you navigate 
to http://www.howsoft.com/runrev/sysinfo/ you can download 
get_sys_info_linux.zip .


Inside, you will find a Linux executable to get system info as detailed 
below. For some reason that I haven't worked out yet though, changing 
the file name, up/downloading it over the Internet, or simply extracting 
the program from the ZIP file nullifies its executable status. So when 
you extract it, look at the file's properties (right click of the mouse) 
and GIVE IT EXECUTABLE STATUS.


Here is my first (and possibly last) routine in RB for creating the module:

  Dim g As FolderItem
  Dim h As string
  Dim f As FolderItem
  Dim t as TextOutputStream

  f = GetFolderItem("sys_info.txt")
  t = f.CreateTextFile

  g=DesktopFolder
  h=g.AbsolutePath
  t.Write h
  t.Write Chr(13) + Chr(10)

  //g=ApplicationsSupportFolder
  //h=g.AbsolutePath
  //t.Write h
  //t.Write Chr(13) + Chr(10)

  //g=FontsFolder
  //h=g.AbsolutePath
  //t.Write h
  //t.Write Chr(13) + Chr(10)

  g=PreferencesFolder
  h=g.AbsolutePath
  t.Write h
  t.Write Chr(13) + Chr(10)

  //g=StartupItemsFolder
  //h=g.AbsolutePath
  //t.Write h
  //t.Write Chr(13) + Chr(10)

  g=SystemFolder
  h=g.AbsolutePath
  t.Write h
  t.Write Chr(13) + Chr(10)

  g=TemporaryFolder
  h=g.AbsolutePath
  t.Write h
  t.Write Chr(13) + Chr(10)

  g=TrashFolder
  h=g.AbsolutePath
  t.Write h
  t.Write Chr(13) + Chr(10)

  //g=SpecialFolder
  //h=g.AbsolutePath
  //t.Write h
  //t.Write Chr(13) + Chr(10)

  t.close
  Quit

--
As you can see, the output is to the file "sys_info.txt". The items 
commented out are the ones which did not work under Linux. So what we 
have in "sys_info.txt" are the paths in the order above, ignoring the 
commented ones. On my computer (Ubuntu), this gives:


/home/bob/Desktop/  (DesktopFolder)
/home/bob/  (PreferencesFolder)
/usr/   (SystemFolder)
/tmp/   (TemporaryFolder)
/home/bob/.Trash/   (TrashFolder)

--
In RR, you can now do a "shell and wait end" on the get_sys_info_linux 
module.


One little detail that I might have to clear up eventually is that the 
RB coding was put into the window's "Activate" handler, but I found that 
if I made the window invisible, this handler would not be actioned. So I 
kept it visible and reduced the window's dimensions to 1x1 pixels, but 
it doesn't help very much because there must be a default minimum size 
that is independent of what I specified in the program, and in fact you 
can actually see a very quick flash of a window which is certainly 
bigger than 1x1 pixels.


That's the best I can do at the moment, I'm afraid. Hope it helps.
Let us know how you get on.

Regards,
Bob



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-05-28 Thread J. Landman Gay

Ken Ray wrote:

  dtFolder=DesktopFolder
  aSupFolder = ApplicationSupportFolder
  prefsFolder = PreferencesFolder


BTW, the RB Help has some clues as to where *it* thinks these folders
are/should be in Linux (substitute "folder path" wherever you see FolderItem
below):

DesktopFolder tries to return the desktop folder for the current user's
Window Manager. If there is a folder named "Desktop", it will return a
FolderItem to that. Otherwise, if there is a folder in the current user's
home directory named ".gnome-desktop", it will return a FolderItem to that.

ApplicationSupportFolder returns a FolderItem for the Home directory for the
logged in user, /home/username/. Typically, when an application wants to
create an application support file, it will create a folder in the Home
directory corresponding to the application's name. For example, for MyApp,
it will use the path: "/home/username/MyApp/".

PreferencesFolder returns a reference to the current user's Home directory,
/Home/username.


I know almost nothing about the 'nixes, but it seems to me that a script 
could calculate most of these using the globals that are automatically 
loaded when Rev starts up. All (or many? Not sure) of the standards are 
there and can be used in any script; i.e., $USR, $HOME, $PATH, etc. 
Maybe these can be used to calculate the necessary paths?


For example: $USER/Desktop/
Or: $HOME/.MyApp/

--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-05-28 Thread Rishi Viner
On Sun, 28 May 2006 12:16 am, Garrett Hylltun wrote:
> The other issue might be, what the equivalents of sudo and su are on
> other flavors of linux.  I know sudo and su are on debian, but not sure
> about the others.

All Linux flavors should have su! They will also all have sudo if it is 
installed (it is an application on its own). If sudo is not there it would be 
unusual and certainly very easy for the user to install, as long as they have 
the root password etc to set it up. 

-- 
Rishi Viner
--
Australia
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-05-28 Thread Rishi Viner
On Mon, 29 May 2006 06:34 am, Bob Warren wrote:
> Richard Gaskin wrote:
>
> Thanks Bob.  While I'm sure RunRev will be interested in catching up
> with RB's well thought-out suite of folder paths, I'm not sure how long
> I can hold my breath waiting for Linux-related stuff in Bugzilla (I'm
> already in my 40s ) -- do you know of shell calls to get those paths?
>
> I don't need system or some of the others, just DesktopFolder,
> PreferencesFolder, and maybe ApplicationsSupportFolder.
>
> ---
> Richard:
>
> I don't know of any shell calls that can be made through Linux, but they
> must exist I imagine. Perhaps one of the Linux wizards out there can help.

"~" will find the users home folder. For example making a directory like this:
"mkdir ~/MyApp" will make the folder "/home//MyApp". 

So to place something on the users desktop, you would put it in "~/Desktop/" 
(note case sensitive!). This is the same on every Linux distro that I use 
(RedHat, SuSE, Gentoo). 

User specific preferences for an application would usually go in "~/.MyApp", 
which may be a file or a folder... Global preferences would go in the 
application folder, but I'm not sure if you will always have permissions to 
write to this? Not sure here. 

HTH

-- 
Rishi Viner
--
Australia
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-05-28 Thread Ken Ray
>   dtFolder=DesktopFolder
>   aSupFolder = ApplicationSupportFolder
>   prefsFolder = PreferencesFolder

BTW, the RB Help has some clues as to where *it* thinks these folders
are/should be in Linux (substitute "folder path" wherever you see FolderItem
below):

DesktopFolder tries to return the desktop folder for the current user's
Window Manager. If there is a folder named "Desktop", it will return a
FolderItem to that. Otherwise, if there is a folder in the current user's
home directory named ".gnome-desktop", it will return a FolderItem to that.

ApplicationSupportFolder returns a FolderItem for the Home directory for the
logged in user, /home/username/. Typically, when an application wants to
create an application support file, it will create a folder in the Home
directory corresponding to the application's name. For example, for MyApp,
it will use the path: "/home/username/MyApp/".

PreferencesFolder returns a reference to the current user's Home directory,
/Home/username.

HTH,


Ken Ray
Sons of Thunder Software
Web site: http://www.sonsothunder.com/
Email: [EMAIL PROTECTED]

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-05-28 Thread Ken Ray
On 5/28/06 3:34 PM, "Bob Warren" <[EMAIL PROTECTED]> wrote:


> After getting the above working, I need to get it to save the system
> paths mentioned in the last e-mail instead of the lines "nameline",
> "addressline" and "phoneline". I also need to find out how to execute
> this on prog startup (followed by an immediate quit) rather than putting
> it into e.g. a button's mouseUp handler.

Here's the RB code to write the data to the text file:

  Dim dtFolder,aSupFolder,prefsFolder,outputFile as FolderItem
  Dim fileStream as TextOutputStream
  
  dtFolder=DesktopFolder
  aSupFolder = ApplicationSupportFolder
  prefsFolder = PreferencesFolder
  outputFile = GetSaveFolderItem(FileTypes1.Text,"text_saved_by_rb.txt")
  fileStream = outputFile.CreateTextFile
  fileStream.WriteLine dtFolder.AbsolutePath
  fileStream.WriteLine aSupFolder.AbsolutePath
  fileStream.WriteLine prefsFolder.AbsolutePath
  fileStream.Close
 
If you make this into an executable, you can run it with the launch command
(I believe) and then I'd insert a pause for 1/2 second or so, and then
verify the file is there and then read from it.

HTH,

Ken Ray
Sons of Thunder Software
Web site: http://www.sonsothunder.com/
Email: [EMAIL PROTECTED]

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-05-28 Thread Bob Warren

Richard Gaskin wrote:
>
Thanks Bob.  While I'm sure RunRev will be interested in catching up
with RB's well thought-out suite of folder paths, I'm not sure how long
I can hold my breath waiting for Linux-related stuff in Bugzilla (I'm
already in my 40s ) -- do you know of shell calls to get those paths?

I don't need system or some of the others, just DesktopFolder,
PreferencesFolder, and maybe ApplicationsSupportFolder.

---
Richard:

I don't know of any shell calls that can be made through Linux, but they 
must exist I imagine. Perhaps one of the Linux wizards out there can help.


As a 2nd class solution, I had the idea of getting these paths in an RB 
 module which would push them out to a text file so that they could be 
read in RR. The RR prog would then only have to shell the RB module and 
wait for it to terminate. In principle it was easy, but I don't have any 
practice in RB at all and I didn't manage to get the module to save the 
text file!


So here's an appeal. If anyone reading this is familiar with RB, perhaps 
they can tell me where I am going wrong. Here's the test routine for 
saving a text file:


  Dim nameline as String
  Dim addressline as String
  Dim phoneline as String
  nameline = "bob"
  addressline = "leonor de barros"
  phoneline = "32332951"

  Dim file as FolderItem
  Dim fileStream as TextOutputStream
  file=GetSaveFolderItem(FileTypes1.Text, "text_saved_by_rb.txt")
  fileStream=file.CreateTextFile
  fileStream.WriteLine nameline
  fileStream.WriteLine addressline
  fileStream.WriteLine phoneline
  fileStream.Close

As per Help (as far as I can gather***), I have defined the FileTypes1 
module in the IDE as:


Textapplication/textTEXTtext.txt

[***Though what is mentioned in the Help is "TextTypes" and not 
"FileTypes1" as appears for use in the IDE. If this is not an 
inconsistency in the Help, then it is probably where I am going wrong, 
and I need to learn how to define "TextTypes" more correctly.]


After getting the above working, I need to get it to save the system 
paths mentioned in the last e-mail instead of the lines "nameline", 
"addressline" and "phoneline". I also need to find out how to execute 
this on prog startup (followed by an immediate quit) rather than putting 
it into e.g. a button's mouseUp handler.


List moderators please note! I am simply trying to find a quick 
workaround for what is currently lacking in the Rev for Linux system 
info provided. I am NOT trying to discuss or promote RB! In fact, noting 
the difficulty I had trying to save a simple text file in RB, I am not 
all that impressed! Perhaps this kind of comparison between RB and RR is 
not such a bad thing.



The routine from the previous e-mail:

  Dim f As FolderItem
  f=DesktopFolder
  If f<>Nil then
MsgBox f.AbsolutePath
  else
MsgBox "The folderItem does not exist"
  end if

Other available functions are ApplicationsSupportFolder, FontsFolder, 
PreferencesFolder, StartupItemsFolder, SystemFolder, TemporaryFolder, 
TrashFolder, SpecialFolder.



Bob


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-05-27 Thread Mark Wieder
Richard-

Friday, May 26, 2006, 6:54:25 PM, you wrote:

> This installer will be made with Rev, so as much as I appreciate any
> tips about third-party installers it's essential to my workflow that I
> roll my own (I have an end-to-end automated build system).

apt or rpm target? If you're looking at a Debian-based core, look into

http://www.debian-administration.org/articles/336

If you don't mind a not-made-in-rev linux solution, you might check
out

http://www.lokigames.com/development/setup.php3

-- 
-Mark Wieder
 [EMAIL PROTECTED]

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-05-27 Thread Richard Gaskin

Bob Warren wrote:

Here is an interesting piece of information which may or may not have 
some practical implications for you.


I have just investigated RealBasic's functions for obtaining fundamental 
system information in Linux. I was using my free copy of RealBasic 2006 
Release 2 for Linux on the Ubuntu pre-release "Dapper Drake" beta.


The following little routine correctly gave me the HD path to my desktop:

   Dim f As FolderItem
   f=DesktopFolder
   If f<>Nil then
 MsgBox f.AbsolutePath
   else
 MsgBox "The folderItem does not exist"
   end if

Other available functions are ApplicationsSupportFolder, FontsFolder, 
PreferencesFolder, StartupItemsFolder, SystemFolder, TemporaryFolder, 
TrashFolder, SpecialFolder.



Thanks Bob.  While I'm sure RunRev will be interested in catching up 
with RB's well thought-out suite of folder paths, I'm not sure how long 
I can hold my breath waiting for Linux-related stuff in Bugzilla (I'm 
already in my 40s ) -- do you know of shell calls to get those paths?


I don't need system or some of the others, just DesktopFolder, 
PreferencesFolder, and maybe ApplicationsSupportFolder.


Not sure yet what I'll do about the Start menu shortcuts.

Sure would be nice if the project leaders for the various window 
managers would get over themselves and work together on common methods 
for common elements.  As long as every team feels their work is more 
precious than any other all of them are collectively slowing adoption of 
Linux, even as they may believe they're moving it forward.


--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.com


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-05-27 Thread Bob Warren

Bob Warren wrote:
>>
Presumably, the user knows where his desktop is, because if you ask this 
question in Transcript (sorry, "Revolution") you won't get any kind of 
answer: as you know, the function specialFolderPath for obtaining such 
system information, that works on both Mac and Windows, has not been 
implemented in Rev for Linux.



Richard:

Here is an interesting piece of information which may or may not have 
some practical implications for you.


I have just investigated RealBasic's functions for obtaining fundamental 
system information in Linux. I was using my free copy of RealBasic 2006 
Release 2 for Linux on the Ubuntu pre-release "Dapper Drake" beta.


The following little routine correctly gave me the HD path to my desktop:

  Dim f As FolderItem
  f=DesktopFolder
  If f<>Nil then
MsgBox f.AbsolutePath
  else
MsgBox "The folderItem does not exist"
  end if

Other available functions are ApplicationsSupportFolder, FontsFolder, 
PreferencesFolder, StartupItemsFolder, SystemFolder, TemporaryFolder, 
TrashFolder, SpecialFolder.


I haven't tried these other functions yet.

Regards,
Bob

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-05-27 Thread Bob Warren

Richard Gaskin wrote:

I'd like to make an installer for Linux versions of my app which handles
the basics:

- Puts the application in its own folder
- Puts a shortcut to the app in the Start menu
- Assigns appropriate file types to the app
- Assigns icons for the app and its documents

When I went fishing for this info a couple years ago, it seemed each
desktop manager had their own way of doing these things, with little if
any consistency between them.

What's involved in making one installer file that works with most common
Linux distros today?

This installer will be made with Rev, so as much as I appreciate any
tips about third-party installers it's essential to my workflow that I
roll my own (I have an end-to-end automated build system).

TIA -
-
Richard:

I'm not an expert on the subject (or any other for that matter), so 
please take anything I say with a pinch of salt.


The question of program installation is really the weakest part of Linux 
as it stands at the moment. Nor do I see the solution to this in the 
very near future, on account of the different meanings of "installation" 
 and the different characteristics of the Linuxes out there. At 
present, what you are asking for is still a dream, at least in my 
limited experience.


The easiest "solution" (which is not a solution really and certainly 
does not attend any of the items you have listed above) is to put the 
whole lot into a ZIP (or similarly compressed) file and to get the user 
to download it directly to the desktop. Presumably, the user knows where 
his desktop is, because if you ask this question in Transcript (sorry, 
"Revolution") you won't get any kind of answer: as you know, the 
function specialFolderPath for obtaining such system information, that 
works on both Mac and Windows, has not been implemented in Rev for Linux.


In a better world, you should be able to put your excellent question to 
the Rev engineers. Since I'm a naughty boy, I've CC'd this reply to Mark W.


Regards,
Bob



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Linux installation

2006-05-27 Thread Garrett Hylltun

Richard Gaskin wrote:
I'd like to make an installer for Linux versions of my app which handles 
the basics:


- Puts the application in its own folder
- Puts a shortcut to the app in the Start menu
- Assigns appropriate file types to the app
- Assigns icons for the app and its documents

When I went fishing for this info a couple years ago, it seemed each 
desktop manager had their own way of doing these things, with little if 
any consistency between them.


What's involved in making one installer file that works with most common 
Linux distros today?


This installer will be made with Rev, so as much as I appreciate any 
tips about third-party installers it's essential to my workflow that I 
roll my own (I have an end-to-end automated build system).


The location of your app can be /usr/bin or usr/home/username/yourapp 
Of course /usr/bin will require password to be able to be installed. 
Sudo or su will get you through that (ask the user for the password in 
advance.)


Their menu specs are here:
http://www.freedesktop.org/wiki/Standards_2fmenu_2dspec

For more specs linux related:
http://www.freedesktop.org/wiki/Standards

Here are some locations found for shortcuts on linux:

/usr/share/applications
/usr/share/applications/kde
/usr/share/gnome/apps  <- some sub dirs with shortcuts
/usr/lib/menu <- text config files for shortcuts
/usr/share/menu  <- text config files for shortcuts
/etc/menu

Setting up a menu entry is still iffy if you ask me, but if you stick 
with the freedesktop specs, you're more likely to have a working menu 
entry since most distro's are adopting it.  Otherwise, as you already 
know, there's a mess when it comes to the shortcuts.


Gnome used it's own location, KDE another, and all the other WM's 
probably have their own location also.  :-(


For file types, I don't remember at the moment.

I don't believe there is a way to actually assign an icon to an 
executable in any of the window managers.  At least I didn't see of any 
way under KDE or Gnome, just the shortcuts and menu entries have the icons.


And I can't remember how to assign a specific icon to associated files 
at the moment.  Been a while since I mucked around the innards of a 
linux system.


Personally, I think the menu shortcuts are still the only major issue 
you will run into.  And imo I'd setup shortcuts in the KDE, Gnome and 
freedesktop locations to insure that you get most, if not all of the users.


The other issue might be, what the equivalents of sudo and su are on 
other flavors of linux.  I know sudo and su are on debian, but not sure 
about the others.


-Garrett
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution