 |
JP1 Remotes
|
| View previous topic :: View next topic |
| Author |
Message |
Barf
Expert
Joined: 24 Oct 2008
Posts: 1415
Location: Munich, Germany
|
 Posted: Mon Nov 07, 2011 3:09 pm Post subject: RemoteMaster setup.exe: Making install dir read-only |
 |
|
From other threads:
| gfb107 wrote: | | RM/RMIR expects the current/working directory to be the directory that contains RemoteMaster.jar, protocols.ini, digitmaps.bin and a number of other files and directories. It also expects to have full read/write/execute permission to those files and directories. |
| vicky2003 wrote: | Windows Vista and Window 7 hates it if an app writes information in the "Program Files" sub folders from an app. "Program Files" is a restricted directory. Any changes to the program files directory after installation go in a hidden data stores area. A normal user can't find them, you even a reinstall can't fix them.
I normally don't recommend installing JP1 programs in the Program Files Folder simply because many of the older programs are not Windows 7 compliant and tend to store information in their home folder. |
So I decided to check what was needed to make the program "clean" in this sense. (Not only for Windows 7/Vista: In the Unix/Linux world this has been "good manners" since start of the 1990-ties, "mounting /usr read-only".) To my surprise, code for putting the properties file in a more sane place was, for Windows, already implemented. Fot "other" operating systems, I implemented a fix putting the properties file in the user's home directory, staring with a period, as is the common convention on Unix/Linux. Remains the error output file rmaster.err. I implemented a simple fix, putting it in the "system temporary directory" (java.io.tmpdir), amounts to /tmp on Unix/Linux and %HOME%\AppData\Local\Temp on Windows. Here are the changes:
| Code: | Index: RemoteMaster.java
===================================================================
--- RemoteMaster.java (revision 1077)
+++ RemoteMaster.java (working copy)
@@ -2916,7 +2916,7 @@
try
{
- System.setErr( new PrintStream( new FileOutputStream( new File( workDir, "rmaster.err" ) ) ) );
+ System.setErr( new PrintStream( new FileOutputStream( new File( System.getProperty("java.io.tmpdir"), "rmaster.err" ) ) ) );
}
catch ( Exception e )
{
@@ -2969,9 +2969,15 @@
{
dir.mkdirs();
}
+ propertiesFile = new File( dir, "RemoteMaster.properties" );
}
-
- propertiesFile = new File( dir, "RemoteMaster.properties" );
+ else // not Windows
+ {
+ String baseFolderName = System.getProperty( "user.home" );
+ if (baseFolderName != null && !baseFolderName.isEmpty())
+ dir = new File( baseFolderName );
+ propertiesFile = new File( dir, ".RemoteMaster.properties" );
+ }
}
}
PropertyFile properties = new PropertyFile( propertiesFile );
|
Finally, I wrote an Inno Install script, creating setup.exe file that the Windows users love. Here is the result.
Testing and feedback solicited. |
|
| Back to top |
|
 |
