Portable version for PortableApps.com

[GoogleCodeExporter]

This isn't /really/ and issue or a problem, more a tacking/question thing.

I was shown this app by a friend and LOVE it. I notice that you have some 
settings/ways to make the app pretty much portable. I'd like to take it an make 
it into a PortableApps.com portable app as well. I figured I'd kinda throw this 
out there/ask for opinions from you guys? I'm going to start working on it 
tonight, it seems as if it'll be a quick setup.

-Michael

Original issue reported on code.google.com by Gizmokid...@gmail.com on 14 Jun 2010 at 1:35

[GoogleCodeExporter]

I don't really know about it. I have used apps from portableapps.com in the 
past but I stopped eventually because they often lagged behind by a few 
releases, etc.

But hey, if you're willing to do it yourself, then you're more than welcome to. 
I'll give you commit access to the source once you have something concrete, 
though.

I'm guessing DamnVid's update checker would have to be modified, though, 
because right now, whenever it sees that there's a new release, it goes to the 
Download page at:
http://code.google.com/p/damnvid/downloads/list
But the portable version of DamnVid would perhaps be hosted at PortableApps.com 
instead? If possible, I'd like to keep DamnVid here on googlecode as much as 
possible, and not have multiple installers floating around. But it'd obviously 
be better to have a portable installer, even if not hosted here, rather than 
nothing at all.

Good luck~ You can ask for help or report on your status here, but I probably 
can't help you much with the PortableApps spec stuff. I can however help you 
set up a Windows build environment so that you can create DamnVid setup's, 
because right now it's kind of a b*tch to set up on Windows. There are some 
instructions on the BuildingFromSource page though.

Original comment by windypo...@gmail.com on 14 Jun 2010 at 1:46

• Added labels: Component-Packaging, Component-Persistence, Component-Scripts, OpSys-Windows, Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

I've put out Songbird there, and am working on KVIrc as well. I don't have a 
problem setting it up and maintaining it. Updating the portable version isn't 
much work at all, assuming that the app's behavior in regards to the system 
hasn't changed much, if at all (ie - reg entries, file storage locations, etc).

I've got no problem with maintaining a branch for it. The only thing that's 
really different is the file structure, and of course there would need to be a 
few extra files, but you can see it all in a current release of a portable app 
or at their Development informational page: 
http://portableapps.com/development. It's really not hard, and I've got no 
problem with it :)

Yes, PortableApps.com would do the hosting of the portable version, they 
actually use SourceForge for the hostinhg since there's so much bandwidth 
involved, but that's neither here nor there.

I won't need to do a special build for it at all, I just create a wrapper for 
the app really. If the update notification doesn't actually automatically 
download a new version and install it, that won't be a problem either. If you 
can make an option to disable it or a similar function that would be desirable 
for the portable version.

PortableApps.com does digital signing of all their installers, but when you put 
out a new version, if you want to give me heads-up I can have the portable 
version ready to go as well and we can put a version up here (unsigned from 
PA.c of course) so even if you leave the notification of updates in, it would 
bring them to the download page with the portable installer as well.

I'll be sure to post up here when I get the first iteration taken care of and 
we can go from there.

Feel free to send me an email as well if you have any questions/etc. I realized 
none of my contact info is on my blog, but I'll get it up there so you have all 
that as well.

-Michael

Original comment by Gizmokid...@gmail.com on 14 Jun 2010 at 2:14

[GoogleCodeExporter]

All my contact info finally: http://gizmokid2005.com/contact-me

Original comment by Gizmokid...@gmail.com on 14 Jun 2010 at 3:20

[GoogleCodeExporter]

When running DamnVid with the --config option, why does the app still create 
C:\DamnVid\<subdirs> to save files in? Isn't that the point to specifying a 
config directory? Is there a switch to modify the data directory as well? 
Thoughts?

Original comment by Gizmokid...@gmail.com on 14 Jun 2010 at 3:34

[GoogleCodeExporter]

Thing is, in order for the app to be fully consistent with other portable apps, 
you probably will have to modify the source code (for example, yes, to specify 
the download page for new versions, because I don't think there should be a 
command-line flag for such a thing), and if you do modify the source code, you 
will have to create a new .exe out of it.

Or maybe I should move these out to a configuration file like damnvid.cfg or 
something that would sit alongside DamnVid.exe and that would be read when the 
program starts, and you'd write the new URL inside it. That would work and be a 
cleaner solution, I think. However, it still does require modifying the source 
code and recompiling it because the current 1.6 release doesn't do that.

Also, what do you mean exactly by creating dirs in C:\DamnVid? What directories 
does it create, where is DamnVid.exe (is it in C:\DamnVid) and what option did 
you use to launch it?

Original comment by windypo...@gmail.com on 14 Jun 2010 at 3:47

[GoogleCodeExporter]

