>>16133 ty >>16146 i would really love the tooltip option, i prefer having ISO but having both is very nice

I had a mixed week, but I got a couple of neat things done. I fixed a handful of bugs, wrote a 'tag actually exists here' filter for tag siblings/parents export, and added local file/thumbnail path fetching to the Client API. The release should be as normal tomorrow. >>16216 Thank you, fixed for tomorrow!

>>16196 >typical modern faget blaming others for his own shortcomings >millions of them everywhere expecting the world to cater their whims Positively this is the result of a home without a father. You have to go back to Reddit.

How do I lock tags for a file once I'm sure it's definitive so that new imports from boorus don't fuck with it? Is creating a separate tag service the only solution?

>>16222 Afaik you go to network -> downloaders -> manage default import options. Then either you set one of the two defaults for watchable/post url on top right of the window, or you double click on an entry in the list and set custom settings for this entry alone, let's say "danbooru file page". There you activate or deactivate the checkboxes that you need like in the image of following post: >>15842

https://www.youtube.com/watch?v=1ySAkB-H33E windows zip: https://github.com/hydrusnetwork/hydrus/releases/download/v591/Hydrus.Network.591.-.Windows.-.Extract.only.zip exe: https://github.com/hydrusnetwork/hydrus/releases/download/v591/Hydrus.Network.591.-.Windows.-.Installer.exe macOS app: https://github.com/hydrusnetwork/hydrus/releases/download/v591/Hydrus.Network.591.-.macOS.-.App.dmg linux tar.zst: https://github.com/hydrusnetwork/hydrus/releases/download/v591/Hydrus.Network.591.-.Linux.-.Executable.tar.zst I had a bit of a mixed week, but I got a couple of neat things done. Full changelog: https://hydrusnetwork.github.io/hydrus/changelog.html highlights I fixed a stupid mistake in last week's 'move left/right after page close' thing, which was doing it even if the page being closed was not the current focus! Also fixed is the share->export menu not showing if you only right-clicked one file. The tags->migrate tags dialog can now filter parent and sibling tags based on tag count. You can say 'only include pairs where the A/B actually exists on service x', where for siblings that B is the ideal tag at the end of the chain. I hope this makes it easier to filter giant multi-hundred-thousand pools of pairs, like from the PTR, down to only what matters for your 'my tags' etc.. The Client API has a new simple permissions mode for access keys, a convenience state just called 'permits everything', which does exactly what you think and is intended to be an easy catch-all for people who just want to turn on future-proofed access for an app they trust. On update, any access key that looks like it was told to permit everything in the old system will be updated to this mode (you will get a popup saying this happened, too). If you do need finer control, you can still tweak individual Client API permissions under services->review services. Relatedly, the Client API gets a new permission this week, 'see local files', and commands to fetch local file and thumbnail paths. If you want to access files directly on the local machine for metadata analysis or whatever, this is what you want! next week I'm sorry to say I have been unproductive recently, so I'll keep it simple. I think I want to try some duplicate auto-resolution database stuff. I still need to think about a couple things, so I'll play around a bit and see what makes the most sense. Fingers crossed, I'll have the skeleton of the maintenance daemon sketched out.

>>16221 >a home without a father Is that the meme of the week or something?

>>16225 "fatherless behavior" has been a normalfag meme for over a year or more now. And also a minor nig meme. This is just a variant.

>>16225 Do not take it lightly, single and divorced mothers are a civilizational problem and revoking the emancipation of women is long due.

