Linux installation - menus
http://standards.freedesktop.org/menu-spec/latest/ is probably the first place to go for how to do menus independently of WMs. Peter ___ 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
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
Linux installation
The only part of this I'm certain of is the desktop icon/link In terms of icons on desktops, it is not the window manager that counts. If you put the application into /opt and put an link and associated icon into /home/user/Desktop, in whatever WM they are using, if it supports icons on desktops, it will end up there and either single or double clicking it will start the app. Now you will probably wonder how to do that exactly from a rev installerdon't know! File associations - a way in may be to google on shebang for links to this. In terms of the menus, still less certain here, you only need to put the link into one WM (Gnome lets say) and the rest pick it up from there. The thing to find out about is /etc/xdg/menus. I believe you need to put entries someplace in there, but don't know the details. Hope this is a start Peter ___ 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
Linux installation - menus
http://standards.freedesktop.org/menu-spec/latest/ is probably the first place to go for how to do menus independently of WMs. Peter ___ 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
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
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: A new definition of libraries (was: Linux Installation)
Richard Gaskin wrote originally: 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). Richard Gaskin wrote now: As for installation, it depends on what one means by that. For a complete user experience, Mac and Windows have a higher standard to meet, with users expecting that an application will not merely run but will also have icons properly set up for the app and its documents, have document associations properly defined, and install a shortcut to itself into the Start menu on OSes that have one. --- One last complement before attempting to close this thread: The point I have been trying to make is that if you want to write an installer in Rev Linux to do the nice things you say above (your original stated task as I understood it), (a) your installer would have to be a real standalone, not itself requiring a setup, and (b) you could not even begin the task of writing such an installer in Rev without a very full implementation of the specialFolderPath functions. Let's give Linux a chance, it's much younger than Mac or Win. That's all. Shall we watch the football? 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: A new definition of libraries (was: Linux Installation)
Bob Warren wrote: Richard Gaskin wrote originally: 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). Richard Gaskin wrote now: As for installation, it depends on what one means by that. For a complete user experience, Mac and Windows have a higher standard to meet, with users expecting that an application will not merely run but will also have icons properly set up for the app and its documents, have document associations properly defined, and install a shortcut to itself into the Start menu on OSes that have one. --- One last complement before attempting to close this thread: The point I have been trying to make is that if you want to write an installer in Rev Linux to do the nice things you say above (your original stated task as I understood it), (a) your installer would have to be a real standalone, not itself requiring a setup, and (b) you could not even begin the task of writing such an installer in Rev without a very full implementation of the specialFolderPath functions. Ideally, yes, and I'd love to see specialFolderPath well implemented for the various Linux GUIs around. But even if such an installer needed a DLL or external helper app, that wouldn't be a show-stopper. One could compress a copy of the external files into the installer app, and the installer could spit them out, run them, and delete them when it's done. The hard part is knowing how to interface with each of the window managers out there -- 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: A new definition of libraries (was: Linux Installation)
Dan Shafer quoted: But anyone who tells you they have an app that runs on every version of Linux has a very simplistic app or a very simplistic understanding of what constitutes Linux. I have both! My chooser widget standalones are a lot more complex than Hello World, but they don't use any non-standard resources at all. Nevertheless, I'd be sooo happy if I could find a distro (Gnome or KDE) they didn't run on! Andre Garzia wrote: If you're running a professional distro such as Fedora, running rev might be as simple as double clicking. --- I've just replaced my Ubuntu with Fedora 5 (until tomorrow perhaps, then I'll be changing to Linspire (KDE)). Unfortunately, my widgets run perfectly on Fedora. It really is as simple as double clicking. I am not qualified to discuss the technicalities of this issue very well, but I might be able to help on the empirical side. If I get time tomorrow, I'm going to create a standalone using every widget in the Rev IDE** and every script library and db option, and then hunt for a distro it doesn't run on. After that, perhaps someone will be able to suggest a more intelligent empirical test app that we can all download and try on our particular flavour of Linux. [** Certainly, the Quick Time Player will not always work.] Richard Gaskin wrote: If you really like the word standalone then perhaps we can lobby the team leaders of the various incompatible Linux window managers to come up with a single spec, so Linux can at last refer to a single thing rather than a hodge-podge collection of loosely-related parts, thereby making it possible for application developers to write for Linux and know that it'll run well on all the various and wildly different things that distractingly use the same name. --- No doubt there is a great deal of truth in what you say, Richard, but is it really such a hodge-podge collection of loosely-related parts? Apart from what I've already indicated about the different layouts of the file system in some respects, which of the things we are capable of including in a Rev project would not work in the corresponding standalone running under any given distro? No doubt it is difficult for application developers in general to write for Linux and know that it'll run well, but we are not concerned with that here. We are considering Rev apps only. Does the Rev IDE and engine run under all Linuxes or not?** Under what distro does Rev itself fail to run? Or isn't that a pertinent question? [**Excluding the obvious, such as non-GUI versions, old versions, of course.] 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: A new definition of libraries (was: Linux Installation)
As I have said, I am not qualified to discuss the technicalities of the distribution of Rev standalones for Linux, how distributable they really are among the various distros, and whether they might need a setup or installation in the traditional sense. But I do know a few facts. Runtime Revolution produce a fairly sophisticated piece of software for Linux (far more sophisticated than I could ever produce) called Runtime Revolution. If I go to their site, RR for Linux is available in 2 forms: one for Red Hat Linuxes and one for the others called TGZ. I have never used a Red Hat Linux, so I download the 2nd of these. Once I have downloaded and expanded the available archive on my desktop (or somewhere else if I like), I have a bunch of files. Among these files, I look for the one called Revolution.X86 and I double click on it. The Rev IDE presents itself on screen, and I am ready to begin creating my own stacks. Note that in the description above there is no mention of setup or installation in the traditional sense of the words. Also, I presume that as this is the procedure on my Ubuntu Linux, it is also the procedure on many (all?) other non-Red Hat Linuxes. Speculating, I think that it may be identical to the procedure on Red Hat Linuxes too, but I don't know. What is this then? Magic? Or is Rev itself profoundly different from the standalone programs I produce using Rev? As I have said, perhaps I am getting a little lost in the technicalities of the discussion so far, but I do wonder how many people providing very interesting contributions actually use or have ever used Rev for Linux. If there is something wrong with my dummy's logic, then please tell me where I am going wrong! 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: A new definition of libraries (was: Linux Installation)
Bob, english is not my native language and sometimes I do fail to express myself in a way that others understand but even more often I do miss what the other guy is trying to express. I really am not grasping what you're trying to do but I'll try to explain a couple things about your last email. I am not using Rev for Linux, I ditched linux from my everyday life when I switched to the macintosh years ago. Let us begin by talking about linux package systems. As everyone and his techie dog knows, distributing linux software might prove a very complex experience due to the library dependency nightmare, that, I talked a little on my previous email. Also some FOSS Linux users won't trust or install any binary package, they will only trust/like software that is Free in all senses of the word and that they are able to see the source and build by themselves, thats cultural. TGZ is a gZiped tarball, which in plain english is a folder that was put inside a tape archive file and then zipped, this is the popular way for packing things for linux, very vanilla. Some eons ago when Red Hat was starting they created the RPM which stands for Red Hat Package Manager which is more than a simple compressed stuff for it knows where to unpack the files and to check for dependencies. RPM proved very successful and many distros now use it. So when you have a linux distribution that uses RPM as its main package system, you can trust that by installing a RPM file will give you all the files in the correct place and a software that will run. If you pick a TGZ (more usually a .tar.gz) file, then you might need to do some file moving yourself. RunRev distributes a binary package, by binary I am saying that the software comes as an closed binary executable and not as source code (of course they won't give the source for the engine) thats why you had such nice experience, the software is already built and your Unbuntu which is a very high level distro has the right libraries in the right place™. Now please Bob, I don't know if I am really helping you go somewhere but can you please tell me what you're trying to do? If its building software for linux with runrev then trust one thing, if the IDE runs, the standalones will run too. Rev will probably run on all major linux distros provided they are new ones (meaning no ancient kernel running for 5 years...). But don't expect it to run everywhere, not even linux users expect it. No one is expecting that Rev apps run on DSL or Knoppix (although they might). If your standalone doesn't run on a given linux, its not your fault. You're not responsible for that and you can do very little. Debugging why the app is not running is a very complex job and to get it running at all costs (replacing libraries, creating new symlinks) is a job for someone that really knows what he is doing, the normal end user will not go that way. What you can do that would really boost your linux offerings is: * Study linux packaging: create packages for your software for all major packaging systems like RPM, Debian and the others. * Create diagnostic bash scripts: this is a hard one and maybe the community should gather on a collective effort on this one. A script that would use ldd to find which libraries the standalone is linking and to check the presence of each one and write a logfile. In cases of software not running, this script might shed a clue. * Join forces in one-click software efforts for linux such as linspire click-and-run. There are people making money thru this channels, you might like it. Thats all I can think of, but I still don't understand what is really the problem. :-) Andre On Jun 11, 2006, at 12:00 PM, Bob Warren wrote: As I have said, I am not qualified to discuss the technicalities of the distribution of Rev standalones for Linux, how distributable they really are among the various distros, and whether they might need a setup or installation in the traditional sense. But I do know a few facts. Runtime Revolution produce a fairly sophisticated piece of software for Linux (far more sophisticated than I could ever produce) called Runtime Revolution. If I go to their site, RR for Linux is available in 2 forms: one for Red Hat Linuxes and one for the others called TGZ. I have never used a Red Hat Linux, so I download the 2nd of these. Once I have downloaded and expanded the available archive on my desktop (or somewhere else if I like), I have a bunch of files. Among these files, I look for the one called Revolution.X86 and I double click on it. The Rev IDE presents itself on screen, and I am ready to begin creating my own stacks. Note that in the description above there is no mention of setup or installation in the traditional sense of the words. Also, I presume that as this is the procedure on my Ubuntu Linux, it is also the procedure on many (all?)
Re: A new definition of libraries (was: Linux Installation)
Andre: First of all, I think your English is excellent, and if after nearly 33 years in Brazil my written Portuguese was as good as your English, I would be a happy man. Thank you very much for your very lucid explanation. Part of what you said is exactly what I confirmed with Ken Ray days ago, and I have been simply seeking to re-affirm this - and only this - ever since. You said: (Andre Garcia wrote:) If its building software for linux with runrev then trust one thing, if the IDE runs, the standalones will run too. Rev will probably run on all major linux distros provided they are new ones (meaning no ancient kernel running for 5 years...). --- On top of that, you have given me the kind of qualification I was looking for: (Andre Garcia wrote:) But don't expect it to run everywhere, not even linux users expect it. No one is expecting that Rev apps run on DSL or Knoppix (although they might). --- I'll certainly try the exceptional distros you mention. Incidentally, I think Rev standalones will probably run OK on Knoppix too, since they run perfectly on Kurumin which is a direct derivative of it. In this thread and the one it arose from, I have not been the slightest bit concerned about discussing the distribution of apps generally in Linux. I have only tried to discuss the distribution of Rev apps. It has now been confirmed again that they do NOT need installing in any normal sense of the word and that standalone means what it says. You can rest assured that you have answered my question perfectly, that you have helped enormously, and that I can now sleep at night knowing that I am not bonkers after all. Thank you very much indeed. 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: A new definition of libraries (was: Linux Installation)
Bob Warren wrote: In this thread and the one it arose from, I have not been the slightest bit concerned about discussing the distribution of apps generally in Linux. I have only tried to discuss the distribution of Rev apps. It has now been confirmed again that they do NOT need installing in any normal sense of the word and that standalone means what it says. That's pretty much been the message from all contributions to this thread in my reading of it. I never understood the goal of this thread from the start, but please don't bother explaining it on my account. As for installation, it depends on what one means by that. For a complete user experience, Mac and Windows have a higher standard to meet, with users expecting that an application will not merely run but will also have icons properly set up for the app and its documents, have document associations properly defined, and install a shortcut to itself into the Start menu on OSes that have one. Linux developers have sufficiently lowered expectations there that users don't seem to mind doing much of that manually, something that would never be tolerated on more consumer-minded OSes. While this unnecessarily hampers Linux adoption among consumers, meeting such low expectations can make a developer's life easier. ;) -- 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: A new definition of libraries (was: Linux Installation)
FWIW, this definition proposed by Mark is what I've always thought a standalone app is. Of course, I've not worked inside Linux nor have I attempted to create any apps that run on Linux. If indeed a common set of constant libraries exists for all (or virtually all) Linux distros, then I would say that a Rev app compiled for Linux ought to rely solely on those libraries and on Rev libraries incorporated into the compiled standaloe application explicitly or implicitly. On 6/9/06, Mark Smith [EMAIL PROTECTED] wrote: Maybe it would be helpful to consider a rev-made 'standalone' as simply a stack that does not require the IDE or a separate stackrunner app in order run. -- ~~ Dan Shafer, Information Product Consultant and Author http://www.shafermedia.com Get my book, Revolution: Software at the Speed of Thought From http://www.shafermediastore.com/tech_main.html ___ 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: A new definition of libraries (was: Linux Installation)
Mark Smith wrote: Bob, I think you may be getting hung up on the face-value meaning of the word 'standalone' - Thanks Mark. You might well be right. And indeed I might be making a fundamental mistake somewhere. However, according to my definition, a Rev standalone might belong in Category 2 (with constant libraries), or it might fall into category 3 (i.e. a non-standalone using variable libraries) according to your definition. Is my idea of Rev standalones different to what you have said? Well, yes, if we also count external libraries such as the one you mentioned (e.g. Quicktime which is NOT part of the OS). I wasn't discussing libraries that were not part of the OS. The question that still remains for me (ignoring external libraries) is whether Rev standalones ever really fall into Category 3. The problem in all of this is that if I adopt what might well represent a safe policy in terms of distribution and I presume that all Rev apps should safely be put into Category 3 (non-standalones), then I am condemned to not only having to establish which libraries my application needs in every Linux distro, but also providing an installation or setup to take care of this. At the moment, this seems to be impossible in Linux (at least in practical terms). And in the last analysis, it might not (always or ever?) be strictly necessary. Mark Smith wrote: Which category a Rev standalone belongs in is a question of what it's been designed to do. I think I might have answered that above, Mark. Let's stick to original OS libraries and forget libraries which are introduced through some other subsequent installation process by non-OS software. Also, to avoid further confusion, I suggest we stick to Linux. Mark Smith wrote: There have also been many discussions on this list about the fact that many ISP/Hosting services fail to run Rev CGIs because they haven't installed a particular library. Ken Ray mentioned something similar at the beginning of the Linux Installation thread. Naturally, my discussion is not about such exceptional cases. Although general advice is helpful, it does not solve my problem. I have produced a Rev app which (for the sake of argument) does not write/read its own files to/from the HD and does not require stuff like Quicktime. It runs perfectly on my Ubuntu. How do I know whether it will run on the other 199 Linux distros in a similar fashion? Install all the known Linuxes and try it out? At this point, I have the intuitive feeling that Mr Ken Ray (who has been very quiet for quite a long time now on this particular issue) will zoom in and tell us all what's what - QED fashion. We'll see whether or not my intuitions betray me. 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: A new definition of libraries (was: Linux Installation)
Bob Warren wrote: Mark Smith wrote: Bob, I think you may be getting hung up on the face-value meaning of the word 'standalone' - Thanks Mark. You might well be right. And indeed I might be making a fundamental mistake somewhere. However, according to my definition If it helps, forget the word standalone altogether, because its historical origins with HyperCard (simply meaning a stack that has the engine embedded and doesn't require the IDE) is apparently unsatisfying. Think application instead. Done. If you really like the word standalone then perhaps we can lobby the team leaders of the various incompatible Linux window managers to come up with a single spec, so Linux can at last refer to a single thing rather than a hodge-podge collection of loosely-related parts, thereby making it possible for application developers to write for Linux and know that it'll run well on all the various and wildly different things that distractingly use the same name. -- 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: A new definition of libraries (was: Linux Installation)
Just a quicky in order not to drive anyone nuts. What I am trying to ask is this: I produce a Hello world standalone application in Rev Linux. Will it run without problems on every known Linux? According to an earlier post by Ken Ray, this is confirmed, with the qualification he made about the CGI thing. According to what other people seem to be trying to tell me recently, the answer is Don't bet on it. Or do you think I have boiled it all down too much? 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: A new definition of libraries (was: Linux Installation)
Bob Warren wrote: What I am trying to ask is this: I produce a Hello world standalone application in Rev Linux. Will it run without problems on every known Linux? Linux? Probably, but that means no GUI. If by every you mean every window manager that sits on top of Linux, that's a maybe for Rev just as it is for RB and many others. The problem here is the casual disregard for consistency among the many unrelated window managers. When all but one of them either go away or become relegated to specialized uses, not only with GUI app makers have a much better time writing for it, but the Linux desktop market will at last grow to the levels the kernel deserves. Until then, the mine's-more-precious-than-yours approach to making the unnecessary plethora of window managers that sit on top of Linux is hurting developers' productivity as much as it's hurting their own evangelism of 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: A new definition of libraries (was: Linux Installation)
Let me be clear up front that I am far from a Linux expert. I *am* a KDE user. And the last post here brought me to a point of remembering what a colleague of mine who IS a serious Linux guy told me a couple of weeks ago in another context. Direct quotation: Linux is the only OS for which there are many windowing environments. If Windows had multiple UIs, you'd have the same problem there. You don't. So it's not really proper to discuss 'Linux compatibility.' The issue is KDE compatibility or Gnome compatibility. Within those constraints, an application can be said to run on a particular windowing environment or on multiple windowing environments. But anyone who tells you they have an app that runs on every version of Linux has a very simplistic app or a very simplistic understanding of what constitutes Linux. That makes sense to me. Maybe it doesn't help clarify this discussion, but it makes sense to me. On 6/10/06, Richard Gaskin [EMAIL PROTECTED] wrote: Bob Warren wrote: What I am trying to ask is this: I produce a Hello world standalone application in Rev Linux. Will it run without problems on every known Linux? Linux? Probably, but that means no GUI. If by every you mean every window manager that sits on top of Linux, that's a maybe for Rev just as it is for RB and many others. The problem here is the casual disregard for consistency among the many unrelated window managers. When all but one of them either go away or become relegated to specialized uses, not only with GUI app makers have a much better time writing for it, but the Linux desktop market will at last grow to the levels the kernel deserves. Until then, the mine's-more-precious-than-yours approach to making the unnecessary plethora of window managers that sit on top of Linux is hurting developers' productivity as much as it's hurting their own evangelism of 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 -- ~~ Dan Shafer, Information Product Consultant and Author http://www.shafermedia.com Get my book, Revolution: Software at the Speed of Thought From http://www.shafermediastore.com/tech_main.html ___ 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: A new definition of libraries (was: Linux Installation)
If I may throw a couple cents at the conversation so that things become more clear it might help everyone here. The problem about linux family of operating systems is the library organization of each distro. When you make a standalone, Rev glues stack and engine togheter. The engine is linked against many shared libraries. This is true for all systems. Shared libraries are what makes modern systems easy to develop and also makes our final code smaller since code shared by many applications can be called from those shared libraries instead of being added to the final executable by static linking. The thing about linux is that it is so customizable that each distro (and even many users sharing using the same distro but with different customizations) organized their shared libraries in a different way. Some library that might be placed in one place in a system might be on a different place on other or even missing. The dynamic loader that is responsible for managing this stuff is not magical and can't cope with all kinds of possibilities. Even as libraries changes, users are forced to mantain multiple versions of the library installed so that updating a library will not break any shared code. It's common to find more than one instance of a given library, specially if the library had some heavy change in the last revision. Thats why linux is a mess. Now let us get back to Rev. I've encountered two problems with linux and Rev regarding shared libraries. One is that some older versions of linux come with some outdated glibc (libC) like version X when rev is linked against version Y. That is to say that you must correct the location or version of such library for Rev to run. This is a problem that many CGI users faced. For example some servers of Dreamhost are running on outdated libC. As for the GUI part. I think Rev links against GTK and friends. So you must have GTK (and GDK and the rest of the dependency tree) for it to run. A simple ldd command will display to you which libraries the version of Rev you have are linked against (this is for linux, mac os x users should use otool instead of ldd and windows, I don't have a clue). After seeing which libraries Rev is calling, make sure you have them all installed and in the path rev is looking for. After that Rev should run fine. If you're running a professional distro such as Fedora, running rev might be as simple as double clicking. The procedure displayed here is for troubleshooting a non running rev and not for all users. Andre PS: did it help? I don't use linux for ages... On Jun 10, 2006, at 5:55 PM, Dan Shafer wrote: Let me be clear up front that I am far from a Linux expert. I *am* a KDE user. And the last post here brought me to a point of remembering what a colleague of mine who IS a serious Linux guy told me a couple of weeks ago in another context. Direct quotation: Linux is the only OS for which there are many windowing environments. If Windows had multiple UIs, you'd have the same problem there. You don't. So it's not really proper to discuss 'Linux compatibility.' The issue is KDE compatibility or Gnome compatibility. Within those constraints, an application can be said to run on a particular windowing environment or on multiple windowing environments. But anyone who tells you they have an app that runs on every version of Linux has a very simplistic app or a very simplistic understanding of what constitutes Linux. That makes sense to me. Maybe it doesn't help clarify this discussion, but it makes sense to me. On 6/10/06, Richard Gaskin [EMAIL PROTECTED] wrote: Bob Warren wrote: What I am trying to ask is this: I produce a Hello world standalone application in Rev Linux. Will it run without problems on every known Linux? Linux? Probably, but that means no GUI. If by every you mean every window manager that sits on top of Linux, that's a maybe for Rev just as it is for RB and many others. The problem here is the casual disregard for consistency among the many unrelated window managers. When all but one of them either go away or become relegated to specialized uses, not only with GUI app makers have a much better time writing for it, but the Linux desktop market will at last grow to the levels the kernel deserves. Until then, the mine's-more-precious-than-yours approach to making the unnecessary plethora of window managers that sit on top of Linux is hurting developers' productivity as much as it's hurting their own evangelism of 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:
Re: Linux installation
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
A new definition of libraries (was: Linux Installation)
Some people might think I am flogging a dead horse. In my opinion, the horse is still very much alive, and this fact has enormous consequences for Rev Linux users, not only in theoretical terms but also in terms of practices. According to what has been discussed under the thread Linux Installation, the answer to the question When is a standalone not a standalone? is When it is a Rev application. I have had all kinds of explanations about the history of the term, reminders of my lack of knowledge about what really happens internally in an OS, etc. However, I find myself in a position where the whole business is still as clear as mud, and I don't know what to do in terms of the distribution of my Rev applications for Linux. Let me try introducing a new concept. The terms constant and variable are familiar to us all, but have you ever thought of applying such terms to libraries? According to this idea: a) Constant libraries are contained within an OS (in the case of Linux, probably within the kernel). They are responsible, for example, for the everyday I-O of reading/writing to the file system, and so on. In the case of Linux, such constant libraries are common to all distros. b) Variable libraries within an OS are the ones that can change from time to time, or can be different between one distribution and another. When I tried to define standalones previously, I said more or less what I am going to say now, but without the new terminology. Modified with the terminology, we now have the following hypothetical definitions: Standalone, used to mean what it says rather than in relation to its historical X-Talk significance, means: EITHER: 1) A program which in no way refers to any type of library within the runtime OS OR: 2) A program which depends on constant libraries in the runtime OS only. To these 2 types of program we need to add non-standalones: 3) A program which makes use of variable libraries in the runtime OS. I had hoped that Rev standalones belonged to category 2, not therefore requiring any kind of installation in the normal (e.g. Windows) sense of the term. People tell me theoretically that they belong to category 3 and that they therefore do require a full-blown installation. Since I am not essentially a religious kind of person, I try very hard to believe what people tell me, but unfortunately I need to see things with my own eyes in practice in order to be 100% convinced. So far, nobody has told me of a Rev standalone that cannot be transferred successfully to other distros of Linux (of course, leaving aside the question of different references it might make to the different characteristics of the particular file system). Only time will tell whether Rev standalones really belong in one category or another by this empirical method. Of course, one person who should know about this better than any other is Mark Waddingham, Rev's chief technical officer. Now, an amusing picture conjures itself up in my imagination. There's Kevin with a whip in his hand and there's Mark with beads of sweat on his brow doing his daily debugging. And Mark gingerly raises his right hand and mutters, Can I go for a wee wee-wee?. And the stern reply is Later!. So I won't send any e-mails to Mark, but it would be nice (if ever he gets time to read the UR-List) if he could give us a position as to what the status of the Rev standalones (especially in Linux) is supposed to be. Or perhaps somebody could jump on him at RevCon? How about you, Richard? It's your thread (I didn't steal it - just borrowed it for a while)!! 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: A new definition of libraries (was: Linux Installation)
Bob, I think you may be getting hung up on the face-value meaning of the word 'standalone'. As Jacque pointed out, there really is no such thing in the world of modern personal computers. Maybe it would be helpful to consider a rev-made 'standalone' as simply a stack that does not require the IDE or a separate stackrunner app in order run. 2) A program which depends on constant libraries in the runtime OS only. To these 2 types of program we need to add non-standalones: 3) A program which makes use of variable libraries in the runtime OS. Only time will tell whether Rev standalones really belong in one category or another by this empirical method. Which category a Rev standalone belongs in is a question of what it's been designed to do. What libraries are needed depends entirely on what the stack does. This is not an exclusively Linux issue, and not a Rev issue, either. Many things that people do with Rev (and other development tools) depend on the presence of quicktime, for instance. While quicktime comes as standard on macs, it does not on windows machines. There have been many discussions on this list of how best to deal with that. There have also been many discussions on this list about the fact that many ISP/Hosting services fail to run Rev CGIs because they haven't installed a particular library. So I'd imagine that an app that simply displays some text would work reliably on many different Linux distros, and so would fall into your desired definition of a standalone, but other, more complex apps might not, and so would fall into your undesired category. None of this is peculiar to Revolution, it's simply due to the fact that different distros of Linux exist, which have different 'libraries'. In the terms you have defined, mac and windows tend to have more 'constant' libraries than Linux, whereas Linux tends to have more 'variable' libraries than mac or windows. This makes life a bit harder for Linux developers, whichever language they use. Best, Mark On 10 Jun 2006, at 00:27, Bob Warren wrote: Some people might think I am flogging a dead horse. In my opinion, the horse is still very much alive, and this fact has enormous consequences for Rev Linux users, not only in theoretical terms but also in terms of practices. According to what has been discussed under the thread Linux Installation, the answer to the question When is a standalone not a standalone? is When it is a Rev application. I have had all kinds of explanations about the history of the term, reminders of my lack of knowledge about what really happens internally in an OS, etc. However, I find myself in a position where the whole business is still as clear as mud, and I don't know what to do in terms of the distribution of my Rev applications for Linux. Let me try introducing a new concept. The terms constant and variable are familiar to us all, but have you ever thought of applying such terms to libraries? According to this idea: a) Constant libraries are contained within an OS (in the case of Linux, probably within the kernel). They are responsible, for example, for the everyday I-O of reading/writing to the file system, and so on. In the case of Linux, such constant libraries are common to all distros. b) Variable libraries within an OS are the ones that can change from time to time, or can be different between one distribution and another. When I tried to define standalones previously, I said more or less what I am going to say now, but without the new terminology. Modified with the terminology, we now have the following hypothetical definitions: Standalone, used to mean what it says rather than in relation to its historical X-Talk significance, means: EITHER: 1) A program which in no way refers to any type of library within the runtime OS OR: 2) A program which depends on constant libraries in the runtime OS only. To these 2 types of program we need to add non-standalones: 3) A program which makes use of variable libraries in the runtime OS. I had hoped that Rev standalones belonged to category 2, not therefore requiring any kind of installation in the normal (e.g. Windows) sense of the term. People tell me theoretically that they belong to category 3 and that they therefore do require a full- blown installation. Since I am not essentially a religious kind of person, I try very hard to believe what people tell me, but unfortunately I need to see things with my own eyes in practice in order to be 100% convinced. So far, nobody has told me of a Rev standalone that cannot be transferred successfully to other distros of Linux (of course, leaving aside the question of different references it might make to the different characteristics of the particular file system). Only time will tell whether Rev standalones really belong in one category or another by this empirical method
Re: Linux installation
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 ___ use-revolution mailing
Re: Linux installation
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
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
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
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
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
Linux Installation and Standalones
Hi from Paris, Of course Jacqueline is absolutely correct when she defines Standalones. Unfortunately (or fortunately), many of the people on the forum haven't been around long enough to make that definition. A standalone has no operating system, no libraries, no drivers, no nothing ! You write everything, from the bootstrap to the peripheral drivers, and you run it by booting a peripheral unit. I'm sure many of you will shudder when you realise what that means. When a standalone program ends, the machine stops, with nothing on your screen. Operating systems were invented to launch all the programs, and to remove the hassle of writing all the common routines. The first real operating system I can remember was BOS on the IBM 360/40 in 1965. The first time we saw that, we were absolutely gobsmacked ! Today, Operating Systems are like television. Not many people remember what it was like when we didn't have them ! What most people mean NOW by standalone, in the Rev community, is a stack which does not need a launcher (and function libraries) such as Stack Runner. But even so, you still have all the Operating System functions behind you to do all the dirty work. The only standalone programs I use these days are : 1 - Mac OS X 2 - Windows XP Pause for thought .. -Francis Nothing should ever be done for the first time But happily.. it was ! ___ 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
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
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 tried running your linux standalone on Windows 3.1 and it wouldn't run. Could it be that some OS resources are missing? 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
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
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 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/UxGuide/UXGuide/Home.asp -- 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 g) -- 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 fNil 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
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
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
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 g) -- 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/username/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
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
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
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
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
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
Re: Linux installation
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
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 fNil 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
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 fNil 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 g) -- 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
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
Linux installation
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 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