mdavej
Expert
Joined: 08 Oct 2003
Posts: 4501
|
| Posted: Tue Nov 08, 2011 9:57 am Post subject: |
|
|
Excellent work, Barf. It works fine, but I would like to see it assign the proper icon image to the shortcut. We've needed something like this for a long time. Right now, setting up RM or IR is very complicated. I think the ultimate goal should be to include the RDF's, Maps and Images as well and automatically default to the installed RDF and Maps folders. Do you have any thoughts on how to accomplish a truly unified install?
Also, how did you get your RM shortcut to just run RM alone? That's fantastic. I've tried and failed to do that for a long time. |
|
| Back to top |
|
|
gfb107
Expert
Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC
|
|
| Back to top |
|
|
Barf
Expert
Joined: 24 Oct 2008
Posts: 1415
Location: Munich, Germany
|
| Posted: Tue Nov 08, 2011 5:03 pm Post subject: |
|
|
| mdavej wrote: | ... I think the ultimate goal should be to include the RDF's, Maps and Images as well and automatically default to the installed RDF and Maps folders. Do you have any thoughts on how to accomplish a truly unified install?
|
First I tried having maps and rdfs downloaded at the user's request, and installed as a part of the installation. I could not find a clean way to accomplish this, so I gave up, at least temporarily. As an experiment, I just uploaded a new version, which
- contains Maps/Images as well as RDSs, optionally installable in directory Program Files\Common Files\JP1\[rdfs,maps]. (No other location possible.)
- Fixes the icon problem
- Makes file associations optional
- If maps and/or rdfs was installed, a rudimentary properties file will be generated (actually, lines are appended to an existing or nonexisting properties file) so that the user does not have to locate rdf/map files at the first start.
Tell me how you like it.
| Quote: | | Also, how did you get your RM shortcut to just run RM alone? That's fantastic. I've tried and failed to do that for a long time. |
Hardly "fantastic", just "use the source, Luke".
| Quote: | | Barf, why don't you just join the "controlRemote" project at sourceforge? |
Will do, thanx. 
| Quote: |
I take it building the Inno installer package can be automated? |
Inno runs fine non-interactively; thus can be integrated in Makefiles or ant-scripts. I have done this before. Even installers run fine non-interactively. |
|
| Back to top |
|
|
mdavej
Expert
Joined: 08 Oct 2003
Posts: 4501
|
| Posted: Wed Nov 09, 2011 6:04 pm Post subject: |
|
|
| I haven't forgotten about this. But the latest java update seems to have broken all my java apps. I'll try out your new install when I get java working again. |
|
| Back to top |
|
|
xnappo
Expert
Joined: 30 Dec 2003
Posts: 861
|
| Posted: Wed Nov 09, 2011 10:00 pm Post subject: |
|
|
Just a note that what I would *really* like for RDFs/Maps is a system where RM-IR:
1. Gets the signature of the remote
2. Searches for a local match
3. Queries Sourceforge for a match
4. Downloads from Sourceforge if no local match was found, or offer to update if there is a newer version.
Obviously a lot of work, but thought I would throw that in while on the subject
xnappo |
|
| Back to top |
|
|
eferz
Expert
Joined: 03 Jun 2010
Posts: 1078
Location: Austin, Texas
|
| Posted: Wed Nov 09, 2011 11:34 pm Post subject: |
|
|
| xnappo wrote: | Just a note that what I would *really* like for RDFs/Maps is a system where RM-IR:
1. Gets the signature of the remote
2. Searches for a local match
3. Queries Sourceforge for a match
4. Downloads from Sourceforge if no local match was found, or offer to update if there is a newer version.
Obviously a lot of work, but thought I would throw that in while on the subject
xnappo |
I second that motion!
_________________
Remotes; JP1.2: Comcast URC-1067, JP1.3: Insignia NS-RC02U-10A, JP1.4 OARI06G, JP2.1: Cox URC-8820-MOTO (still trying to figure out how to make them self-aware.) |
|
| Back to top |
|
|
gfb107
Expert
Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC
|
| Posted: Thu Nov 10, 2011 8:35 am Post subject: |
|
|
That would be a lot of work, and we have no version information in RDF file names to work with.
I have another idea that might be acceptable.
Java has built-in support for examining and reading ZIP files. It would be fairly simple to enhance RM to read RDFs and Maps/Images directly from zip files (or folders, for people developing RDFs).
Once that is in place, RM could, at startup (and possibly on demand) check if the local .zip files exists or are the latest version. If not, it would ask the user if it is OK to download the latest version from SourceForge or to choose a .zip file or folder to use.
For the automatic version checking to work, we would need to have the version information embedded in the .zip file/folder name in a consistent format.
Thoughts?
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST) |
|
| Back to top |
|
|
eferz
Expert
Joined: 03 Jun 2010
Posts: 1078
Location: Austin, Texas
|
| Posted: Thu Nov 10, 2011 9:03 am Post subject: |
|
|
| gfb107 wrote: | | That would be a lot of work, and we have no version information in RDF file names to work with. |
I would think the first step would for you to indicate how you'd like the nomenclature to be. Taking a look at a few files it seems there's already a parse-able format
| Code: | 30463046 (Cox-URC-7820B JP1.3).rdf
Looks like...
SIGNATURE (Human Readable Name).rdf |
It shouldn't be difficult at all to rename all the files with the last date of acceptance.
| Code: | SIGNATURE DATE (Human Readable Name).rdf
For example, the above with 11/10/2011 date would be.
30463046 20111110 (Cox-URC-7820B JP1.3).rdf |
That would make it simple to use a greater/less than statement on the second word in the filename based on the space delimiter. The logistics would probably require each RDF to exist as a separate downloadable file instead of encapsulating them into one zip archive. But, that would also save in bandwidth usage because of iterative updates.
| gfb107 wrote: | I have another idea that might be acceptable.
Java has built-in support for examining and reading ZIP files. It would be fairly simple to enhance RM to read RDFs and Maps/Images directly from zip files (or folders, for people developing RDFs).
Once that is in place, RM could, at startup (and possibly on demand) check if the local .zip files exists or are the latest version. If not, it would ask the user if it is OK to download the latest version from SourceForge or to choose a .zip file or folder to use.
For the automatic version checking to work, we would need to have the version information embedded in the .zip file/folder name in a consistent format.
Thoughts? |
Seems a lot easier but it sounds like an "all or nothing approach". Wouldn't the unzipping of the files cause it to overwrite all the pre-existing files? I personally would be worried because I had changed quite a few of my RDFs (...or maybe it was protocol.ini) to remove the repeats for Slingbox users.
_________________
Remotes; JP1.2: Comcast URC-1067, JP1.3: Insignia NS-RC02U-10A, JP1.4 OARI06G, JP2.1: Cox URC-8820-MOTO (still trying to figure out how to make them self-aware.) |
|
| Back to top |
|
|
xnappo
Expert
Joined: 30 Dec 2003
Posts: 861
|
| Posted: Thu Nov 10, 2011 9:23 am Post subject: |
|
|
Yes, it would be easy to rename the files to include the version. I think I would just embed the SVN version instead of the date. Still easy enough to parse.
It would also be easy to generate and maintain a list of the current versions so RM-IR could use that as a lookup.
The files are already available as individual files - however I am not sure if there are any restrictions from SourceForge on direct linking to the SVN repository from within a program. I don't think the traffic we generate would be much of a concern...
That said, I have no idea how easy/hard the Java side of this would be.
xnappo |
|
| Back to top |
|
|
gfb107
Expert
Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC
|
| Posted: Thu Nov 10, 2011 10:49 am Post subject: |
|
|
| eferz wrote: |
I would think the first step would for you to indicate how you'd like the nomenclature to be. Taking a look at a few files it seems there's already a parse-able format
| Code: | 30463046 (Cox-URC-7820B JP1.3).rdf
Looks like...
SIGNATURE (Human Readable Name).rdf |
It shouldn't be difficult at all to rename all the files with the last date of acceptance.
| Code: | SIGNATURE DATE (Human Readable Name).rdf
For example, the above with 11/10/2011 date would be.
30463046 20111110 (Cox-URC-7820B JP1.3).rdf |
That would make it simple to use a greater/less than statement on the second word in the filename based on the space delimiter. The logistics would probably require each RDF to exist as a separate downloadable file instead of encapsulating them into one zip archive. But, that would also save in bandwidth usage because of iterative updates. |
We have to be carefull about changing the names of RDF files, as it might cause incompatibilities with other tools that use RDFs, primarily IR. Maybe IR won't have a problem with naming conventions, but maybe it will. I don't know.
Doing it at the individual RDF level is almost building an SVN client into RM.
| Quote: | | gfb107 wrote: | I have another idea that might be acceptable.
Java has built-in support for examining and reading ZIP files. It would be fairly simple to enhance RM to read RDFs and Maps/Images directly from zip files (or folders, for people developing RDFs).
Once that is in place, RM could, at startup (and possibly on demand) check if the local .zip files exists or are the latest version. If not, it would ask the user if it is OK to download the latest version from SourceForge or to choose a .zip file or folder to use.
For the automatic version checking to work, we would need to have the version information embedded in the .zip file/folder name in a consistent format.
Thoughts? |
Seems a lot easier but it sounds like an "all or nothing approach". Wouldn't the unzipping of the files cause it to overwrite all the pre-existing files? I |
With this approach I wouldn't unzip at all. The RDFs would be read directly from the .zip file. But, yes, it is sort of "an all or nothing" solution.
An enhancement to this idea would be to have a 'work' folder that is checked for files before looking in the zip file. This is where people could keep custom or under-development files. RM would never replace files in this 'work' folder.
| Quote: | | personally would be worried because I had changed quite a few of my RDFs (...or maybe it was protocol.ini) to remove the repeats for Slingbox users. |
That sounds like protocols.ini.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)
Last edited by gfb107 on Thu Nov 10, 2011 4:43 pm; edited 1 time in total |
|
| Back to top |
|
|
gfb107
Expert
Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC
|
| Posted: Thu Nov 10, 2011 11:31 am Post subject: |
|
|
| xnappo wrote: |
Yes, it would be easy to rename the files to include the version. I think I would just embed the SVN version instead of the date. Still easy enough to parse.
It would also be easy to generate and maintain a list of the current versions so RM-IR could use that as a lookup.
The files are already available as individual files - however I am not sure if there are any restrictions from SourceForge on direct linking to the SVN repository from within a program. I don't think the traffic we generate would be much of a concern...
That said, I have no idea how easy/hard the Java side of this would be.
xnappo |
Looks like pulling files directly out of SVN is pretty easy.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST) |
|
| Back to top |
|
|
eferz
Expert
Joined: 03 Jun 2010
Posts: 1078
Location: Austin, Texas
|
| Posted: Thu Nov 10, 2011 12:13 pm Post subject: |
|
|
| gfb107 wrote: | | Looks like pulling files directly out of SVN is pretty easy. |
Woo hoo!
_________________
Remotes; JP1.2: Comcast URC-1067, JP1.3: Insignia NS-RC02U-10A, JP1.4 OARI06G, JP2.1: Cox URC-8820-MOTO (still trying to figure out how to make them self-aware.) |
|
| Back to top |
|
|
Barf
Expert
Joined: 24 Oct 2008
Posts: 1415
Location: Munich, Germany
|
| Posted: Thu Nov 10, 2011 1:41 pm Post subject: |
|
|
Embedding a svn-client should not be a very difficult matter. I have been using Netbeans which comes with its own svn-client for example. Googling for "java svn client api" gives several hits.
Mapping of signatures to URLs: Best thing would be to have the signature determine the URL/filename uniquely, without any "readability cruft". This is probably not do-able for practical reasons. So instead a solution with a catalog file, e.g. in XML format, is easily suggested. This provides the mapping from signatures to either svn-Urls or local filenames. Something like:
| Code: |
<remote-file-mappings>
<admindata>
<!-- Version of this file, etc -->
...
</admindata>
<remote signature="12345678" rdf="http://controlremote.svn.sourceforge.net/.../long and silly name.rdf" map="http://controlremote..../.../another silly name.map" image="http://controlremote.../imagefile.jpg"/>
...
<remote signature="87654321" rdf="http://controlremote.svn.sourceforge.net/.../even longer and sillier name.rdf" map="http://controlremote..../.../yet another silly name.map" image="http://controlremote.../another imagefile.jpg"/>
</remote-file-mappings>
|
This file should be reside in the svn-repository, with a simple, not changing name, so that a program can download it. As a fallback, it would be sensible to compile the current version into the RM program itself, for fallback when the internet connection is not working. For opimization, the catalog file may be saved to disk between sessions. And/or subject to version updates like rdf files.
And please, please, no versions in file names, it will break "everything". Better to use the facilities svn offers. And no zip files.
So, when the user downloads a remote the following happens. Lets assume that RDF is a local directory, setup as a svn local workarea for RDF files. Pseudocode:
| Code: |
signature = downloadRemote;
if $RDF/localfile(signature) present
status = svn.status($RDF/localfile(signature))
if status == new_file
user_message("using a local file not in svn")
else if status == locally_modified
user_message("using a locally modified rdf file.)
else if status == conflicts
user_message("conflicts between local file and svn detected. Resolve manually.")
else if status == outdated
answer = user_query("new version of your RDF file exists. download?")
if answer == yes
svn.update(RDF/localfile(signature))
else if status == ok
// do nothing
else // no local file present
exists = svn.file_present(url(signature))
if exists
answer = user_query("wanna download rdf?")
if answer == "yes"
svn.checkout(url(signature))
else
user_message("Outta luck with your remote. Ask the friendly guys at hifi-remote.com for help.")
go on using $RDF/localfile(signature)
...
|
The handling of map- and image files I leave as exercise for the reader. 
When the user selects "New image..." the following happens:
| Code: |
try
catalog_file = download(catalog_URL)
catch
// download fails
catalog_file = compiled_in_fallback;
setup pulldown menu of available remotes according to catalog_file
continue as in the download case
|
Of course, there should be a user option for disallowing internet downloads completely. Also, there may be an option "check only once per day/week/month/..."
Returning to setup routines, there may be an alterative in the setup program just to create empty directories for RDFs, maps, and images; then later to download on demand.
When it comes to protocols.ini, digimaps.bin,... then ... ...
Should not be too hard to implement this really...  |
|
| Back to top |
|
|
gfb107
Expert
Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC
|
| Posted: Fri Nov 11, 2011 8:34 am Post subject: |
|
|
I suppose including an SVN client in RM wouldn't be a big deal.
If we go down this route, I think we would want to make sure only 'official' or 'released' versions of RDFs, maps, and images ever make it to the trunk. This way RM always looks in trunk for the latest version, and doesn't have to know about any tags or branches.
When putting files that aren't ready for distribution into SVN, a branch should be created (with trunk as the source) where those files are kept and revised until they are ready for release. At that point the branch is merged back into trunk, and would be picked up the next time RM checks for updates.
Using SVN would also allow RM to detect if any unofficial RDFs are being used. Don't yet know if or what we'd want to do in that case, but the capability is there.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST) |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
File Section
Wiki
