/hydrus/ - Hydrus Network

Actually, the best solution would be for Hydrus itself to ask users where they want their database + files to be, and to remember that.

That would be much, MUCH more graceful that forcing the location with shortcuts.

Here's my proposal, @hydrus_dev.

If no db is detected, hydrus asks where you want your db+files, or it asks you to locate an existing db. Whatever you choose is remembered. Done. Thoughts? That would pretty much negate this thread + any issues on my end.

I'd like to have user settings stored separately in C:\Users\<user>\AppData\Roaming\Hydrus.

If Hydrus sees no db folder, I'd like it to ask me wither to 1. Browse to locate db folder or to 2. Create new db with C:\Users\<user>\Hydrus being default location.

>>8039

I am happy with the current default location of

C:\Hydrusnetwork that the non-chocolatey version uses, but your position #1 and #2 would be fine by me as well. #1 is a bit better IMO

#4 is just awful – documents is supposed to a user-controlled folder for the user's files, and I hate that every program I install clutters it up with its own config files and other garbage

#3 is bad for the same reasons as 4, though windows programs have less of a history of disrespecting it like that.

But I also agree with

>the best solution would be for Hydrus itself to ask users where they want their database + files to be, and to remember that.

I tried to use the hydrus release on chocolatey but quickly gave up on it when every update went to C:\tools\ – I wanted to use my pre-existing C:\hydrusnetwork directory. It was possible to get chocolately to do a one-off install to this directory with the –installargs parameter, but subsequent versions from "choco upgrade all" still went into the tools folder, and I ended up giving up on it.

Another note: Installing to program files is a bad idea. Hydrus puts the database in its own install directory, and files in the program files directory can't be modified without administrator permission. So if you install there, users will be forced to run hydrus in administrator mode.

>>8041

Thanks for this thread. I like this idea, and I agree that #1 is a good non-portable option. Anyone with a big collection is almost certainly going to want to move their stuff out of C drive pretty soon, so the less buried that location is, the better. I can also find the base user path on all platforms without it being a problem. I would also like to make it easy to manage multiple clients on one computer and one user, so I am not super-keen on writing global preferences (to save the result of a first-boot 'where to put the db' question) to user directory by default.

How about I do this:

If location is explicitly set in shortcut, use that.

Otherwise:

If hydrus has permission to write to its own directory, use that.

Otherwise:

Use ~/Hydrus (i.e. C:\users\user\Hydrus on Windows)

This should make it easier for people to install to protected locations like Program Files right out of the gate without them having to tweak anything or be confronted with a possibly confusing dialog about db locations and permissions on their first boot, and I think it'll slot in neatly for you as well, right?

Do you need me to change the installer to supply a program files location option (like a portable/local install radio button choice or something), or can you specify that at your end? Would just defaulting to ~/Hydrus as a last resort be enough to do what you want?

Let me know if I have misunderstood something here. I am not very familiar with package managers.

>>8066

>but subsequent versions from "choco upgrade all" still went into the tools folder, and I ended up giving up on it.

Yeah, that's my bad. I could have added some code to not overwrite the user's existing install location, but then again, chocolatey is supposed to be implementing the ability to remember your installarguments for each package. That way, your custom location would be applied for every future update, and I could keep my install script clean+simple. I wish they would hurry up with that…

> Installing to program files is a bad idea.

I think you've misunderstood the intent. Software goes into a read-only location for reasons of security and stability. It's the software's job to write to user writable locations. I will be installing hydrus itself to program files, but your databases and pictures will go to C:\Users\<user> (or wherever we decide).

>>8074

> How about I do this: …

I think that would be perfect! To clarify, by

>location is explicitly set in shortcut

you mean -db_dir in general, right?

You don't need to change anything in the installer- but what I've done to work around it is a bit of a hack. Some installers accept arguments to customize the installation director. Yours does not, as far as I can tell. In order to change the install location, I directly manipulate the registry entry your installer reads like so:

'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Hydrus Network_is1\'

'Inno Setup: App Path':'C:\Program Files\Hydrus Network'

This works fine, but will break if you change the location or syntax in any way. Also, this doesn't actually matter, but WOW6432Node is for 32bit software, and hydrus has been x64 only for some time :P

