wthit56

Currently, as far as I've figured out, in the HTML we can have {import:...} and it will be accessed. So we can use that to actually run code immediately. Using it this way means it won't be included in the lists for when it's imported into other generators, but we can still use it in that specific page.

But we can't use {import:...}.property or {import:...}(args).

In the lists, we can have imported={import:...} and it will load in but not be accessed. To trigger the access, we have to use [imported] someplace that is accessed--in the HTML, or perhaps $output depending on the situation, something like that. Which is counter-intuitive, as the code we're writing to import it in the first place is literally an assignment (by how it looks at least).

But if it's in the list at all, it's now part of the dependencies included when importing it into another generator. Which, if we're only importing it into the list to be able to call in the HTML, is not explicitly intended by the creator. As this kind of assignment doesn't actually access the imported thing, at least it's not going to actively do anything. But ideally it just would not be required.

On the other hand, it would be useful to be able to simply say {import:...} and have it import, even without a name to store it under. It's clear what the creator wants, from that code. And it works exactly as expected in the HTML panel. On the other-other hand there's no way to call an imported function or access an imported property from just the HTML so it needs to be part of the dependencies of the plugin itself.

If my plugins were actually used by anyone (LOL) this would have been a pretty big issue when I recently made a typo (and got stuck being unable to fix it for a time) in a not-required-at-all import that had to be there purely for the plugin's page to use.

If I could've just imported it and used it all within the HTML panel, it wouldn't have been so urgent, because the error would not have affected any users of the plugin--only my own page presenting it.

The main thing here is, they work differently--seemingly (from the outside from an average creator's point of view) for no real reason. So learning how import works correctly is made more difficult. And learning how it works just for lists or just for HTML is easy... but of course trying to use that knowledge in the other panel leads to confusion and frustration because actually there are different unforeseeable rules there.

Could well be that for backwards-compatibility some of this could not be changed. But perhaps things could be expanded to allow for more features to be cross-compatible, and more expected/very common features to "just work."

https://perchance.org/hash-links-plugin#edit

It's stuck in this while loop. I've seen it happen a couple of times before; it blocks saving too. But normally refreshing/reloading does the trick. For whatever reason, here it always gets stuck no matter what, which means I can't fix a bug in my code, which means that entire plugin and anything that imports it (all my generator pages) breaks entirely. Editing them, I can remove stuff to try to temp fix it, it seems to save, then I reload and the save hasn't actually saved, and there's nothing I can do about it 😬

while (!window[sadf5456])
  await new Promise(r=>window[lkjsfh83](r, 1000));

This is where it's stuck. Something to do with waiting for "riot" to load? ARRRRGHGHG!

While testing it can be frustrating having to "clear cache and hard reload" from time to time just to see the changes I've made in other generators. A "no-cache" option would be great, in whatever form that takes.

It creates objects for the import, but when accessing it it throws the error Cannot read properties of undefined (reading 'getSelf') from line in the getter:

let moduleRoot = window.moduleSpace[moduleName].getSelf;

So it seems like it thinks it's there, but it hasn't actually loaded in at all.

Short-term, a more useful error message would be useful for creators. But ideally, it would actually load in the import when createPerchanceTree is called.

It seems there is no way to have scripts run after everything else. Normally I'd use window.onload or similar things, but all that's been and gone by the time any script is run anyway. So I tried defer. Normally defer means that script will run after non-defer scripts. That would be useful, but the defer attribute isn't heeded by the engine, currently.

https://perchance.org/085unhhfqe#edit

For now I'm going to try using a [code block] just to have it run later. But obviously that won't be sufficient for all situations. So it still would be useful to have some callback or addEventListener thingy to use to run code after perchance has done everything it does.

https://perchance.org/8swe0svvsk#edit

The same exact call in a code block vs a script tag behaves differently. The values seem to arrive to the plugin okay, but then get funky at some point--no idea why.

(Not sure "Update" is the right name for it.)

We have the Refresh button which reloads the whole page. And we have an auto-refresh-some-of-the-page-or-something which keeps the scroll in-place and does other things. Personally I find it annoying (and wasteful of image generations) when it keeps updating and updating as I type. So what I do is, I leave that off.

But then when I want to actually see my changes, I need to use the Reload button, which loses my place and such. So I've come up with this awkward way of turning on Auto, adding a space somewhere to trigger it, and deleting it... just so that it activates that different updating mechanism. And then turn off "Auto" because I don't want it to actually automatically do anything. 😅

I personally would find it useful if there was just a button for that. (And maybe a shortcut for it.)

Caused by this code:

if(!data.prompt) {
d.prompt = data.evaluateItem.toString();
}

It expects the settings object itself to have an .evaluateItem property, which it normally won't have. Ideally it should handle that too instead of erroring. (I've put a failsafe into my advanced plugin for now.)

I think it should always fall back to using "" as the prompt. Which at the very least would stop this error from happening. Though it's still blocked from generating anything with a message. I also feel like it should still just generate an image, unless there's something actually bad that will happen on the server-side because of this that I'm not seeing?

We can use text zoom on the whole page, but I don't need/want the generator page to be bigger, just the code itself. Having separate control over this would be great. My page is designed to look best at a certain kind of zoom level, so I need to keep changing back and forth if I want to see how it looks, know what I mean?

Did someone (like literally just this minute) change how generation works, so there is no .onFinishPromise any more? I've fixed my code but that was sudden 😂

Maybe for backwards compatibility there could be a property called that pointing to the same promise?

Ah I see, the returned object is the promise now, and can be used whether the input was a string or an object.

I see what the code is meant to do... it removes those from the style so it's not on the element. And adds it to injectedStyles for the iframe to see. But that seems to actually do nothing.

For image generation, if you're lucky you see it for a split second before the full-page grey element is shown. So at least there it is actually added by the iframe. Maybe the page background could be made grey by default and the injected style could override, and the grey element could just not have a background. At least then it would work. (Though as we can't change the text colour, people could make an unreadable mess. On the other hand, that's allowed by allowing any styling in the first place ;P)

The gallery doesn't appear to add it at all, though.

Feature Request: CSS Injection

While we're on the topic, I had a feature request... a property to inject full-on CSS. This would make things very flexible. Even allow us to prevent gallery saving by hiding that button, etc. Allow us to cater to dark mode in whatever way we wish also. And this background removing and injecting thing could just be commented out entirely because this new property would do the job... and actually do the job, too.

I automatically use CTRL+S to save quite often. Which is a problem if it's a live, public, released generator and I'm adding features or it's in a half-broken state while I work on it.

I'd love to be able to use CTRL+S to simply save without worrying about that--then frantically rushing to fix it, before I can continue working as I was. Perhaps a local-only save if it's public. (This would go hand-in-hand with the private-by-default idea.) It could save local-only, or perhaps save on the server still but marked as "not the live version" or just keeping track of the version that is meant to be live, something like that.

Then have a separate button to "Make Live" or "Publish" the current version. This would give the creator more control over what is public and what is not, when to release a project and when to keep it to themselves, etc.

Perhaps a confirm() could pop up when closing the tab, if their latest version they saved in the current session is not "Live" so they can easily make it Live if they wish. As a help to people thinking they've made some change live but it's only private to them.