Are all of those talking about image generation?
Oh damn.
Yeah, some generators should be dealt with. And a system to report that would be useful. (In the past I've posted here about a bad generator and it was dealt with pretty quick.)
Sounds okay 👍
Right. But the way it's presented is not like "select a file, copy, paste." It's "click an option from a menu." As I said, more like "save as." So intuitively people (or I) think of it working that way, is all.
And the whole "reload so it saves but doesn't really save" is mentally confusing too. It feels like a "soft" save that just isn't public. Which adds to this feel that it's sorta already saved, and so duplicating it would copy that latest soft-save.
I mean we can go round and round about this, but I've presented what I'm talking about in the post. It's a request for a change to how it works, so it's up to the dev to comment really.
Yes, I've been doing that. The issue is that my plugin allows the user of the plugin to have a function that returns html. That html is then eventually returned by the plugin.
But depending on if it's being called by a code block and injected that way, or being called by a script tag and being injected with .innerHTML
... those backslash escapes will be stripped out, or they won't. It behaves differently. Try it and see.
The solution I added here in a comment works to detect it, but really it shouldn't be necessary.
A different public gallery curation idea
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.)
Advanced Image Generator
Uses AI to generate images, including many simple but powerful tools to add depth and variety to images.
![Advanced Image Generator](https://lemmy.world/pictrs/image/fc9cbf48-ab00-4027-a679-6a6f75ab0bf1.png?format=webp&thumbnail=256)
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 prompt:
slim person. jumping· feeling positive; punching, up, smiling eyes open; asian foot, looking· loving BREAK low small clouds· thick ground mist heavy blue BREAK colour mud minimalism (seed:::893326274)
Fairly often gives stuff like this:
Text-to-image assumes the iframe will be in the page by the time it completes generating
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);
New bug: the code expects there to be a href attribute on every <a>
tag. There may not be, at which point it breaks.
Defining function onload() {} will call it
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.
perchance to ignore certain elements, not evaluating any of their text
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.
I... might have found a solution. It's super hacky, but simple enough.
if (!document.currentScript) {
// escape specials
}
document.currentScript references the script tag in the DOM that is currently being processed. Or null
if no script tag is being processed. Luckily somehow this works? I guess because the [code blocks]
are (luckily) being processed in an event, something like that?
Of course, this is extremely brittle, but will do for now I guess. Same as my using __evaluateText
😅
I can't even use html entities because they're converted and parsed as well 🤦 AAAAAAAAAAAAAAAARGRHRGRGHRGHJRG
Cool cool… I guess this could be built in to $meta as a property with a setter? 🤔
@[email protected] I'm mentioning you in a comment as well because someone told me no notifications are sent for mentions inside posts. Is that right?
return html without it ever being evaluated.
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 😅
Duplicating a generator copies the save, not the current code (even reloaded/partial-reloaded code)
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.
.canEvaluate
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.
Great--I'm so happy! :D
I'll bookmark this comment and come back to let you know if I spot more logs that should be .debug()
Okay it all seems to work now. Maybe the change didn't make it to my browser or something but it's all good now 👍
Interesting that for that demo page only the __perchanceError()
does anything. There are several other errors happening on that page, but none make it to the console or the perchance error box.
You can also just not use the update at all. (People can still call it on the other side, but you don't need to use that as the mechanism by which you change stuff.) You can just use regular JS and set it up to work however you want it to work.
Very odd things going on with giving objects
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...
Setting document.body.innerHTML triggered by a breaks saving
As seen here: https://perchance.org/ius2f4kd5y#edit
If there's a missing prop= there is absolutely no error reporting
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.
Put all the usual loading/init etc. messages under console.debug()
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.
Different error reporting for perchance-internal errors
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~~~?!
Unsaved generator changes trigger confirm after deleting is confirmed
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.
Gallery overlay
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.
Pass .maybeNsfw along to the result object for onFinish()
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.
Change url should start with current url
So if you just want to adjust it, you don't have to type it all in or copy-paste.
Pro tip: make a private dev copy of your plugin/generator
(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.
CORS between domain and subdomains, and cross-subdomains
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.