The one thing I would like you to change about the installer: don't open the changelog after install. If you could have that off by default, or give me a command line switch to de-select it, or have it automatically de-selected when the user has used the /VERYSILENT switch, that would be great.

>>8088

> If I want hydrus to use that folder, I have to set this other folder to read-only

You've got it backwards. Hydrus will default to running in portable mode (as it always has done). If the folder containing client.exe is read-only, THEN hydrus will proceed to use ~/Hydrus.

Current behavior probably just throws an error. Proposed behavior acts as a fallback mechanism. Those desiring to use custom directories will continue to rely on -db_dir

> The installer definitely has a directory option, but as far as I can tell it isn't documented anywhere

http://www.jrsoftware.org/ishelp/index.php?topic=setupcmdline

I like to think I would have tried the /DIR option when I made this package years ago. Maybe I'm just dumb. I'll retest it against hydrus installer again when I get the chance.

>>8074

> I would also like to make it easy to manage multiple clients on one computer and one user, so I am not super-keen on writing global preferences

Food for thought: I have my hydrus database located on H:\Hydrus. I altered start menu shortcuts to point db_dir to H:\Hydrus. Hydrus updates and the installer overwrites my shortcuts. Solution: manually create shortcuts with a different name so they aren't overwritten. Never launch hydrus from the official shortcuts provided by the installer.

As a maintainer, fallback to ~/Hydrus means hydrus will package nicely, and everything else isn't my problem.

As a user with nonstandard db_dir, the fallback to ~/Hydrus doesn't help me. I still need to ignore shortcuts from the installer + create my own shortcuts. Which is fine, but your argument against global preferences is actually the exact reason we'd benefit from them ;)

A dialog prompt asking where to place the fallback db_dir would be better than just assuming ~/Hydrus.

An interface for switching between different databases would be the be a good long term feature, too.

>>8089

>You've got it backwards. Hydrus will default to running in portable mode (as it always has done). If the folder containing client.exe is read-only, THEN hydrus will proceed to use ~/Hydrus.

I'm saying that this will be obtuse and awkward for users who WANT to use ~/Hydrus. It should perhaps change the default value for a user-configurable option, but "current folder is/is not read-only" shouldn't be the ONLY way to change that behavior.

>>8090

> I'm saying that this will be obtuse and awkward for users who WANT to use ~/Hydrus

If the end goal is to have your files in ~/Hydrus, installing to program files is not obtuse or awkward. It is in fact a "best practice" and the wisest option as a general rule. You'd have to be trying to do something obtuse and inadvisable for it to not cover your use case. I'm perfectly OK with discouraging bad practices ;)

It's also trivial enough to just run Hydrus in portable mode directly in ~/Hydrus.

There's also still the -db_dir option, which is already here and not going anywhere.

I ultimately agree with your proposal, just none of your rationale behind it ( read what I wrote to dev >>8089 )

>>8087

Yeah, by explicitly, I mean the -db_dir.

I have set this in for tomorrow's release. If no -db_dir switch is set and the default db dir is non-writable, ~/Hydrus will be used instead.

I've set the 'open help' to unchecked by default. After thinking about it, I actually prefer it this way. Thanks for letting me know.

As >>8088 says, you should be able to go:

installer.exe /DIR="C:\Program Files\Hydrus"

To overwrite the default install location. I am not sure if your script has access to that or if there are other permission issues, but it works for me just testing it from my desktop here.

>>8088

I like the idea of having a file override as well. Maybe I could slide this in just below the command switch. So, in order of preference:

-db_dir

install_dir/db/db_dir.txt (or whatever)

install_dir/db if writable

~/Hydrus

>>8089

I see. I don't use the installer in my IRL clients so I hadn't come across these issues. I will think about this–maybe a file override will be a good solution for these cases, or I can just bite the bullet and write a location .txt to ~/Hydrus or whatever in certain situations.

>>8088

>>8087

I use InnoSetup, btw. It works very well for me.

http://www.jrsoftware.org/ishelp/index.php?topic=setupcmdline

>>8093

Update pushed, thanks dev!