diff --git a/docs/changelog.md b/docs/changelog.md index 92d35c748..1f2881be2 100644 --- a/docs/changelog.md +++ b/docs/changelog.md @@ -7,6 +7,44 @@ title: Changelog !!! note This is the new changelog, only the most recent builds. For all versions, see the [old changelog](old_changelog.html). +## [Version 577](https://github.com/hydrusnetwork/hydrus/releases/tag/v577) + +### explorer integration + +* thanks to a user, we have some new OS-file-explorer integration +* two additional options are added to the "open" menu for Windows users, "in another program" opens the Windows dialog to select which program to use and "properties" opens the Windows file properties dialog for the file +* the 'media' shortcut set gets the new 'open file properties' and 'open with...' commands to plug into these new features +* the "open in file browser" media menu command now more reliably selects the file in Windows and is now available for most Linux file managers--full list [here](https://github.com/damonlynch/showinfilemanager#supported-file-managers). +* the "open files' locations" file import log menu command is similarly more reliable, and can sometimes select multiple files when launched on a selection +* this requires a new external library, so users who run from source will want to rebuild their venvs this week to get this functionality + +### misc + +* the manage times single-time edit dialog's paste button can now eat any datstring you can think of. try pasting 'yesterday 3am' into it, it'll work! +* split the increasingly cluttered 'media' options panel into 'media playback' (options governing how media is rendered) and 'media viewer' (options governing the viewer itself like drags and slideshows) +* added to the new 'media viewer' panel are five checkboxes to turn off the background text in the full media viewer--for the taglist, the top hover, the top-right hover, the notes hover, and the bottom-right index string. if you want, you can have a completely blank background now +* gave the _help->about_ window a pass. I broke the cluttered first tab into two, and the layout all over is a bit clearer +* the _help->advanced mode_ option is now available under a new _options->advanced_ tab. this thing covers several dozen things across the program, all insufficiently documented, so the plan is to blow it out into all its granular constituent components on this page! +* fixed it so an invalid `ApplicationCommand` will still render a string. if you got some jank `ToString()` errors in a shortcuts dialog recently, please try again and let me know what you get. you'll probably want to go into the actual shortcut with the error string and try and see if you can fix what it has set--again, let me know the details please! +* updated the 'installing and updating' help page to talk clearly about the different versions that have special update instructions, and generally gave the language a pass + +### some url encoding + +* fixed an issue in url encoding-normalisation where urls were not retaining their parameters if their names had certain decoded characters (particularly, this was stuff like the decoded square brackets in `fields[post]=123`). a new unit test will catch this in future +* url classes and parsers are now careful to encode their example urls any time they are asked for (outside of their respective edit dialogs' "example url(s)" fields, so if you want to work with a human-looking URL in UI, that's fine). this ensures the automatic url-parser linking system works if the parser and url classes have a mish-mash of encoded and non-encoded example URLs. it also fixes some stuff like the multi-column list in the manage url classes dialog when the url class has a decoded example url. this was basically just an ingestion point that I missed in the previous work +* the edit parser dialog makes sure to properly encode the URL when you do a test pull + +### orphan table tech + +* the _database->db maintenance->clear orphan tables_ command, which could previously only clear out the repository update/processing-tracking tables, can now nuke: the core file list tables in client.db; the core mappings tables in client.mappings.db; the display and storage mappings caches in client.caches.db; the display and storage autocomplete count caches; the ideal and actual tag parent lookup tables in client.caches.db; the ideal and actual tag sibling lookup tables in client.caches.db; and the various tag search tables (except the fts4 stuff) in client.caches.db +* when this job fires, it now sends orphan tables to the deferred delete system (previously it dropped them immediately, which for a big mappings table is a no-go) + +### boring cleanup + +* cleaned a bunch of db table code for the new orphan table stuff +* deleted the old 'yaml_dumps' table and all associated methods, which are all now unused +* added a couple help labels to the "colours" and "style" pages to better explain what is actually going on here + ## [Version 576](https://github.com/hydrusnetwork/hydrus/releases/tag/v576) ### file access latency @@ -384,30 +422,3 @@ title: Changelog * cleaned up some misc URL Class code ## Version 567 was cancelled, its changes folded into 568. - -## [Version 566](https://github.com/hydrusnetwork/hydrus/releases/tag/v566) - -### incremental tagging - -* when you boot a 'manage tags' dialog on multiple files, a new `±` button now lets you do 'incremental tagging'. this is where you, let's say for twenty files, tag them from page:1->page:20. this has been a long time in the works, but now we have thumbnail reorganisation tech, it is now sensible to do. -* the dialog lets you set a namespace (or none), start point (e.g. you can start tagging at page:19 if you are doing the second chapter etc...), the step (you can count by +2 every file, instead of +1, or even -1 to decrement), the subtag prefix (so you can say 'page:insert-4' or something), and the subtag suffix (for, say, 'page:2 (wip)') -* the last namespace is remembered between dialog opens, and if the first file in the selection has a number tag in that namespace, that is the number the 'start' will initialise with. a bit of overlap/prep may save time here! -* the prefix and suffix are remembered between dialog opens -* a status text gives you a live preview of what you will be adding and says whether any of the files already have exactly those tags or have different tags under the same namespace (which would be possible conflicts, suggesting you are not lined up correct) - -### misc - -* added import support for .docx, .xlsx, and .pptx files (the Microsoft Open XML Formats). they get icons, not much else. they are secretly zips, so **on update, you will be asked if you want to scan your existing zips for these formats** -* when you move a window to another screen in a maximised state (e.g. on Windows you can do this with win+shift+arrow), the system that remembers window coordinates will now register and save this. the 'restore' window size is preserved from whatever it was on the previous screen while the 'restore' position will try to stay the same on the new monitor (e.g. if it was at (200, 400) on the old monitor, it will try to do the same on the new) as long as the window fits, otherwise it is moved to (20,20) on the new screen -* the 'edit string converter' panel no longer requires you to enter an example text that can be converted. you can see the error on the dialog, so if you don't want to fix it, or you just need to nip in and out testing things, it is now up to you -* if the database takes a long time to update, the 'just woke up from sleep' state should no longer trigger. the system thought the long weird early delay was the computer going to sleep -* the system that gives a popup and then a dialog when you have 165+ (and then 500+ or so) pages open is now removed. this was always a wx thing primarily, and Qt is much happier about having a whole load of UI elements. the main problem here is now memory blot and UI-update lag. this is now in the user's hands alone, no more bothering from me (unless it becomes a new problem, and I'll figure out a better warning test/system) - -### boring code cleanup - -* neatened how some manage tags ui is initialised. there's a hair of a chance this fixes the 'the manage tags dialog taglist is cut off sometimes' bug -* neatened how some pending content updates are held in manage tags -* manage tags dialogs now receive their media list in the same order as the underlying thumbnail selection, ha ha ha -* untangled some of the presentation import options. stuff like 'is new or in inbox' gets slightly better description labels and cleaner actual logic code -* fixed some type issues, some typo'd pubsubs, and other misc linting -* tried last week's aborted github build update again. the build is now Node 20 compatible diff --git a/docs/getting_started_installing.md b/docs/getting_started_installing.md index d157bb9c0..ebef79156 100644 --- a/docs/getting_started_installing.md +++ b/docs/getting_started_installing.md @@ -133,31 +133,26 @@ To run the client: Although I put out a new version every week, you can update far less often if you prefer. The client keeps to itself, so if it does exactly what you want and a new version does nothing you care about, you can just leave it. Other users enjoy updating every week, simply because it makes for a nice schedule. Others like to stay a week or two behind what is current, just in case I mess up and cause a temporary bug in something they like. -A user has written a longer and more formal guide to updating, and information on the 334->335 step (python2 to python3) [here](update_guide.rtf). - -??? note "The 526->527 step was also important." - 527 changed the program executable name from 'client' to 'hydrus_client'. There was also a library update that caused a dll conflict with previous installs. - - If you need to update from 526 or before, then: - - * If you use the Windows installer, install as normal. Your start menu 'hydrus client' shortcut should be overwritten with one to the new executable, but if you use a custom shortcut, you will need to update that too. - * If you use one of the normal extract builds, you will have to do a 'clean install', as below. You also need to update your program shortcuts. - * If you use the macOS app, there are no special instructions. Update as normal. - * If you run from source, `git pull` as normal. If you haven't already, feel free to run setup_venv again to get the new OpenCV. Update your launch scripts to point at the new `hydrus_client.py` boot scripts. - The update process: -* If the client is running, close it! -* If you maintain a backup, run it now! -* If you use the installer, just download the new installer and run it. It should detect where the last install was and overwrite everything automatically. -* If you extract, then just extract the new version right on top of your current install and overwrite manually. *It is wise to extract it straight from the archive to your install folder.* -* Start your client or server. It may take a few minutes to update its database. I will say in the release post if it is likely to take longer. +* If the client is running, close it! +* If you maintain a backup, run it now! +* Update your install: + 1. **If you use the installer**, just download the new installer and run it. It should detect where the last install was and overwrite everything automatically. + 2. **If you use the extract**, then just extract the new version right on top of your current install and overwrite manually. *It is wise to extract it straight from the archive to your install folder.* + 3. **If you use the macOS App**, just drag and drop from the dmg to your Applications as normal. + 4. **If you run from source**, then run `git pull` as normal. +* Start your client or server. It may take a few minutes to update its database. I will say in the release post if it is likely to take longer. + +A user has written a longer and more formal guide to updating [here](update_guide.rtf). ??? warning "Be extremely careful making test runs of the Extract release" **Do not test-run the extract before copying it over your install!** Running the program anywhere will create database files in the /db/ dir, and if you then copy that once-run folder on top of your real install, you will overwrite your real database! Of course it doesn't really matter, because you made a full backup before you started, right? :^) If you need to perform tests of an update, make sure you have a good backup before you start and then remember to delete any functional test extracts before extracting from the original archive once more for the actual 'install'. +**Several older versions, like 334, 526, and 570 have [special update instructions](#big_updates).** + Unless the update specifically disables or reconfigures something, all your files and tags and settings will be remembered after the update. Releases typically need to update your database to their version. New releases can retroactively perform older database updates, so if the new version is v255 but your database is on v250, you generally only need to get the v255 release, and it'll do all the intervening v250->v251, v251->v252, etc... update steps in order as soon as you boot it. If you need to update from a release more than, say, ten versions older than current, see below. You might also like to skim the release posts or [changelog](changelog.md) to see what is new. @@ -166,7 +161,7 @@ Clients and servers of different versions can usually connect to one another, bu ## Clean installs -**This is usually only relevant if you know you have a dll conflict or otherwise update and cannot boot at all. It usually only applies to Windows or Linux users who manually update using the 'Extract' releases.** +**This is usually only relevant if you use the extract release and have a dll conflict or otherwise update and cannot boot at all. A handful of hydrus updates through its history have needed this.** Very rarely, hydrus needs a clean install. This can be due to a special update like when we moved from 32-bit to 64-bit or needing to otherwise 'reset' a custom install situation. The problem is usually that a library file has been renamed in a new version and hydrus has trouble figuring out whether to use the older one (from a previous version) or the newer. @@ -181,17 +176,58 @@ However, you need to be careful not to delete your database! It sounds silly, bu After that, you'll have a 'clean' version of hydrus that only has the latest version's dlls. If hydrus still will not boot, I recommend you roll back to your last working backup and let me, hydrus dev, know what your error is. -*Note that macOS App users will not ever have to do a clean install because every App is self-contained and non-merging with previous Apps. Source users similarly do not have to worry about this issue, although if they update their system python, they'll want to recreate their venv. Windows Installer users basically get a clean install every time, so they don't have to worry about this.* +*Note that macOS App users will not ever have to do a clean install because every App is self-contained and non-merging with previous Apps. Source users similarly do not have to worry about this issue, although if they update their system python, they'll want to recreate their venv. Windows Installer users basically get a clean install every time, so they shouldn't have to worry about this.* + +## Big updates { id="big_updates" } + +If you have not updated in some time--say twenty versions or more--doing it all in one jump, like v290->v330, may not work. I am doing a lot of unusual stuff with hydrus, change my code at a fast pace, and do not have a ton of testing in place. Hydrus update code often falls to [bitrot](https://en.wikipedia.org/wiki/Software_rot), and so some underlying truth I assumed for the v299->v300 code may not still apply six months later. If you try to update more than 50 versions at once (i.e. trying to perform more than a year of updates in one go), the client will give you a polite error rather than even try. -## Big updates +As a result, if you get a failure on trying to do a big update, try cutting the distance in half--try v290->v310 first, and boot it. If the database updates correctly and the program boots, then shut down and move on to v310->v330. If the update does not work, cut down the gap and try v290->v300, and so on. **Again, it is very important you make a backup before starting a process like this so you can roll back and try a different version if things go wrong.** -If you have not updated in some time--say twenty versions or more--doing it all in one jump, like v250->v290, is likely not going to work. I am doing a lot of unusual stuff with hydrus, change my code at a fast pace, and do not have a ton of testing in place. Hydrus update code often falls to [bitrot](https://en.wikipedia.org/wiki/Software_rot), and so some underlying truth I assumed for the v255->v256 code may not still apply six months later. If you try to update more than 50 versions at once (i.e. trying to perform more than a year of updates in one go), the client will give you a polite error rather than even try. +If you narrow the gap down to just one version and still get an error, please let me know. If the problem is ever quick to appear and ugly/serious-looking, and perhaps talking about a "bootloader" or "dll" issue, then try doing a clean install as above. I am very interested in these sorts of problems and will be happy to help figure out a fix with you (and everyone else who might be affected). + +_All that said, and while updating is complex and every client is different, various user reports over the years suggest this route works and is efficient: 204 > 238 > 246 > 291 > 328 > 335 (clean install) > 376 > 421 > 466 (clean install) > 474 > 480 > 521 (maybe clean install) > 527 (special clean install) > 535 > 558 > 571 (clean install)_ + +??? note "334->335" + We moved from python 2 to python 3. + + If you need to update from 334 or before to 335 or later, then: + + * If you use the Windows installer, install as normal. + * If you use one of the normal extract builds, you will have to do a 'clean install', as above. + * If you use the macOS app, there are no special instructions. Update as normal. + * If you run from source, there are no special instructions. Update as normal. + -As a result, if you get a failure on trying to do a big update, try cutting the distance in half--try v270 first, and then if that works, try v270->v290. If it doesn't, try v260, and so on. +??? note "427->428" + Some new dlls cause a potential conflict. + + If you need to update from 427 or before to 428 or later, then: + + * If you use the Windows installer, install as normal. + * If you use one of the normal extract builds, you will have to do a 'clean install', as above. + * If you use the macOS app, there are no special instructions. Update as normal. + * If you run from source, there are no special instructions. Update as normal. -If you narrow the gap down to just one version and still get an error, please let me know. I am very interested in these sorts of problems and will be happy to help figure out a fix with you (and everyone else who might be affected). +??? note "526->527" + 527 changed the program executable name from 'client' to 'hydrus_client'. There was also a library update that caused a dll conflict with previous installs. + + If you need to update from 526 or before to 527 or later, then: + + * If you use the Windows installer, install as normal. Your start menu 'hydrus client' shortcut should be overwritten with one to the new executable, but if you use a custom shortcut, you will need to update that too. + * If you use one of the normal extract builds, you will have to do a 'clean install', as above. + * If you use the macOS app, there are no special instructions. Update as normal. + * If you run from source, `git pull` as normal. If you haven't already, feel free to run setup_venv again to get the new OpenCV. Update your launch scripts to point at the new `hydrus_client.py` boot scripts. -_All that said, and while updating is complex and every client is different, various user reports over the years suggest this route works and is efficient: 204 > 238 > 246 > 291 > 328 > 335 > 376 > 421 > 466 > 474 > 480 > 521 > 527 (clean install) > 535 > 558 > 571 (clean install)_ +??? note "570->571" + 571 updated the python version, which caused a dll conflict with previous installs. + + If you need to update from 570 or before to 571 or later, then: + + * If you use the Windows installer, install as normal. + * If you use one of the normal extract builds, you will have to do a 'clean install', as above. + * If you use the macOS app, there are no special instructions. Update as normal. + * If you run from source, there are no special instructions. Update as normal. ## Backing up diff --git a/docs/old_changelog.html b/docs/old_changelog.html index 79bebbd3f..0c3fddbb1 100644 --- a/docs/old_changelog.html +++ b/docs/old_changelog.html @@ -34,6 +34,37 @@

changelog