Application: RSSOwlCategory: InternetDescription: RSSOwl Portable is the popular RSSOwl news/RSS aggregator packaged with a PortableApps.com Launcher as a portable app, so you can work with news feeds from an iPod, USB flash drive, portable hard drive, CD or any other portable media. It has all the same great features as RSSOwl including OPML support, bookmarks, blogrolls and more. Plus, it leaves no personal information behind on the machine you run it on, so you can take your news aggregator wherever you go.Download RSSOwl Portable 2M9 Development Test 4 [15.9MB download / 18.6MB installed]
(MD5: 99b68581de331ea1a8a97ead6e009f21)
Release Notes:
Development Test 4 (2009-07-21):
- Updated launcher to correctly pass Additional Parameters from the ini file.
Development Test 3 (2009-06-01):
- Updated launcher for a typo. Please check your installation and ensure that you don't have a folder called "RSSOwl}" under your RSSOwlPortable\App\ folder.
Development Test 2 (2009-05-19):
- Updated the ini, readme, and other files to include RSSOwl as the app name instead of KVIrc.
- Updated the launcher to correctly pass the -vm switch.
- Also updated the launcher to use Java Portable if it exists instead of the local java first.
Development Test 1 (2009-05-15): Initial release
- Thanks for all the help from fellow Devs
- Thanks in advance for testing!!
Notes:
- This app REQUIRES Java 1.5 minimum to run. This will use Java Portable before a local instance by default. If you have Java Portable installed, Java on the local machine is not required.
- App has been tested on XP Pro SP3 with both admin and limited/guest accounts.
Enjoy!!
Woo-hoo! I love RSS. I usually use NFReader, but I'll definitely give this a try. *high-fives Gizmokid2005*
for a good rss reader the other day and nobody could give me a suggestion but this...I've been using it and love it. Thought I'd spread the love
Your launcher has a bug as it searches for Java Portable in $EXEDIR, but not in the default common files directory, try getting the root and give path manually in your code on line 94.
The final edited and tested code for the Java Portable:
lines:93-97
${GetRoot} "$exedir" $R0
StrCpy $DRIVELETTER $R0 1
UsePortableVM:
StrCpy $EXECSTRING `"$PROGRAMDIRECTORY\$PROGRAMEXECUTABLE" -vm "$DRIVELETTER:\PORTABLE APPS\COMMON FILES\Java\bin"`
While I've been using brief recently I still have something of a soft spot for RSSOwl. I used it a little bit and it worked fine.
One thing I would say, is it possible to make it use Java in CommonFiles as I'd rather not have multiple copies?
Keep up the good work
John is working on a portable version of java, so RSSOwl's launcher and settings will eventually change depending on what happens there.
And there might be a way to change it in the config for RSSOwl itself.
**EDIT - 5 mins later**
You can use this thread to help you. Just set the -vm additional launch parameter with your Java path and it will use it.
http://sourceforge.net/forum/forum.php?thread_id=3109453&forum_id=296910
Great addition to the PA portfolio! Thanks.
Have installed Java Portable and RSSOwl on a portable device and want to direct RSSOwl to use only that JVM. Adding the -vm launch parameter as described in the thread you reference involves a known, fixed drive letter. How would you adjust parameters for a drive letter that varies? Is there a relative drive variable, or similar method, that the RSSOwl launcher will parse in order to explicitly use the portable JVM, rather than a local JVM, when the assigned portable device drive letter changes?
RSSOwl by default with use the PortableJava if it's available. I took this precaution when setting up the launcher. So if you have Java Portable installed, RSSOwl will use it without any work needed on your part
Use the location for Java Portable. It should not require or use an install on the local machine. Whatever we do packaging wise, it'll be at the current location of Java Portable.
Sometimes, the impossible can become possible, if you're awesome!
I'll test it as that's just what I've been looking for! Your app is just in time!
To Dev Test 2. See Release Notes for details!
I've been using this daily since DT2 came out, and I haven't come across any issues with it whatsoever. Very nice!
for the report!! I haven't noticed anything either, besides the minor glitch here and there in the actual app. Keep me posted!
to DT3
Still using daily, still working great. I have a question though. This isn't a portable issue, it's with the program itself. I noticed that RSSOwl uses Internet Explorer to internally display feeds. I was wondering if maybe someone knew of a way to point it to another browser (one on the portable drive) to display pages instead, like choosing the portable browser to open pages in when clicked.
I noticed that too...I'll bring it up to the guys over there and see if there is a way they can add that as a feature or if it's too deep into the code.
In the Preferences > Miscellaneous - Top option is Browser, you can specify a browser here for it's engine I hadn't looked/noticed it before. Try that and it should. work, I'm going to do the same.
-Gizmokid2005
PS - I did it, but it doesn't look like it actually changes the internal viewing engine, it just opens the feeds in the external app specified.
Yeah, I tried that too. It uses Iron as the external browser, but does nothing internally. lol
I've also been noticing lately that this program leaves all temporary internet files from feeds behind. Is there a way to delete them on close?
Where does it leave them? In the Temp folder? If so, not really, unless the names are the same every time.
Yeah. In the Temporary Internet Files folder.
I don't think we can clear that out, but I'll look into it.
Afaik, FFP uses that too, I believe, but I could very well be wrong. Unless anyone knows a way around it, I don't think there is one.
clearing your cache and closing all other apps that use it and try again. The main dev said that RSSOwl does NOT use temp files when displaying a feed. AND there is a way to use xulrunner (firefox) as the internal browser, though it isn't pretty, and I probably won't be implementing it in the portable version as that would cause issues with both support here and there.
So let me know onestoploser - whether or not the temp files were really left behind by RSSOwl. I will check again myself in my VM later.
Ok. I deleted all my temporary internet files and opened RSSOwl. I read quite a few feeds, most of them with images in them. When I checked back in on my temporary internet files folder it was full of stuff; mostly images from the feeds. I didn't have any other apps open at the time.
I'm thinking maybe RSSOwl doesn't necessarily use temporary files, but IE does. Is it using my local IE install to display feeds?
Thanks.
I've reported it. I haven't tested it myself, but we'll see what I come up with. It does currently use the IE internal engine to display feeds.
I've been using it since Test 1 and so far I haven't had any problems with either version...
EDIT: A problem just happened.
The app won't run - when I click on it - it opens and briefly after this - closes. It doesn't go past the initial green square. I don't know where's the problem. It all worked OK until today. When I opened it - it said something about updating or cleaning its database and closed itself after a while. And it doesn't work now.
That's interesting...try renaming your data folder and launching again. It might be some corrupt data.
Yup - it worked that way. Now I have to find the feeds database and delete it maybe - I guess that's where the problem is most likely to be.
EDIT: I found the DB file Data\.rssowl2\.metadata\.plugins\org.rssowl.core\rssowl.db and deleted it - it all worked afterward. Of course all my subscriptions were lost but good that I have a backup OMPL file... just in case.
I figured that was the case. I had an issue like that too. Glad it's fixed
any chance of killing that ugly, nonstylish RSSOwl's splashscreen somehow by default?
http://boreal.rssowl.org/#1c
Just pass it in your .ini like you for other portableapps, and let me know if you have any issues.
im confused, how exactly can i pass -noSplash switch to portable launcher??
like you would for Firefox Portable to pass additional parameters. Look in \RSSOwlPortable\Other\Source\Readme.txt.
both 'AdditionalParameters=noSplash' and 'AdditionalParameters=-noSplash' in RSSOwlPortable.ini give me the same repulsive splash screen
I'll work on it and see what I can do.
This should fix your issue. Use -noSplash in the additional parameters. It worked for me. Please let me know.
cool, it worked
when we could expect official release and what are open issues if any?
Good to hear! Not sure on the timeline of an official release from RSSOwl's team...there is one issue that if they can't fix it won't go official. The internal browser in RSSOwl currently uses the IE engine, and therefore uses IE's cache. Since we can't just clear that out, it has to be handled in the app.
I think it doesn't work on Java 1.6 (not portable).
Should I install older version?
How to force it to use portable version of Java?
By default the launcher will check for \PortableApps\CommonFiles\Java\ and make sure java is there and if so, will use that. Next it will check for the program's 'VM' switch. Then lastly it'll attempt to use any local versions on the PC.
Is there any way to disable the creation of backup files found in...
RSSOwlPortable\Data\.rssowl2\.metadata\.plugins\org.rssowl.core
I'll check. I'm not sure, I know you should be able to delete them. I'm going to ask the devs about disabling/removing.
Here's what the Devs said: https://sourceforge.net/forum/message.php?msg_id=7546828
Thanks for your help! I'll also definitely vote for this - in my case backups are pretty much useless - I backup my whole drive daily, plus I don't save any news inside the program so even if something DOES go wrong - I don't have anything to lose - I can always just import my OMPL file and I'm done!
Same here. Daily backups became a standard for me after I killed my old drive and lost over half of everything.
So far, there is no fix for this. RSSOwl can run with XULRunner, but it nearly doubles the size of the app, plus when that is used instead of the default IE engine, the right-click context menu is lost. Not too mention, RSSOwl won't be bundled with it for those reasons.
The only way to allow RSSOwl to not use IE's cache is to disable Images/Flash in the feeds, which greatly reduces the functionality of the reader itself...
I'm not sure if this is ever going to make it final with this blocking issue at hand.
why not create a XUL runner portble, then make RSSOwl piggy back onto that
I know it still doubles the size and all that, but then its not application specific. (Unless my image of XULRunner is totally wrong).
Too many lonely hearts in the real world
Too many bridges you can burn
Too many tables you can't turn
Don't wanna live my life in the real world
That's what I was thinking, BUT, then you'd still have to have both, and that would make it bigger, because it's own portablization...on top of that, it kills the right-click context menu though...
Can it use the XULRunner within Firefox? The firefox exe accepts an -app command line switch to allow it to launch other XULRunner apps. Firefox has been XULRunner since 3.0.
Sometimes, the impossible can become possible, if you're awesome!
Unfortunately he says it can't here. Only XULRunner will work..
Those are outdated instructions based on XULRunner 1.8.x which was indeed different than Firefox 2.0. Firefox is based on and includes XULRunner 1.9.x since version 3.0.
Sometimes, the impossible can become possible, if you're awesome!
Yes, but it's still got to interface with his internals in RSSOwl. He's tried it with newer versions of XULRunner apparently and it has issues.
Yes, it makes it bigger, but it does open the opportunity for other apps.
Whats the though for?
Too many lonely hearts in the real world
Too many bridges you can burn
Too many tables you can't turn
Don't wanna live my life in the real world
That using XULRunner stops any right-click context menu from working. So if we use XULRunner we can't right click and copy, paste, copy link, etc...
While that wouldn't be bad for me, I guess (Ctrl+C/Ctrl+V, anyone?), I can see how it would be a bad thing for others. Does the developer have plans to fix this?
Too many lonely hearts in the real world
Too many bridges you can burn
Too many tables you can't turn
Don't wanna live my life in the real world
AFAIK, no. Because he doesn't recommend it anyways, because it doubles the size of the app, and a few other issues apparently, that we haven't discussed.
Thanks you for starting the portable edition of this amazing RSS Reader.
May I suggest a few updates on Portable Edition of RSSOwl ?
1) You shouldn't change any file in RSSOwl distribution located in folder "RSSOwlPortable\App\RSSOwl".
I saw that "RSSOwlPortable\App\RSSOwl\Configuation\config.ini" has been modified. You should use "-data" and "-configuration" parameters instead.
These parameters are generally setup in file "RSSOwl.ini" or passed directly to the command line. You could then start "RSSOwl.exe" with the "--launcher.ini" parameter pointing to that file in folder "RSSOwlPortable\Data\" or adding these parameters to the command line when launching "RSSOwl.exe".
You will find all available parameters here.
2) You should also used the PortableApps way to discover what JRE to use.
You could use the JRE, Portable Edition (Recommended solution). Please note that PortableApps is not always installed in the root folder of the portable device. So using the command "$DRIVELETTER:\PortableApps\CommonFiles\Java\bin\" is not valid fo everyone.
I'm sure John and his developer team will help you to implement the correct solution.
The JRE can also be setup through the "-vm" parameter in RSSOwl.ini or directly to the command line.
I have a huge experience with Eclipse and all these ini parameters. So don't hesitate to ask me questions if you need any further assistance about these parameters.
Best regards,
Bertrand
I'll have to modify for the config.ini, I was unaware that was changed.
As for the Java VM - I've gone through that with John, and Java is supposed to ONLY be located at this location at the current time in relation to the platform. That's the way he has it setup. Hence the way the launcher looks for portable Java, then the -vm switch, then will fall-back on a local install of Java.
This will probably not go final due to the issue mentioned above. RSSOwl still uses IE's cache when displaying feeds with images/flash/etc therefore nullifying the portability of it. Unless a workaround can be made, this can't be made final.
The lead dev and I have talked, and XULRunner is not really a valid solution as it removes the right-click context menu in RSSOwl.
Java is supposed to ONLY be located at this location at the current time in relation to the platform.
Damned ! It's very limited.
However OpenOffice Portable Edition doesn't work that way.
CheckJavaCommonFiles:
${GetParent} $EXEDIR $PORTABLEAPPSDIRECTORY
IfFileExists "$PORTABLEAPPSDIRECTORY\CommonFiles\Java\javaportable.ini" "" LaunchNow
StrCpy $JAVADIRECTORY "$PORTABLEAPPSDIRECTORY\CommonFiles\Java\"
ReadINIStr $JAVAVENDOR "$PORTABLEAPPSDIRECTORY\CommonFiles\Java\javaportable.ini" "JavaPortable" "Vendor"
ReadINIStr $JAVAVERSION "$PORTABLEAPPSDIRECTORY\CommonFiles\Java\javaportable.ini" "JavaPortable" "Version"
Why don't you use the same technique for RSSOwl Portable Edition ?
For the caching issue, why don't you force RSSOwl Portable Edition to use an External Browser (Preferences->Browser->Use the following external Browser) ? Firefox Portable Edition for instance. What do you think ?
Hmm, I'll have to change that then. I wasn't aware of that.
Also - that more/less limits the use of an RSS Reader.
When making it portable you have to assume that people are going to use all the features of the app. And the normal use of the app would remove it's portablity. Opening in an external browser means you only know of new feeds and the title in the app, anything else you want has to launch the external browser.
I was going through these suggestions today finally. I made the modifications to the launcher for the Java.
I haven't use any switches to move the paths of the data though, everything is set in the RSSOwlPortable\App\RSSOwl\configuration\config.ini file. That's the only set of paths I've modified. But I modified that one on purpose. It shouldn't be modified when it's being used. The app is always going to look for that file, and I'm modifying it when I distribute it, so anytime they install the app from me, it'll be ok.
But may I insist to not modify any file in the RSSOwl distro. Eclipse RCP provides an easier solution to apply customization. As stated in my previous post, you could provide a custom "RSSOwl.ini" file to "RSSOwl.exe" to apply the same effect.
1) Please don't touch anything in original "RSSOwl.ini" (folder "$PROGRAMDIRECTORY"):
-vmargs
-Xms15m
-Xmx192m
-Dosgi.requiredJavaVersion=1.5
Instead create a copy of "RSSOwl.ini" in folder "$SETTINGSDIRECTORY". And apply any modification you might require. But you could keep it without any modification if you want.
Then to use this copy instead of the original file in folder "$PROGRAMDIRECTORY" you must pass the following parameter to "RSSOwl.exe":
--launcher.ini "$SETTINGSDIRECTORY/RSSOwl.ini"
RSSOwl will now use this customized file rather than the original one.
2) Keep also "config.ini" untouched (folder "$PROGRAMDIRECTORY/configuration"):
# RSSOwl 2.0 runtime configuration file
#
# This file contains a number of key/value pairs that are merged into the
# System properties on system startup. The values control the way the
# runtime is structured and runs.
# Section Name allowing to read/write values using NSIS (see Bug 383)
[rssowl]
# The comma-separated list of locations to search for the splash screen file (splash.bmp).
# For each list element a subdirectory structure based on the pattern nl/ is searched.
# The system binds to the first matching file. There is no default value.
osgi.splashPath=platform:/base/plugins/org.rssowl.ui
# The comma-separated list of bundles which are automatically installed and optionally started
# once the system is up and running. Each entry if of the form
# [@ [] [":start"]]
# If the startlevel is omitted then the framework will use the default start level for the bundle.
# If the "start" tag is added then the bundle will be marked as started after being installed.
# Simple bundle locations are interepreted as relative to the framework's parent directory.
# The startlevel indicates the OSGi start level at which the bundle should run.
# If this value is not set, the system computes an appropriate default.
osgi.bundles=org.eclipse.equinox.common@2:start,org.eclipse.update.configurator@3:start,org.eclipse.core.runtime@start
osgi.bundles.defaultStartLevel=4
# The product to run. A given Eclipse configuration may contain many products.
# The product identified will supply the branding (window icons, title bar text) etc
# as well as define the default application to run.
eclipse.product=org.rssowl.ui.product
# The default workspace location
osgi.instance.area.default=@user.home/.rssowl2
# The default configuration location
osgi.configuration.area=@user.home/.rssowl2/config200
# Version Information
rssowl.buildId=2.0 RC1
# End of file marker - must be here
eof=eof
Instead you must pass the additional following parameters to "RSSOwl.exe":
-data "$SETTINGSDIRECTORY/.rssowl2"
-configuration "$SETTINGSDIRECTORY/.rssowl2/config"
This will overwrite at runtime the original values of the following parameters setup in the original file "config.ini" (folder "$PROGRAMDIRECTORY/configuration"):
osgi.instance.area.default=@user.home/.rssowl2
osgi.configuration.area=@user.home/.rssowl2/config200
Please note also that it is recommended to use "$SETTINGSDIRECTORY/.rssowl2/config" instead of "$SETTINGSDIRECTORY/.rssowl2/config200".
It is always a bad idea to hardcode a version in the folder name. What will happen when RSSOwl will be upgraded to version 2.0.1 ? You will have to migrate all the settings from "$SETTINGSDIRECTORY/.rssowl2/config200" to "$SETTINGSDIRECTORY/.rssowl2/config201".
If you follow all my recommandations, you will not have to change anything to you portable launcher nor to the settings. All you will have to do is to upgrade the RSSOwl distro without changing anything. Easy, isn't it ?
If you don't understand any part of my recommandations, don't hesitate to contact me directly for assistance
Cheers,
Bertrand
I'll look into working on that. I don't like to set command line parameters in the launcher, it's a lot more that I have to look for and work around in the launcher.
Command line parameters are betters. For one, you shouldn't have to run the launcher after the program is launched. Second, reduce the read\write introduced by renaming things.
Third, I think its cleaner myself. Geany Portable features code to do this, as does PNotes Portable.
My two cents. (or however much . . . )
Too many lonely hearts in the real world
Too many bridges you can burn
Too many tables you can't turn
Don't wanna live my life in the real world
I like it in that regards, but then you have to build in a check to make sure that parameter isn't already passed, etc. Most likely I'll just use it that way in the launcher so.
As soon as I can get the stupid launcher to rename the directory for me I'll get up a new release.
I don't . . . . I don't think any of the others check either.
Too many lonely hearts in the real world
Too many bridges you can burn
Too many tables you can't turn
Don't wanna live my life in the real world
Please note that command line parameters are the most common way to make applications portable. 95% of portable application launchers have been developped that way. For instance, even Firefox Portable Edition launcher is using this technique to force the profile location ("-profile" switch ). Why do you not use this common technique ?
Have a look at most of launcher scripts of PortableApps.com applications to see by yourself. Maybe John Haller could convince you to work that way... if you are still reluctant to use command line parameters in you launcher
Oh, I know. I love command line switches for portability. I just like to ensure that if someone tries to overwrite it, I don't overwrite their choice.
It seems your suggestions are redundant. If by using the -configuration option, it uses the specified config.ini, then there's no reason to also use the -data switch as that's already specified by the config.ini. So it would make sense to do one or the other.
Either specify -data or specify -configuration, especially since the switches will overwrite runtime values.
Or I'm not understanding it fully.
Maybe you can catch me on IRC or email me gizmokid2005 {at} gizmokid2005 {dot} com
I will try to make it simpler if it's not clear yet
By default, "RSSOwl.exe" will use java system properties defined in "config.ini" (in folder "$PROGRAMDIRECTORY/configuration"). In particular:
In order to overwrite the value of both properties at runtime you have several options:
If you choose to setup these parameters in "RSSOwl.ini", it's not recommended to update the original "RSSOwl.ini" (in folder "$PROGRAMDIRECTORY").
A best practice is to make a copy of the original "RSSOwl.ini" and save it in folder $EXEDIR\App\DefaultData. If the file doesn't already exist in folder $SETTINGSDIRECTORY, copy this default file to that location when the launcher is called. And update any path accordingly on both parameters.
Then add the following parameter to command line when launching "RSSOwl.exe":
--launcher.ini "$SETTINGSDIRECTORY/RSSOwl.ini"
This will force "RSSOwl.exe" to use this updated "RSSOwl.ini" (in folder $SETTINGSDIRECTORY) instead of the original one (in folder $PROGRAMDIRECTORY).
That helps a lot! I was a little lost there.
So what I'm going to do is modify the RSSOwl.ini that comes with RSSOwl, and put it in my \Data\ folder, as well as put a copy of the original in the DefaultData folder. Then I'll use the --launcher.ini argument to set it to look for the right RSSOwl.ini.
Out of curiosity, why is there two hypens before launcher.ini as an argument, but only one for the vm argument?
-Gizmokid2005
The Eclipse launchers have been rewritten for 3.3. Since then arguments that are new are named using the convention --launcher.<arg>, old arguments keep the same name as before. You will find all the details on Eclipse Wiki.
In my opinion, I think it's better to directly setup "-data" and "-configuration" parameters on command line. Otherwise you will have to update each time both parameters values in "RSSOwl.ini" (the drive letter of the portable device may change from one computer to another); that also means more I/O. If you use these parameters on command line instead, you don't have to change anything because you could use runtime nsis variables:
All this follows the same idea beyond the "-vm" parameter usage to force the JRE used by "RSSOwl.exe". You could setup this parameter on "RSSOwl.ini" but it's better to use it on command line for the same reasons.
However, I will recommend also to use a copy of "RSSOwl.ini" for other customization (as explained previously). By default, the content of "RSSOwl.ini" is
-vmargs
-Xms15m
-Xmx192m
-Dosgi.requiredJavaVersion=1.5
I'd like to apply a more fine grained tuning to the JVM parameters for my own usage. I'm currently using the following parameters:
-vmargs
-Xverify:none
-Xms64m
-Xmx128m
-XX:PermSize=64m
-XX:MaxPermSize=64m
-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC
-Dswing.defaultlaf=com.sun.java.swing.plaf.windows.WindowsLookAndFeel
-Duser.language=en
-Duser.country=US
Using a copy of the original "RSSOwl.ini" will let the RSSOwl users to apply any customization they might need. And as the PortableApps format suggests, user's data should be saved in "$SETTINGSDIRECTORY" instead of "$PROGRAMDIRECTORY".
Keep going the good work then
Best regards,
Bertrand
I'm with Bertrand on preferring the command line for all our additions. Updating INI files should be avoided if possible. We don't worry about colliding on arguments of the command line since we only add the options we need for portablization. If a user wants to manually specify the same option on the command line we use for portablization, then they probably don't want to be using our launcher anyway. If we're manually setting something that is helpful for portablization that, say, some users may want to turn off, we can add an INI option to our launcher's INI for that. But, generally, it's not needed.
Sometimes, the impossible can become possible, if you're awesome!
I don't mind using command line. I have been building in protection if someone was to use the particular switch that I am. If you think it wouldn't necessarily be needed, then I can just make the changes without that. I don't have a problem with that.
Hi, I'm trying the RSSOWL 2.0 RC1 barely copied on your portableapps version (paying a little bit of attention to config file, of course).
It's working like a charm.
Thanks.
Good to hear. I've got to update RSSOwl and KVIrc. My box is down at the moment due to a dead PSU, but I should have things back up and running soon.
i noticed that after quiting RSSOwl Portable, the RSSOwlPortable.exe process doesnt always quit as taskmanager says..
any chance of fixing that somehow?
also, i noticed a good performance improvement in latest RC1 build, great news
I haven't noticed nor heard of this issue. Can you reproduce it and tell me how?
Also - RC1 should be out soon (hopefully )
not every time, it seems just random..
cant be reproduced easily since sometimes it quits properly and sometimes it just lurk among other processes in task manager..
btw, looking forward for release of RC1 portable, i copied RC1 files to a M9 and upgraded it with care, no hustle
they finally implemented option to choose which columns will be visible, no more stretching
Hmmm. Sounds interesting. I'll see if I can find anything that might do that.
And good to hear.
RC3's out and downloading ATM!
Anyone has any idea what that means? I've installed the Portable Java in the appropriate place - [folder where all papps are incl. Rssowl]/CommonFiles... Using the latest Development Test 4 (2009-07-21) version.
Here's the image to look at: http://img4.imageshack.us/img4/6466/a7cc5f7f8e2844d7717ac5a.png
EDIT: OK. I just read a comment a few screens above that pointed me into the right direction to this thread: http://sourceforge.net/projects/rssowl/forums/forum/296910/topic/3109453
Which had the solution:
Thanks buddy - it sure did help me!
In case someone wonders what I did - I created a shortcut and added the path to my portable java's bin folder - "pathToPortableApps\CommonFiles\Java\bin" and it worked! :))
in the right directory.
For PortableApps.com's JavaPortable, Java should be in X:\PortableApps\CommonFiles\Java (X: being your drive letter).
That's where RSSOwl is going to look for Java by default. If you install it there, and NOT to RSSOwl's directory, it'll work without any modifications.
So the X:\PortableApps\CommonFiles\Java is an absolute path then? I thought it was looking in a relative path like dir-where-rssowl-and-commonfiles-are/CommonFiles/Java... in other words I thought the X:\PortableApps\ part didn't matter as long as both RSSOwlPortable and CommonFiles were in the same folder.
My bad.
Actually, if I remember correctly, I have it set to look for Java in relation to the PortableApps\ folder instead of the drive letter, but it will be looking in the standard structure I said above, not in the actual RSSOwl folder.
Well, here's my structure:
E:\Programs\PortableApps\CommonFiles\Java
E:\Programs\PortableApps\RSSOwlPortable
And it didn't work until I used the -vm passing.
Hmmm, it should've worked. Do you use the platform as well?
What do you mean by platform?
I'm using Win 7 64bit btw.
portableapps.com platform/menu/suite from here.
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
Simeon is right, the PortableApps.com Platform (menu).
I am also using Win7 Ult 64-bit and haven't had any issues with it.
Nope, not using the platform. Should I?
Pages