From: Jim L. <jc...@au...> - 2009-06-20 08:05:05
|
I've been looking though the tutorials and program examples which I have been able to find that explain/example writing simple ROX apps. But the info I have found all uses Python. Unfortunately, I have no knowledge of Python, and almost all my programming in the last decade or two is in 'C'. (With some tiny amounts of C++ or Java.) So I'd much prefer to work in C. This would also make it easier if I want to port across some of the work I've already done for RO apps. Are there any tutorials or simple examples I can read of ROX Apps in C? My interest initially is to be able to do a few simple things like. Have the app open up a terminal window so I can get it to print text there or accept input I type in. This will let me experiment and ensure I can communicate, see if it can find environmental variables, etc, etc. Then Experiment with C programs that use GTK, or some other method so I can use drag and drop for input and output. Slainte, Jim -- Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html Audio Misc http://www.audiomisc.co.uk/index.html |
From: Jim L. <jc...@au...> - 2009-06-20 11:25:36
|
On 20 Jun, jc...@au... wrote: >[snip] > Have the app open up a terminal window so I can get it to print text > there or accept input I type in. This will let me experiment and ensure > I can communicate, see if it can find environmental variables, etc, etc. To clairify/simplify my question I can give the following example. I create a new directory called "HelloWorld". Inside it I write the traditional 'Hello World' c file that I compile with gcc. This gives me a compiled executable file called, with amazing orginality, 'RunImage' inside the HelloWorld directory. :-) If I start up a terminal (e.g. xfce4-terminal) and cd to HelloWorld I can run the RunImage file by typing "/.RunImage" and it then prints 'Hello World!" in the terminal. No problem. But what would I put into the AppRun file to cause the HelloWorld application directory to open a terminal, and run the file, so displaying the message? Sorry if this is a very idiotic question, but it is many years since I have used Linux/UNIX. The books I have on C don't mention this. Nor, so far as I can find, do the ones on Linux. I can simply ignore this and use something like GTK since - I assume (?) - that I can then just put the compiled executable in place as AppRun. But I'd prefer to understand and be able to do the above first. I'd like to proceed on a 'step by step' basis so I can understand what is happening. Slainte, Jim -- Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html Audio Misc http://www.audiomisc.co.uk/index.html |
From: Thomas L. <ta...@gm...> - 2009-06-20 13:00:04
|
2009/6/20 Jim Lesurf <jc...@au...>: > On 20 Jun, jc...@au... wrote: >>[snip] > >> Have the app open up a terminal window so I can get it to print text >> there or accept input I type in. This will let me experiment and ensure >> I can communicate, see if it can find environmental variables, etc, etc. > > To clairify/simplify my question I can give the following example. > > I create a new directory called "HelloWorld". Inside it I write the > traditional 'Hello World' c file that I compile with gcc. This gives me a > compiled executable file called, with amazing orginality, 'RunImage' inside > the HelloWorld directory. :-) > > If I start up a terminal (e.g. xfce4-terminal) and cd to HelloWorld I can > run the RunImage file by typing "/.RunImage" and it then prints 'Hello > World!" in the terminal. No problem. > > But what would I put into the AppRun file to cause the HelloWorld > application directory to open a terminal, and run the file, so displaying > the message? Run xterm in the AppRun. e.g. exec xterm -hold -e `dirname $0`/RunImage "$@" -- Dr Thomas Leonard ROX desktop / Zero Install GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Jim L. <jc...@au...> - 2009-06-20 15:58:57
|
In article <cd5...@ma...>, Thomas Leonard <ta...@gm...> wrote: > > > > But what would I put into the AppRun file to cause the HelloWorld > > application directory to open a terminal, and run the file, so > > displaying the message? > Run xterm in the AppRun. e.g. > exec xterm -hold -e `dirname $0`/RunImage "$@" Excellent! Thanks! :-)) I felt sure the command would involve something like xterm -e, but my problem at present is that I tend to get puzzled about syntax, so wasn't able to work out how the portion after that should be constructed. Kept experimenting, but no success until you gave the above. Now works fine! Using the above I can now click on the app directory and it opens the xterm, and runs the program. Using argc and argv I can now also pick up the path and filenames when I drag and drop a file onto the app. If system() works as I hope, the next step will be to automate gcc compiling of 'RunImages' by drag and drop. The aim being to have editor, terminal, and gcc on the icon bar and picking up the relevant paths by drag and drop, to make further work simpler. :-) Having got the above working I also added -fn with a bigger font onto the command as my eyesight is lousy. Thanks again. :-) Sorry I am so new and dim at this, your patience is appreciated. Jim -- Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html Audio Misc http://www.audiomisc.co.uk/index.html |
From: Tony H. <h...@re...> - 2009-06-22 16:26:15
|
On Sat, 20 Jun 2009 16:59:03 +0100 Jim Lesurf <jc...@au...> wrote: > In article > <cd5...@ma...>, > Thomas Leonard <ta...@gm...> wrote: > > > Run xterm in the AppRun. e.g. > > > exec xterm -hold -e `dirname $0`/RunImage "$@" > > Excellent! Thanks! :-)) I felt sure the command would involve something > like xterm -e, but my problem at present is that I tend to get puzzled > about syntax, so wasn't able to work out how the portion after that should > be constructed. Kept experimenting, but no success until you gave the > above. Now works fine! You might prefer to use xfce's terminal (I can't remember what the command's called, but ISTR xfce does have its own terminal) or ROXTerm so you can have nicer fonts and set up options without having to specify them on the command line every time. If you use ROXTerm, download the tarball and use it as a ROX app, the version that comes with Ubuntu is out of date. > Using the above I can now click on the app directory and it opens the > xterm, and runs the program. Using argc and argv I can now also pick up the > path and filenames when I drag and drop a file onto the app. If system() > works as I hope, the next step will be to automate gcc compiling of > 'RunImages' by drag and drop. The aim being to have editor, terminal, and > gcc on the icon bar and picking up the relevant paths by drag and drop, to > make further work simpler. :-) The Unix way is to run the compiler (usually via make) from the text editor so that the editor can see the error messages and let you select them, rather like Throwback in RISC OS. I'm not sure whether any of the mainstream editors have anything as convenient to use as Throwback (vim's compiler error browsing is very klunky in comparison). My own vixn does, but you probably won't want to learn a vi-like editor at this point! -- TH * http://www.realh.co.uk |
From: Tony H. <h...@re...> - 2009-06-22 16:33:52
|
On Sat, 20 Jun 2009 12:18:50 +0100 Jim Lesurf <jc...@au...> wrote: > I can simply ignore this and use something like GTK since - I assume (?) - > that I can then just put the compiled executable in place as AppRun. But > I'd prefer to understand and be able to do the above first. I'd like to > proceed on a 'step by step' basis so I can understand what is happening. Even with GTK it's normal to use a shell script for AppRun with some common options eg --compile. The scripts are also usually responsible for automatically compiling applications when they're run for the first time. Just find one that seems vaguely similar to what you want to write, pinch its AppRun and adapt it if necessary. You'll probably find that most ROX C apps use a script based on whatever was one of the first that Thomas wrote. Open source :-). -- TH * http://www.realh.co.uk |
From: Thomas L. <ta...@gm...> - 2009-06-22 18:40:21
|
2009/6/22 Tony Houghton <h...@re...>: [...] > You'll probably find > that most ROX C apps use a script based on whatever was one of the first > that Thomas wrote. Open source :-). Yes, the joys of cut-and-paste programming :-/ When I did the original scripts I was using various university machines (x86, sparc, etc) with an NFS shared home directory. I didn't have root anywhere, and packaging systems back then didn't work for ordinary users. That meant:that the build system had to be bundled with the software (there was no dependency handling for software outside of the repositories), which also meant it had to be quite primitive. There are now several variations on the build system: - ROX-CLib uses the original system, generating multiple binaries inside a single application directory. It doesn't work on mixed 32- and 64-bit systems. On these systems, both types of binary can run, but you can't mix them in a single process. i.e. if a 32-bit application uses ROX-CLib then it needs the 32-bit binary. If a 64-bit application uses the same library on the same computer, it needs the 64-bit binary. - A patched version of ROX-CLib drops most of the built-in build code and contains code just to build a single binary. An external build tool (0compile) takes the source application directory and generates a new application directory for each architecture it is compiled for. This works with complex systems (e.g. 32 and 64 bit mixed), but does require an external build tool. - ROX-Filer has two build systems. The user can either use 0compile to create one binary per architecture, or run the AppRun script directly to generate a single binary. - Some other programs dispense with using an application directory at all for the source or binary, and look just like traditional Unix builds. External tools like AddApp or Zero2Bundle automatically turn the result into a ROX application directory as it is installed, while users of other desktops use other installers which integrate it in other ways. I'd probably use this for programs where you don't want to limit the audience to ROX users. HTH, -- Dr Thomas Leonard ROX desktop / Zero Install GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Tony H. <h...@re...> - 2009-06-22 20:32:50
|
On Mon, 22 Jun 2009 19:39:19 +0100 Thomas Leonard <ta...@gm...> wrote: > There are now several variations on the build system: > > - ROX-CLib uses the original system, generating multiple binaries > inside a single application directory. It doesn't work on mixed 32- > and 64-bit systems. On these systems, both types of binary can run, > but you can't mix them in a single process. i.e. if a 32-bit > application uses ROX-CLib then it needs the 32-bit binary. If a 64-bit > application uses the same library on the same computer, it needs the > 64-bit binary. I don't understand what you mean. Why would you want to mix 32-bit and 64-bit versions of the same library in a single process? > - A patched version of ROX-CLib drops most of the built-in build code > and contains code just to build a single binary. An external build > tool (0compile) takes the source application directory and generates a > new application directory for each architecture it is compiled for. > This works with complex systems (e.g. 32 and 64 bit mixed), but does > require an external build tool. > > - ROX-Filer has two build systems. The user can either use 0compile to > create one binary per architecture, or run the AppRun script directly > to generate a single binary. > > - Some other programs dispense with using an application directory at > all for the source or binary, and look just like traditional Unix > builds. External tools like AddApp or Zero2Bundle automatically turn > the result into a ROX application directory as it is installed, while > users of other desktops use other installers which integrate it in > other ways. I'd probably use this for programs where you don't want to > limit the audience to ROX users. ROXTerm uses another strategy that I think deserves a mention. It compiles and installs (scattering itself under /usr/local or wherever) with the standard "autotools" so it works with GNOME etc. But installation is optional. It can be run in place with the AppRun script passing it a --appdir option telling it where to find its data files instead of the compiled-in ${prefix}. This could probably also have been combined with one of the multi-arch strategies as above, but getting that to fit in with automake might have been "challenging" and I didn't think there was a demand for it. -- TH * http://www.realh.co.uk |
From: Thomas L. <ta...@gm...> - 2009-06-23 07:28:40
|
2009/6/22 Tony Houghton <h...@re...>: > On Mon, 22 Jun 2009 19:39:19 +0100 > Thomas Leonard <ta...@gm...> wrote: > >> There are now several variations on the build system: >> >> - ROX-CLib uses the original system, generating multiple binaries >> inside a single application directory. It doesn't work on mixed 32- >> and 64-bit systems. On these systems, both types of binary can run, >> but you can't mix them in a single process. i.e. if a 32-bit >> application uses ROX-CLib then it needs the 32-bit binary. If a 64-bit >> application uses the same library on the same computer, it needs the >> 64-bit binary. > > I don't understand what you mean. Why would you want to mix 32-bit and > 64-bit versions of the same library in a single process? You wouldn't, but whatever selects the version of ROX-CLlib to use has to know this rule, which my old scripts don't. -- Dr Thomas Leonard ROX desktop / Zero Install GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Jim L. <jc...@au...> - 2009-06-23 09:06:40
|
In article <200...@re...>, Tony Houghton <h...@re...> wrote: > On Sat, 20 Jun 2009 16:59:03 +0100 Jim Lesurf <jc...@au...> > wrote: > You might prefer to use xfce's terminal (I can't remember what the > command's called, but ISTR xfce does have its own terminal) or ROXTerm > so you can have nicer fonts and set up options without having to specify > them on the command line every time. Yes. Agreed. FWIW I have been using xfce4-terminal up until starting to use xterm for my ROX experiments. Indeed, whilst experimenting with ROX I have often had both an xfce terminal and an xterm window up at the same time. :-) The snag was that I wasn't able to find the relevant commands for telling the xfce terminal to run the executable, etc, as I now can with xterm. Xterm seems to have a man page as-long-as-yer-arm, but I didn't know how to use the xfce terminal for this purpose. I do plan to try getting it to work, but I assume that if I ever make an app available for other xterm will be a safer choice as it is more likely to be available on a range of distros (?) Presumably, though, I can setup the defaults I want for xterm in a settings file that gets read at bootup. I am wondering about this and giving it the alias or name 'TaskWindow'... :-) > If you use ROXTerm, download the tarball and use it as a ROX app, the > version that comes with Ubuntu is out of date. Can you summarise what differences that would make? i.e. what limitations the 'out of date' version has? > > Using the above I can now click on the app directory and it opens the > > xterm, and runs the program. Using argc and argv I can now also pick > > up the path and filenames when I drag and drop a file onto the app. If > > system() works as I hope, the next step will be to automate gcc > > compiling of 'RunImages' by drag and drop. The aim being to have > > editor, terminal, and gcc on the icon bar and picking up the relevant > > paths by drag and drop, to make further work simpler. :-) > The Unix way is to run the compiler (usually via make) from the text > editor so that the editor can see the error messages and let you select > them, rather like Throwback in RISC OS. I'm not sure whether any of the > mainstream editors have anything as convenient to use as Throwback > (vim's compiler error browsing is very klunky in comparison). My own > vixn does, but you probably won't want to learn a vi-like editor at this > point! I haven't yet got into 'vi* versus *emacs' concerns. On RISC OS I avoid such theological arguments by using DeskEdit, not Zap or StrongED. 8-] In article <200...@re...>, Tony Houghton <h...@re...> wrote: > On Sat, 20 Jun 2009 09:06:08 +0100 Jim Lesurf <jc...@au...> > wrote: > > > > Are there any tutorials or simple examples I can read of ROX Apps in C? > Writing in C is fine, but you *need* to learn (Bourne) shell if you're > going to develop in Linux/Unix. Yes. Agreed. This is something else I am trying to do at present. My main problem is the "so much to do, so little time" syndrome, linked to my lack of skill and being distracted by 'real life'. :-/ FWIW I am not really aiming to 'develop' any apps in a serious sense. Just that I may try to produce ROX versions of some of my RO '!Track' series. They just pop up and run in TaskWindows. I may end up with a crude GTK interface. The aim is partly to use them myself, but also as teaching and learning exercises which others would be welcome to use (or turn into decent apps!) if they so wished. Also, perhaps, as something to use for articles in 'Archive' that may increase reader awareness of ROX. Above said, at the moment I am just playing and exploring, so no idea if the above makes sense or will come to pass! :-) Slainte, Jim -- Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html Audio Misc http://www.audiomisc.co.uk/index.html |
From: Tony H. <h...@re...> - 2009-06-23 12:05:25
|
On Tue, 23 Jun 2009 09:26:54 +0100 Jim Lesurf <jc...@au...> wrote: > In article <200...@re...>, Tony Houghton > <h...@re...> wrote: > > On Sat, 20 Jun 2009 16:59:03 +0100 Jim Lesurf <jc...@au...> > > wrote: > > > > You might prefer to use xfce's terminal (I can't remember what the > > command's called, but ISTR xfce does have its own terminal) or ROXTerm > > so you can have nicer fonts and set up options without having to specify > > them on the command line every time. > > Yes. Agreed. FWIW I have been using xfce4-terminal up until starting to > use xterm for my ROX experiments. Indeed, whilst experimenting with ROX I > have often had both an xfce terminal and an xterm window up at the same > time. :-) > > The snag was that I wasn't able to find the relevant commands for telling > the xfce terminal to run the executable, etc, as I now can with xterm. > Xterm seems to have a man page as-long-as-yer-arm, but I didn't know how > to use the xfce terminal for this purpose. I do plan to try getting it to > work, but I assume that if I ever make an app available for other xterm > will be a safer choice as it is more likely to be available on a range of > distros (?) xfce terminal probably uses -e too. IME xterm isn't necessarily installed by default, but it probably would be on a system that hasn't been messed about with as much as mine. when presented with a list of packages due for update which is full of dozens of packages I never use that come as part of a complete "distro" or "GNOME desktop" I tend to uninstall them, which can make other things go missing :-). On Debian based systems, x-terminal-emulator is your best bet. > Presumably, though, I can setup the defaults I want for xterm in a settings > file that gets read at bootup. I am wondering about this and giving it the > alias or name 'TaskWindow'... :-) xterm uses the ancient Xresources system, which means if you want its settings to load automatically you either have to alter your xinit scripts or make it share a file with other elderly programs (for example tkinfo, which is pretty horrible, making it several times better than any other info reader). ROXTerm and gnome-terminal use named profiles. > > If you use ROXTerm, download the tarball and use it as a ROX app, the > > version that comes with Ubuntu is out of date. > > Can you summarise what differences that would make? i.e. what limitations > the 'out of date' version has? It's more a long list of trivial things than anything very major, not easy to summarise concisely. I'd have to ask you to download it and look at the ChangeLog (since version 1.12.2). [Snip] > FWIW I am not really aiming to 'develop' any apps in a serious sense. Just > that I may try to produce ROX versions of some of my RO '!Track' series. > They just pop up and run in TaskWindows. I may end up with a crude GTK > interface. The aim is partly to use them myself, but also as teaching and > learning exercises which others would be welcome to use (or turn into > decent apps!) if they so wished. Also, perhaps, as something to use for > articles in 'Archive' that may increase reader awareness of ROX. You should probably think about writing your own TaskWindow using vte, which is a complete terminal emulator encapsulated in a GTK widget. The terminal runs itself really; the bulk of the code in ROXTerm and gnome-terminal etc is concerned with providing a nice UI for configuring it and managing the multiple tabs. -- TH * http://www.realh.co.uk |
From: Jim L. <jc...@au...> - 2009-06-23 16:07:49
|
In article <200...@re...>, Tony Houghton <h...@re...> wrote: > On Tue, 23 Jun 2009 09:26:54 +0100 Jim Lesurf <jc...@au...> > wrote: > > The snag was that I wasn't able to find the relevant commands for > > telling the xfce terminal to run the executable, etc, > xfce terminal probably uses -e too. I'd tried it with '-e' but had no joy. However just tried it again and xfce4-terminal didn't respond to '-e' but *does* work with '--execute'. So I guess it is slightly more fussy about syntax than xterm. :-) > IME xterm isn't necessarily installed by default, but it probably would > be on a system that hasn't been messed about with as much as mine. when > presented with a list of packages due for update which is full of dozens > of packages I never use that come as part of a complete "distro" or > "GNOME desktop" I tend to uninstall them, which can make other things go > missing :-). As a newbie I am trying to keep to the synaptic packages as much as I can to avoid giving myself problems I'm too dim to solve. No doubt I'll chance my arm a bit more later. No doubt in due course I'll also risk trying distros other than Ubuntu/Xubuntu, but at present their 'user friendly' approach is helping me to focus on learning about other things. FWIW I last tried Linux about 8 years ago, and did also try ROX then. But I didn't have any specific use for Linux at the time, and did get into a muddle. Partly maybe because the laptop I'm using (same as then) is a bit creaky. But mainly I assume because I was/am clueless and even Red Hat of those days was a bit too puzzling for me. Since I didn't have a need for it then I abandoned it. But now I have good reasons to use Linux, and do like the idea of using ROX, so I will persist. [snip useful info] > You should probably think about writing your own TaskWindow using vte, > which is a complete terminal emulator encapsulated in a GTK widget. The > terminal runs itself really; the bulk of the code in ROXTerm and > gnome-terminal etc is concerned with providing a nice UI for configuring > it and managing the multiple tabs. Thanks. I'll investigate when I can. At present being able to use the xfce terminal suits OK. But the above looks useful for the future. Slainte, Jim -- Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html Audio Misc http://www.audiomisc.co.uk/index.html |
From: Tony H. <h...@re...> - 2009-06-22 17:17:11
|
On Sat, 20 Jun 2009 09:06:08 +0100 Jim Lesurf <jc...@au...> wrote: > I've been looking though the tutorials and program examples which I have > been able to find that explain/example writing simple ROX apps. But the > info I have found all uses Python. Unfortunately, I have no knowledge of > Python, and almost all my programming in the last decade or two is in 'C'. > (With some tiny amounts of C++ or Java.) So I'd much prefer to work in C. > This would also make it easier if I want to port across some of the work > I've already done for RO apps. > > Are there any tutorials or simple examples I can read of ROX Apps in C? Writing in C is fine, but you *need* to learn (Bourne) shell if you're going to develop in Linux/Unix. Imagine trying to program RISC OS without knowing Obey or BASIC! Python is useful if you want to tweak your ROX experience and it's a great language in its own right anyway. You'll probably find yourself just as at home with it as with C very quickly, but it's far more powerful and scalable than BASIC despite being pretty easy to learn. Despite having quite a different syntax from C, its C underpinnings/heritage are out in the open and its libraries (including GTK) are nicely analogous with the C equivalents. -- TH * http://www.realh.co.uk |