Ideas for complete control over a curated gallery (behind a setting).

Only show people their own saved images in the public gallery. Other galleries can work as normal, but images they didn't add to the public gallery are hidden from the user.

The owner can see all images in the public gallery, nothing hidden there. But they can mark (and unmark) images as being part of the actually public facing gallery that everyone can see. Maybe just an extra button to toggle this is shown on the image if the owner is viewing it. (But also an always-visible icon or border colour or some indication as to whether it's already in the true-public view or not.)

So then you have a situation where the owner has full control over what everyone sees, but anyone can still add their own images to the public gallery. This is all smoke and mirrors, really, just filtering out images not owned, unless you're the owner of the generator itself. So it may not be too much server-side stuff to do.

Another take, perhaps even simpler (but more annoying to maintain for the owner): Have a property on the prompt/gallery call which contains a list of allowed images. Maybe one for blocked images too (which people have been requesting).

This could potentially be part of a separate call that just reminds the server what the settings are for this generator.

Or a property that can be set on the text_to_image function itself which is then taken into account for any images or galleries generated after that. Which would avoid having to send it every time a call is made. (I'm guessing the user block list etc. is currently sent on every call?)

Or ideally it would just be something stored on the server--which brings us back to the original idea if having an interface for it built in.

Could potentially use a separate generator for it though... like you pass in the id of a generator as a property on the gallery/image call. The server can then look that up without any extra AJAX stuff or message passing required at all, cached server-side until it's edited, etc. And a similar solution could be used for ban lists also. This method gives a lot of flexibility to the creator, and lower overhead on performance and network traffic. And it's even extensible with more "server-side data" options into the future. (Though I have no idea if this method would be better or worse from a dev standpoint.)

The advanced image plugin was in service of my advanced image generator. Which is now out! It has many features, but it's not focused on automatically adding opaque prompts you don't have control over. It's more about giving the user many tools to generate the prompts themselves.

All settings have (i) tooltips explaining what they do.

Your device's dark mode will work. Images automatically scale so they can be fully seen in the viewport.

> Of special note, there's a "prompt only" setting which will just show you what prompts are generated.

> And a "plain text" setting which makes the prompts not dynamic--you're just sending them direct to the image generator on the server.

Generator update thread on discord: https://discord.com/channels/970057744612724746/1276832370518921228

This line errors, if the iframe has been removed when there's a message received about it (completion I guess?):

464: document.querySelector(`iframe.${privateIframeId}`).contentWindow.postMessage({type:"originNotify", frameId:privateIframeId}, serverOrigin);

I guess because you're always copying everything onto the window object?

So if you then call it yourself, because "you don't think it's been called automatically, because why would it? You haven't told it to do that"... it's actually being called twice.

Anything that's ever inside a tag with some attribute (eg. no-perchance) would not be evaluated whatsoever. This could be an easy way to allow creators to skip evaluation for entire sections of their page when they know they never want stuff in there evaluated. Also saves processing time looping through those elements (presumably), etc.

Or potentially, even provide a $ignoreHtmlSelector property (defaulting to [no-perchance] perhaps) to let the creator straight-up tell the engine what to ignore.

You could use the .closest(selector) on a node to figure out if it's in an ignored element. Or perhaps do a document.querySelectorAll(":not(" + $ignoreHtmlSelector + ")") to find only the elements you need to evaluate within and loop over those.

Link I’m guessing only the dev can answer this.

@[email protected]

I'm now coming up against the issue you thought I was having before. Where after a [code block] is processed it's evaluated. But if using a <script> tag to do things it won't be.

I don't want evaluation to happen. So I could escape perchance specials to work right when returned to a code block, but they won't be evaluated by scripts so they'll still be there on the page. Or I could not escape perchance specials to work right from scripts, but they will be evaluated by code blocks which I don't want. I just want plain text to always come out no matter what.

And there's (seemingly) no way of knowing if it's going to be evaluated at the end of a code block or not. And no way of just telling perchance "LEAVE THIS STRING ALOOOOOONE!!"

Is there anything I can do or is this just not possible in any way?

If not, I'd really super-duper like it if you could add a way. Even if it is as simple and "dumb" as setting a property on the object like .DONTEVALUATETHIS = true or something. I'd really appreciate it.

Or even something like if it has .evaluateItem = "..." it'll automatically use that instead? Maybe? I tried that in case, and it didn't work.

Honestly, I'm surprised this isn't an issue for all sorts of plugins. Though maybe it is assumed that everyone only ever calls anything from code blocks and not scripts. Or people just don't think about or have instances where the plugin returns HTML that includes specials that they want to stay plain text.

But as I'm doing my best to make my plugin bulletproof no matter how it's used... it's driving me insane 😅

So if you happen to have made changes to the code, even reloaded and partial-reloaded a bunch of times, none of that matters. Only the actual save. This is unexpected, as "duplicate" is sort of a "save as..." kind of function in my mind.

I recently was working on a bug, and duplicated the generator to narrow it down before reporting. But the bug didn't happen in the duplicate. Took a lot of testing to figure out why that was.

To return true if there's anything to evaluate in the object. Like for a string, if there's some valid {option|s} or [code blocks], that kinds of stuff.

I explored this here: https://perchance.org/481tgbwo1k#edit

I can't even guess as to what's happening with some of this. Most bizarre...

As seen here: https://perchance.org/ius2f4kd5y#edit

As seen here: https://perchance.org/ihmcs2z5nn#edit

__perchanceError() doesn't show on the page, or in the console. throw new Error() doesn't either.

Edit: Similar for in a <script> tag. The error does go to the console, but no perchance error shows up. So later if you call a function that wasn't created in that script tag because of that hidden error, you just get the error that the function isn't there--as if there was no problem with the script tag, but the function just isn't there, for no apparent reason.

Would be better if the script tag's error was also shown in the perchance error box so it doesn't lead to misleading reporting like this.

At the moment there's a lot of "clutter" in what is logged; it seems to all just use console.log which counts under the "info" category. And means anything the creator logs for their own "real" debugging is much harder to see--especially with more complex generators with many imports and nested imports.

If debug was used instead, the creator could choose to see all those things by turning on the "verbose" category in their dev tools. Or leave it off, and see the "info" channel with their own logs very easy to see and much more useful.

It's always funny when I get a perchance error in the red box that's some obscure problem internally. It's like "here's some common mistakes," but the mistake is actually not the user's fault and they're not making any mistakes--the perchance engine is 😅

Main thing is... the error message will mean absolutely nothing to most creators, and just look real scary. (I'm able to figure things out to some degree because I'm a web dev.)

It would be good to either catch problems early and handle them without erroring, just logging a warning perhaps.

Or maybe throw up more useful/readable messages, careful to mark it as an internal perchance issue--so then average creators can report that issue, and more advanced "hacky" users like me know it's because they're poking around with the internals.

Or you could have it just marked as an "internal error" and have an expandable <details> panel with the real error inside. Again, so advanced users can figure things out, but average users aren't like AWHAAAAAAAAAA~~~?!

If you have a generator that has been saved at least once, you can open its settings and choose to delete the generator. You then need to confirm. If you do, it says the generator has been deleted, and it will take you to the homepage.

But then if there are unsaved changes, it has that warning about leaving the page. But As the user has confirmed they want to delete the generator, saving doesn't even mean anything anymore anyway. If they cancel and stay on the page, they can continue to edit and even save.

When they save, though the save fails and the preview shows a warning like: (⊙.⊙) sorry, we cannot find a generator called curxte4k6u! and it never comes out of the saving state.

It's all a bit pointless and there's no point in ever staying. I'd say the expected behaviour is that after it's been deleted it shouldn't care if there are unsaved changes anymore, and just let the redirect to the homepage happen as expected--without that confirmation popup.

For what I'm building I don't particularly fancy the full gallery--for reasons. But I wouldn't mind a button users can click to open the overlay version. I think I may be able to replicate that looking through the text-to-image plugin... maybe. But it would be great to just have that as an option. Like, the normal way of producing the gallery, but add overlay=true to have it show the overlay instead.

Also, some "official" way of closing the overlay--perhaps something as part of the returned value when asking for an overlay? Perhaps even a property on the imported text-to-image-plugin I could call to close any open gallery overlays.

And an easy way of finding the outermost overlay container div (it's all just styles right now, so I've got a somewhat brittle css selector to query based on the iframe's src). Perhaps include a useful id or attribute. I've got something working fine, but would be a good feature to have in place as part of this.

Edit: Oh also, I feel like Escape should close the gallery overlay. And perhaps there should be a clear button to close it.

Might be useful. Could potentially be used to trigger retrying the generation, maybe with stronger (nsfw) negative prompt, something like that. Or just hiding that generation entirely.

So if you just want to adjust it, you don't have to type it all in or copy-paste.

(Pro tips can still come from non-pros, right? 👀)

I only started doing this recently, but it's a lot better for my stress levels 😂

I change the title to DEV ONLY so I know how safe it is to edit the functionality etc. I also have a banner in the HTML that shows if I'm not actually editing the original "real" version, which also reassures me.

Then I can break stuff, save to my hearts content (I have an itchy save-finger). And only copy it across to the real version when I'm happy it's safe. Just remember not to overwrite the $meta stuff if that's different in your dev copy. Though if you accidentally do that, the backups are very useful for quickly grabbing what you need to put back.

For the name, I call it the same, but with -dev- in there somewhere, and -4958734957 a load of random numbers at the end so it's super unlikely people could stumble across it.

I'm not too studied-up on CORS, but I know what it's there for. Currently there's a number of things that are not possible to do because our generator is on a different subdomain than other generators or iframes, etc. etc. and even the top-level page we're actually on.

With that allowed (I think CORS can allow this), there's a lot more customisation we can do of things like t2i image iframes and gallery iframes, reading/changing the top-level url, etc. Maybe that's something you don't want to allow, but I for one have wanted to do these things for completely benign legit reasons multiple times.