>>16224 Wow! I've been waiting for that relationship filter feature for over 3 years! I didn't expect it to just be added out of no where thanks a bunch! If I could ask for a small (I assume it's small) option though, I'd like it if the "only" checkboxes could have an "OR" option or something like that. Basically what I mean if that I'd like the siblings or parents to be added if either one side or the other has counts, rather than it needing to be both when I check both boxes. Or is that already how it works? I just wanna make sure before I pull the trigger. but anyway, I'm really glad this is finally here!

>>16224 I appreciate the "for convenience, I moved stuff around in the access permissions" on upgrade to 591, both the action and the warning so I'm aware without reading the full changelog. Thanks for treating us so well!

>>16228 >Do not take it lightly, single and divorced mothers are a civilizational problem Who is picrel for? > In all OECD countries, most single-parent households were headed by a mother. The proportion headed by a father varied between 9% and 25%. It was lowest in Estonia (9%), Costa Rica (10%), Cyprus (10%), Japan (10%), Ireland (10%) and the United Kingdom (12%), while it was highest in Norway (22%), Spain (23%), Sweden (24%), Romania (25%) and the United States (25%). These numbers were not provided for Canada, Australia or New Zealand. https://www.oecd.org/content/dam/oecd/en/data/datasets/family-database/sf_1_1_family_size_and_composition.pdf > and revoking the emancipation of women is long due. In Russia, fatherless families are more likely to be ruled by the mother's parents, and old women are often sadomasochistic slavers who love strong men, illusory rules and hierarchy, and know that they will not be imprisoned or sent to war. If you are talking about the right to vote, guess what.

>>15916 >>>15901 >>The derpibooru downloader downloads descriptions without the links in them. :( >I will check it out. I don't know how this thing works, but if it is just pulling the visible 'text' of the html, and the URL you want is in <a href="xxx">, it may be tricky to get that in a neat way. The hydrus note tech is only plaintext for now, so no proper rich text or links or anything yet. The example urls in the "default" one have no interesting descriptions. Here is one with a link and a quote (the ">" becomes an entity): https://derpibooru.org/images/2680312 The link is preserved. The quote is not. I may have been looking at a description fetched from a mirror that had lost the link. If there is still a reason, there is a hidden form that contains a textarea with the Markdown source of the description.

>>16236 >with the Markdown source of the description. with entities for ">", at least

>>16236 >The link is preserved. The quote is not. Sorry, I meant the leading ">".

tangentially related to Hydrus but Mozillia recently announced renewed interest in adding Jpeg-XL (JXL) support to Firefox, thanks to a new rust-based library for it that a Google research team is developing for them (crazy, I know). also the JXL website got an overhaul and looks really nice, even including a direct jab at AVIF.

>>16236 Sorry for rushing and not reading or thinking. It is indeed about things linkified with href. Another issue is that images included in the description leave no useful trace. An image included from any site directly like in https://derpibooru.org/images/3448782 is ignored completely. An image included from derpibooru itself like in https://derpibooru.org/images/3450178 is replaced by "This image is blocked by your current filter - click here to display it anyway your current filter.", although there is no filter that should block it.

>>16240 >An image included from any site directly like in https://derpibooru.org/images/3448782 is ignored completely. and note that the image is included using derpibooru's proxy, and original url appears in the invisible Markdown, but not in the HTML.

>>16239 >google developing a rust library for mozilla to use >same google that has been stonewalling jxl >same google that made jxl ???? I know google is big and all but I would have thought that the teams would at least appear to be in agreement in public.

>>16242 This is how I understand the situation: The "research" team is very much a fan of JXL and wants to see it adopted. The chrome team doesn't want JXL because (I think) they don't want the maintenance burden and don't care about the benefits of a new format. The problem is that the chrome team has much more clout with the heads of Google than the research team does, so they usually get their way, and they did with Chrome removing JXL support. The research team still believed in JXL even after Google as a whole was no longer backing it, so they asked if they could write a new library for JXL in a memory safe language (Rust) to hopefully reduce the maintenance burden and security risks of supporting a new image format. The Google heads said that they could, but that Chrome still won't support it even if they do, and they're only allowed to work on it if some other meaningfully significant project would use the library. The team knew that Mozilla was somewhat interested in adding JXL support to Firefox, but that Mozilla was apprehensive about fully committing to it, because of the security risks of merging a large library written in a memory-unsafe language (C++) into their flagship browser's stable release. So the research team contacted Mozilla to see if they were interested in Firefox being the project that the research team needed to get the go-ahead from their higher-ups, and Mozilla agreed. So here we are. source: a bunch of reading on different websites about the topic that I didn't save the sources for because I'm not a journalist. I wish I did save the sources though. It's an interesting situation.

>>16241 It is very simple and the ">" appears as ">". [30, 7, ["description from Markdown", 18, [27, 7, [[26, 3, [[2, [62, 3, [0, "textarea", {"id": "description"}, null, null, false, [51, 1, [3, "", null, null, "example string"]]]]]]], 1, "href", [84, 1, [26, 3, [[2, [51, 1, [2, "^((?!No description provided\\.).)*$", null, null, "pony"]]]]]]]], "description-md@derpibooru"]]

>>16245 ponerpics uses a different syntax https://ponerpics.org/images/7063333?q=blood+cell the twibooru page does not have any source code in it https://twibooru.org/3344908

>>16243 Appreciate the run down, I was wondering what all the google drama about JXL was. -t not >>16242

>>16242 >firefox deving >google salary Living the (professional browser dev) dream.

>>16249 >google salary That is the TOTAL dream.

>>16208 Thanks, this makes sense. Rather than trying to fix each watcher parser, I should just hardcode a rule for subject parsing to clean up any html garbage. >>16214 >>16215 The straight answer is: not really, but maybe in the future. The technical problem is that Ugoira is, fundamentally, a list of pngs/jpegs (often stored in a zip) and then some frame timing information (either transmitted as JSON or hardcoded into a javascript viewer). I forget the details of Pixiv specifically, but I think they'll let you download the raw zip, but then we'd need to figure out some hardcoded bullshit where we download the JSON/javascript and convert to a .json that we then embed in the zip. It isn't impossible, but it is a pain in the ass. A user was looking into it, since I was taking so long to get to it, and his feedback was not overly enthusiastic. iirc there seem to be even more pains in the ass on the Pixiv side; it really is an unusual site. Also, to be straight, hydrus does recognise an ugoira (it is under the 'animations' filetype), and it'll give you a thumbnail, but it won't render yet, and we don't have json timing parsing yet (the json-inside-the-zip part is unofficial, not part of the ugoira standard, and though I have seen it done elsewhere, we'd ultimately be inventing our own proprietary standard here). The danbooru-style 'use a hardcoded script to convert it to an mp4' is not a bad solution, and I see why they go for it. >>16217 Good idea, I'll have a think about this. I have also been using 'locations' as the word in code more often. >>16229 Does running the job twice, once with the first guy checked, and then with the second one checked, do an OR for your case, or is your workflow a bit more complicated and it needs to be done at the same time? You are right, if you check both, I'm pretty sure it does 'gotta be count on both sides'.

>>16254 >Does running the job twice, once with the first guy checked, and then with the second one checked, do an OR for your case Well I think not because if you run it on a tag with (for example) checking old siblings for counts, and an old sibling doesn't have counts, then that relationship is discarded, so when you check it the second time for new sibling counts, that relationship won't be there now for Hydrus to say "oh the new sibling has counts, so let's keep this one" right? I'm not sure if I understand what you mean though. My workflow is just that I used to sync with the ptr and I want all of the relationships that are relevant to my local files to be kept and the rest discarded. by "relevant" in this case, I mean if any of the tags on either side of a relationship exist in files I have, then it should be kept, but if the entire relationship is only tags that don't exist for me, then it should be discarded. Does that make sense? Actually now that I think about it, are you asking if doing a migration from the same archive twice would work, once with the checkbox checked for one side, and once with the checkbox checked for the other, but both times on all tag relationships in the archive? If so then I think that would work, as long if it'll migration the relationship regardless of which side has the counts. I'm not sure if a double migration is safe though, and I don't wanna do something that could clobber my db, especially since if it does clobber it, it'll be the relationships which is something that I might not notice for a while. But since my case is simple (I think it is anyway) maybe it's safe. I'm just worried about a subtle breakage.

>>16236 >>16240 Thanks, I understand better now. I think I get slightly different parsing results to you; perhaps that is due to your using a real login and me being a guest? Maybe your user account has some note display options or something. picrel is what I get for all three files. I see the markdown in the hidden form you are talking about. I am not sure if a typical/default user wants the markdown stuff, since having just the URL may be nicer, in raw text form, than "[https://www.kickstarter.com/projects/partylikeanartist/my-little-pony-fan-made-charity-coloring-book](https://www.kickstarter.com/projects/partylikeanartist/my-little-pony-fan-made-charity-coloring-book)", but I can see that the current parsing does miss embedded image URLs and stuff. Maybe I should add a second note parser, or maybe I should make a second derpi parser that grabs raw markdown notes. I think probably the former, even if it is spammy. Spammy notes is a larger problem than this that I need to come up with a nice solution for otherwise. Looks like maybe I should just fold this into the default?: >>16245 Let me know what you think I should do here! >>16239 >>16242 >>16243 (Thank you!) This makes me feel good/hopeful. JpegXL is my personal favourite of the new standards, and I hate how it has been sidelined. If we can get actual support in a big browser, then that's a potential first domino to everyone else following, just like webm was on /gif/ in the old days. I'm sure there are still many ways this could be scuttled, but let's keep our eyes on it. As soon as JpegXL support becomes real for PIL (e.g. https://pypi.org/project/jxlpy/ becomes more real and/or is folded into the main branch), I'll add it to hydrus in a week. Thinking about it more, I can appreciate more google's reluctance to add a new attack surface by integrating this. I'm sure the recent webp stuff has only made made them more frightened. BUT, I'll say, you don't build a ship to keep it in port--we need new image formats, so it sounds like we need a group of really clever guys to figure out the problem as best they can, I wonder if google knows anyone like that. Good on the research team, if so, for continuing to push.

>>16255 Thanks, your workflow makes sense. Yeah, I was thinking in terms of copying to a new service. I will add a checkbox for OR!

>>16257 great! thank you!

>>16256 >>>16236 >>>16240 > Thanks, I understand better now. I think I get slightly different parsing results to you; perhaps that is due to your using a real login and me being a guest? Maybe your user account has some note display options or something. picrel is what I get for all three files. Maybe I meant that the blockquote stops being a blockquote and is turned into a paragraph. Everything else seems like what I'd seen earlier. >I see the markdown in the hidden form you are talking about. I am not sure if a typical/default user wants the markdown stuff, since having just the URL may be nicer, in raw text form, than "[https://www.kickstarter.com/projects/partylikeanartist/my-little-pony-fan-made-charity-coloring-book](https://www.kickstarter.com/projects/partylikeanartist/my-little-pony-fan-made-charity-coloring-book)", That's either how the user wrote it, or leftovers from some old bug. Normally Markdown links look like <http://example.com/> or [example site](http://example.com) >I think probably the former, even if it is spammy. Spammy notes is a larger problem than this that I need to come up with a nice solution for otherwise. Maybe if middle-clicking a note's title asked if you want to delete it? >Looks like maybe I should just fold this into the default?: >>16245 That seems to be working well. Consider the note name though: the window is small. The default ponerpics parser does not get a source or description.

>>16257 The confirmation window and progress popup do not mention the new filter.

>>16259 Thanks, I will roll that extra note parser into the defaults. There is 'note import options' that let users control which notes are parsed, but tbh that panel is overengineered and pretty garbage from a user-friendliness perspective, so that's another thing to think about overhauling here. I'm afraid I don't think I have a ponerpics downloader in the defaults, so did that come from the repo at some point? https://github.com/CuddleBear92/Hydrus-Presets-and-Scripts/tree/master/Downloaders although I don't see it there--unless ponerpics is a synonym for ponybooru or something? Is it this one: https://github.com/CuddleBear92/Hydrus-Presets-and-Scripts/blob/master/Downloaders/ponibooru-tag-search-2018.11.29.png ? I'm afraid I just don't know much about this community--if you know what to do, please feel free to update that downloader and submit a pull on the repo to update it there. >>16260 Damn, thanks. I forgot to write the text for them!

>>16261 Then I probably made the ponerpics downloader myself and forgot and made a "customized" copy.

>>16262 It's https://ponerpics.org and may be parseable by derpibooru parser.

>>16261 Here is the difference between my customized derpibooru parser and the ponerpics parser.