Not too much of a fan of doing extra modifications for stuff, if it just goes 
to the download page, we can put a copy of the portable version up here as 
well, just to be safe?

I ran DamnVid from the desktop (C:\Documents and Settings\User\Desktop\DamnVid) 
like so: DamnVid.exe --config="C:\Documents and 
Settings\User\Desktop\DamnVid\DATA"

I had downloaded one YouTube video to see where any files/folders were created. 
It created C:\DamnVid\YouTube\<videofileIdownloaded>

Original comment by Gizmokid...@gmail.com on 14 Jun 2010 at 3:51

[GoogleCodeExporter]

Well, where/how did DamnVid get "C:\DamnVid" from? I mean, it can't guess that 
it should put videos there. Did you modify the configuration so that it did? 
The default directory is in the "My Videos" folder in C:\Users or Documents and 
Settings\Username\Videos\DamnVid.

Now yes, one of the limitations of this is that there's no switch yet for 
overriding the "My Videos" folder (other than editing DamnVid's configuration). 
Should I add it? Something like DamnVid.exe --videos="X:\MyVids" and it would 
override each configuration value that says "C:\Users or Documents and 
Settings\Username\Videos\DamnVid" to "X:MyVids".

Original comment by windypo...@gmail.com on 14 Jun 2010 at 4:01

[GoogleCodeExporter]

Well, in the PortableApps.com version, all the registry entries (just in my 
initial tests) do not exist. I just installed the app, pulled the files, 
restarted to a clean environment in a VM, dropped the files in and ran it. 
That's where the files wound up. I'd suggest a --videos option, or --data if 
more than just videos are stored (besides the config). Having separate options 
for the videos and config is a very good idea. And yes, if the command line 
option exists, it overwrites the config as it should be considered a "live" 
change to the app versus the "cached" config value.

Original comment by Gizmokid...@gmail.com on 14 Jun 2010 at 4:06

[GoogleCodeExporter]

Well, I'm guessing that the environment you ran it in doesn't have a "My 
Videos" folder set (the one you get using SHGetFolderPathA 0xE), or it 
defaulted to C:\. Quite weird indeed.

Here's what DamnVid stores:
- In the configuration folder:
-- damnvid.ini (the actual configuration file)
-- damnvid.log (the log file of the last run)
-- lastversion.damnvid (text file containing the version used the last time 
DamnVid was run. Used to determine whether the config file is outdated and 
stuff)
-- modules/ (a folder containing all the user's modules)
--- (all the modules... The configuration of each module is in damnvid.ini 
though)
-- temp/ (a folder where DamnVid stores incomplete video files that are being 
converted, and passes log in case of a multi-pass video encode). It is created 
when DamnVid starts and deleted when DamnVid exits

- In the videos folder:
-- Only finished, ready-to-play videos

Previously, DamnVid stored its temporary files in the user's temp folder 
(%TEMP%). I moved it to the config folder, I don't exactly remember why though 
as that was a long time ago... Maybe I should make all three folders 
configurable? (--videos, --config, --temp)? Especially the temp folder, because 
if it's a USB key, read/write's are expensive and slow, so perhaps temporary 
files should not be kept there.

A cool thing in damnvid.ini is that the My Videos folder is never "hardcoded". 
It is replaced by "?DAMNVID_MY_VIDEOS?" when written to disk, and replaced back 
with the current my Videos folder when read from disk. That way it would be 
easy to make it be replaced with something else from the command-line flags, 
and then if you launch it without it, it's back to the local My Videos folder.

I would really like to have the portable version there so that I can keep 
tracks of the number of downloads and stuff. If it's on both sites, I don't 
really know which site has which share. However, PortableApps probably has a 
lot more traffic than this site, so perhaps it could be on both sites, and then 
when there's an update it redirects users here so that this site gets traffic 
on top of it? That'd be cool but I don't know if the guys at PortableApps would 
be okay with it.

Original comment by windypo...@gmail.com on 14 Jun 2010 at 4:21

[GoogleCodeExporter]

Sounds like you've done a lot of work on the setup/config of DamnVid, and the 
way it handles things. That's really nice when it comes to portability. My 
guess is you moved the temp folder for the portable version so when it's moved 
or closed mid-dl/convert the files aren't left behind. That's a good policy :)

Sometimes I have to take a step back to think about flash drives, since I run 
so much stuff via PortableApps.com version, I killed 2 separate Corsair 
FlashVoyager GT drives, blew up the chipsets basically, I had to go to a 2.5" 
external hdd. Having separate parameters for each item is a good idea, I'm sure 
users would wind up using it via the local version as well (for those that run 
apps on one drive, save stuff to another, etc...) so I could see them being 
useful.

It's kind of hard to really think about where you'd want the defaults to 
be...For example, assuming all the standard PA.c formats are kept/met, it would 
be as follows:

Structure:
X:\PortableApps
     \DamnVidPortable
          \App
               \AppInfo
               \DefaultData
               \DamnVid
          \Data
               \settings
          \Other (Mainly just PA.c specific stuff for launcher source, simple readme/help files)
               \Help
               \Source

So, the actual App files would be in 
X:\PortableApps\DamnVidPortable\App\DamnVid. We'd probably just nix the 
\DefaultData folder since there really isn't any data required that the app 
doesn't seem to create itself, so no need to take up the extra space for it. 
We'd then do the videos one of two ways.

The PortableApps.com Platform has a menu that comes with it that also creates 
folders in X:\Documents\ such as Music, Videos, Pictures. We'd probably put in 
the launcher to check for the platform (X:\Documents\Videos folder) and if it 
doesn't exist we'd then store the videos in 
X:\PortableApps\DamnVidPortable\Data\(possibly creating a "Videos" folder at 
this level as well). As for the temp files, we could store them directly in the 
Data folder as well, or possibly make use of the %TEMP% folder on the local 
machine just to cut down on the wear of the flash drive. That's something we'd 
have to dig into a bit more before finalizing.

As for file hosting, the main download would absolutely be there, that's where 
PA.c stores their files after signing for distribution. I haven't delved into 
how GC handles posting links in the files section, but if it's possible, you 
could also have a link in there for the portable version that just pushes the 
user to the DamnVidPortable page at PA.c. You'd still get traffic, yet all the 
downloads would still be counted at SourceForge using their stats and 
everything is in one spot.

Original comment by Gizmokid...@gmail.com on 14 Jun 2010 at 4:45

[GoogleCodeExporter]

I have implemented --temp=/some/path and --myvideos=/some/path in r325.
The app indeed stores its "default data" in its own installation directory (in 
/conf/conf.ini and /modules/).

I also added a file called "overrides.damnvid" in /conf. It is pure Python code 
that runs right after declaring the update check/download/help/etc URLs, and 
can be used to override these if the file is present. The example file I 
checked in gives an example:
http://code.google.com/p/damnvid/source/browse/trunk/conf/overrides.damnvid
This overrides the download URL (the one users are sent to when there's a new 
version) and the "Help" page URL (the one users are sent to when they press 
Help in the menu).

To actually use all of that in a portable directory structure, you'll probably 
need to compyle and generate a setup.exe to put all of that into place. Let me 
know if you run into problems with that (hint: you will), I'll answer them and 
then I'll edit the BuildingFromSource page with more detailed instructions so 
that people don't run into them again.

Issue accepted, you are now its owner. Also, you should have commit access now 
and of course your entry on http://code.google.com/p/damnvid/people/list ~

Original comment by windypo...@gmail.com on 15 Jun 2010 at 6:12

• Changed state: Accepted

[GoogleCodeExporter]

Thanks for the updates. Either I'll have to try to setup a build enviro for it, 
or just wait for you to build an updated version for me. No need to generate a 
new setup.exe or anything. The install will be handled by the PortableApps.com 
installer which just extracts the files. So, if you want to build a new version 
even if it's just for me to tinker/test with, I can see if there's anything 
outstanding with it.

Original comment by Gizmokid...@gmail.com on 15 Jun 2010 at 2:29

[GoogleCodeExporter]

Are there any files that DamnVid uses to store paths of anything, hardcoded or 
otherwise, maybe for config files or whatnot?

And do the --config, --temp, --myvideos switches work with relative paths or 
must they all be absolute paths?

I'm finally getting things going and need these two clarified first.

Original comment by Gizmokid...@gmail.com on 15 Jul 2010 at 2:07

[GoogleCodeExporter]

DamnVid will use a file for overrides which may be used to specify paths, but 
the command-line solution would be better since it would work for 
changing-letters USB keys and whatnot. It should accept relative paths but you 
should convert it to absolute paths unless you are sure that they are relative 
to DamnVid's directory and that you are starting DamnVid.exe from its own 
directory. Or you know, just convert to absolute to be safe~

Original comment by windypo...@gmail.com on 16 Jul 2010 at 4:25

[GoogleCodeExporter]

Alright. I'll just use absolute paths anyways, that works for me.

Original comment by Gizmokid...@gmail.com on 16 Jul 2010 at 4:59

[GoogleCodeExporter]

DamnVid Portable has been posted, it's the first Development Test, but it's on 
its' way. Give it a try and post any issues either here or in the thread!

http://portableapps.com/node/24280

Original comment by Gizmokid...@gmail.com on 19 Jul 2010 at 5:00

[GoogleCodeExporter]

DamnVid Portable Pre Release 1 is up and going. The more testers/feedback we 
get the faster we'll go final!

http://portableapps.com/node/24457

Original comment by Gizmokid...@gmail.com on 2 Aug 2010 at 8:26

[GoogleCodeExporter]

Has gone final. :) Thanks Gizmokid2005~

Original comment by windypo...@gmail.com on 3 Mar 2011 at 8:33

• Changed state: Done