Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: foo_uie_webview (Read 75526 times) previous topic - next topic
0 Members and 8 Guests are viewing this topic.

Re: foo_uie_webview

Reply #525 –
Quote from: ApacheReal on
Quote from: yeyo on
Quote from: ApacheReal on
Quote from: ApacheReal on
Quote from: yeyo on
Quote from: ApacheReal on
@ yeyo

I made the changes to the spin disc of your version and they are now compatible with the latest version of the foo_uie_webview plugin.

I didn't post it out of fairness to you.
Feel free to share, I'd love to!

Ok tell me if it's okay. I changed the background color, image path and icon management beyond opening the container box.

Do not download this version because it does not update the images.

@ yeyo if you can post your updated version, without runservice and info track, which I'm not interested in, and I really don't understand it, you'll do me a favor.

Thank you.
Note the case of the refresh function. After reading your template, the function name is "function Refresh()" and the place where it is called is ”refresh()", please change it to ”Refresh()“.

Maybe it was just this. A way of things has changed Changes to Functions and Properties
Methods:

GetArtwork should be getArtwork.

GetFormattedText should be getFormattedText.

Callbacks:

OnPlaybackStarting should be onPlaybackStarting.

OnPlaybackStop should be onPlaybackStop.

OnPlaybackPrevious should be onPlaybackPrevious.

OnPlaybackNext should be onPlaybackNext.

To say I'm angry is an understatement. But for what then for this Changed: Returned JSON objects now use camelCase casing. (alpha4)
Changed: *Breaking Change* Callbacks follow the Category-Noun-Verb naming convention. (alpha5)
Changed: *Breaking Change* All properties, methods and callbacks to use camelCase convention. (alpha5)
Changed: *Breaking Change* The parameter list of most callbacks has been expanded. (alpha5)

I have 13 scripts to edit never never never.......

This is not the reason why the template cannot update the image. JS functions are strictly case-sensitive. Be consistent when calling them. Change "refresh()" in your template to "Refresh()" and it will work as required.

Re: foo_uie_webview

Reply #526 –
That's what happens if you use a framework on alpha state which is obviously changing on every release, not sure what did you expect.

Also... there are proper tools for that like notepad+ or VSCodium, which make changing method names a matter of 2 seconds. It seems like you are simply not using the proper tools with a minimum of error checking. There are scripts out there having x1000 more lines of code and files and updating them is not so hard as long as you use the right tools.
 

Re: foo_uie_webview

Reply #528 –
@yeyo tell me if it's okay. The problem is all my other scripts

Re: foo_uie_webview

Reply #529 –
Quote from: regor on
@pqyt
Do you plan to add some kind of handle / handle list support?
I don't see the connection with fb2K. Which feature are you referring to? I'm working on adding library support now.

Re: foo_uie_webview

Reply #530 –
@yeyo I solved it with the spin disc modules but not with my other scripts, it's not just the refresh that needs to be changed.

So I can throw them away now as I don't have a guide on what I need to change

Re: foo_uie_webview

Reply #531 –
I also solved it in my modules thanks to yeyo's FUNDAMENTAL indication.

However, let me say that when you make such a significant change, you also give an indication for those who then use the plugin.

Now I'm going to rearrange quite a few modules with Refresh() practically everywhere.

Re: foo_uie_webview

Reply #532 –
@yeyo On the Spin Disc I found another problem: the double click that applies the mask is not maintained when changing tracks.

Re: foo_uie_webview

Reply #533 –
Quote from: pqyt on
Quote from: regor on
@pqyt
Do you plan to add some kind of handle / handle list support?
I don't see the connection with fb2K. Which feature are you referring to? I'm working on adding library support now.
On SMP/JSP you can manipulate handle lists, as far as I have seen there is nothing for that here.

You have callbacks and TF but they simply evaluate or pass hard-coded handles (now playing, etc.) or file paths. The selection methods for ex. just report indexes and file paths.

So that's why I ask about it, if you plan to implement handle lists, retrieving library items, etc. as objects, not only file paths.

Not that I'm requesting it, just asking if it's planned, . If someone expects to do anything more than simple UI elements, they will be needed. Creating something like Library Tree (SMP) for webview would be a nightmare or just impossible without a full handle/handle list implementation. I don't really think forcing to work with track paths for all methods is the way to go. But obviously it all depends on the scope you want for the component.

Quote
However, let me say that when you make such a significant change, you also give an indication for those who then use the plugin.
I would say a version number including ALPHA or below v1.0.0 or several lines about breaking changes is indication enough, and it's a pretty reasonable assumption that people who write scripts should know what they are doing and understand those points.

Re: foo_uie_webview

Reply #534 –
Quote from: ApacheReal on
@yeyo On the Spin Disc I found another problem: the double click that applies the mask is not maintained when changing tracks.

Solved I hope.....

Spoiler (click to show/hide)

Re: foo_uie_webview

Reply #535 –
Quote from: regor on
Quote from: pqyt on
Quote from: regor on
@pqyt
Do you plan to add some kind of handle / handle list support?
I don't see the connection with fb2K. Which feature are you referring to? I'm working on adding library support now.
On SMP/JSP you can manipulate handle lists, as far as I have seen there is nothing for that here.

You have callbacks and TF but they simply evaluate or pass hard-coded handles (now playing, etc.) or file paths. The selection methods for ex. just report indexes and file paths.

So that's why I ask about it, if you plan to implement handle lists, retrieving library items, etc. as objects, not only file paths.
I see. The binary interfaces between SMP and IE are gone. I found no COM interop between a host and WebView2. WebView2 can call binary code via a 'host object' and the host can call script code.

I've looked at handles but I can't estimate the lifespan of a handle value when transitioning from fb2k binary code to the JavaScript world. I'm worried about handle leaks.

Re: foo_uie_webview

Reply #536 –
Quote from: ApacheReal on
I also solved it in my modules thanks to yeyo's FUNDAMENTAL indication.

However, let me say that when you make such a significant change, you also give an indication for those who then use the plugin.

Now I'm going to rearrange quite a few modules with Refresh() practically everywhere.
I'm sorry for your rework but now was the time to introduce the breaking changes. The methods and callbacks introduced in the alpha versions were still in flux but I realize changing the pre-0.2 methods caused some pain.

Re: foo_uie_webview

Reply #537 –
I have yet another module to sort out... difficult and demanding and who knows how many problems I will still find

Re: foo_uie_webview

Reply #538 –
Quote from: ApacheReal on
I have yet another module to sort out... difficult and demanding and who knows how many problems I will still find

Learning should be a life long ambition.

Quote from: regor on
Creating something like Library Tree (SMP) for webview would be a nightmare or just impossible without a full handle/handle list implementation. I don't really think forcing to work with track paths for all methods is the way to go. But obviously it all depends on the scope you want for the component.

The starting point should not be, what we could recreate, but what we can newly create.
Doing the things I've already done with webview would be a nightmare or just impossible to get to work in JSP SMP, not least of all due to shit memory issues with the frameworks. @pqyt has the right idea there.

Both are stagnant waters for many reasons, not least of which the learning curve to get something useful.
They are more backend tools and webview is more of a frontend tool (currently) and it's about damn time FB has one; not to mention one with far more applicable real world applications, e.g internet?!

I've already achieved more with it in a few months, than 15 years prior.
They may be "simple UI things" to you, but I've seen few, if any of them around here in all that time.
@flagstaff/br3tt was a master of UX/front end and look how his work hangs on here zombified and worshipped 10 years later.

Re: foo_uie_webview

Reply #539 –
Quote from: mjm716 on
Learning should be a life long ambition.

I try to learn from the best, I'm doing my best....

Kaledoscope



Go ahead calmly there is no image prohibited...



Moderator: please keep music clips under 30 seconds

Re: foo_uie_webview

Reply #541 –
Quote from: mjm716 on
The starting point should not be, what we could recreate, but what we can newly create.
Doing the things I've already done with webview would be a nightmare or just impossible to get to work in JSP SMP, not least of all due to shit memory issues with the frameworks. @pqyt has the right idea there.
I don't see how any of that relates to my remarks. Obviously rendering HTML + JS is going to be easier for UI things since you are just working over +20 years of work from other people xd Who doubts that? That has nothing to do with the scope of the component, and if the idea is to manage a library (because foobar is a music player with a library), then you need something else, not just buil-in UI web frameworks and file paths management.

Also, people using JSP and SMP and previous components were just being lazy/selfish because everyone just created their own scripts without any kind of shared design. i.e. everyone has been repeating the same things over and over. JS frameworks doesn't work like that. Obviously it's a pain in the ass to create a chart in SMP vs web view, but you have to create a charts framework once. Then everybody can reuse that. There has not been evolution of SMP/JSP scripts because of that, just 2/3 devs creating their scripts until they got tired. There were no frameworks provided, everything had to be coded from scratch. I created my Timeline-SMP script which can be used to display arbitrary charts, library stats or a timeline with dates/artists... but anyone else can just reuse my statistics framework and create their own thing (for ex. a Spotify Wrapped alternative). It's there, with docs. No one has done it; why? Because other people just prefer to say "hey look, my component is better" and do similar things in their own component just for the sake of it. (that's pretty much the recap of the last 10 years of WSH/SMP/JSP & scripts development)

Finally obviously web view is not going to have memory issues if you are just rendering single art   ::)  I have said it many times, I can crash JSP, SMP or any JS based component as long as I add enough data. Whenever this component adds some kind of library management + tags support for handle lists, then it will be a problem if you use 32 bits and you have a library of 300K tracks. If you try to load into web View 10K covers at the same time, it will be the same. That has nothing to do with component design, data requires ram and you can not have infinite ram in 32 bits. (ex. 300K tracks x 18KB for a raw ChromaPrint fingerprint = 5 GB ram)

It seems some of you get offended if I say "simple UI things", but it is what it is. Right now. I'm not talking about the component, I'm talking about what people have been doing with it. If someone creates a script to replace biography/library tree, find similar tracks, create interactive charts by library stats, reproduce a youtube video by selected artists, etc., then it would be different. And "simple UI things" is not a derogatory name. Many things in Web view are pretty simple xd they are not in JSP/SMP. But they are just that, UI things. So I asked the dev to understand what will be the scope of the component to think about creating my own scripts here or not.

Re: foo_uie_webview

Reply #542 –
That's what I was implying...

Quote from: mjm716 on
Both are stagnant waters for many reasons,

Clearly you, myself, @MordredKLB and others have been fed up with the situation for some time.

Quote from: regor on
Obviously rendering HTML + JS is going to be easier for UI things since you are just working over +20 years of work from other people xd Who doubts that? That has nothing to do with the scope of the component, and if the idea is to manage a library

Yep. (actually ~30) years for people here to draw upon and finally new sprouts are beginning to take hold.
Who the hell wants to reinvent the wheel to increase the delightful nature of their music player.

It certainly has much to do with the current scope of webview.
As we both agree, there are half-baked backend tools here for awhile, but doing UI with them has been a misery.

Managing a libary with webview is your own projection. Maybe yes, maybe no.

Obviously doing so will cost memory, but you're also overlooking webview existing in threads outside of FB which doesn't crash when shit goes bad. I've already tried things in x86 FB that have run webview threads >6GB (which I could always kill manually if necessary) and FB was still running fine.

Also as I've said many times in the past, I would love to use your charts framework - comprehensive libary statistics would be my utopia - but it doesn't get off the starting block (for me!) because the core components crash foobar with the first computation of your framework.

(I NEED this in FB!)


Quote from: regor on
And "simple UI things" is not a derogatory name. Many things in Web view are pretty simple xd they are not in JSP/SMP. But they are just that, UI things. So I asked the dev to understand what will be the scope of the component to think about creating my own scripts here or not.

You are naturally looking after your self-interest, but if not derogatory, you are definitely over valuing engineering and under-valuing creativity; while not exclusive, neither is that easy. There has long been a vacuum of simple UI/front-end things here.

The recent 7000 posts about 16+ year-old vumeters, which broke Marc's brain/spirit, shows the interest in silly UI things is just as great as for those looking for the next great js smooth playlist.

Re: foo_uie_webview

Reply #543 –
Quote
Obviously doing so will cost memory, but you're also overlooking webview existing in threads outside of FB which doesn't crash when shit goes bad. I've already tried things in x86 FB that have run webview threads >6GB (which I could always kill manually if necessary) and FB was still running fine.
Obviously if you are running things outside foobar, you can do whatever you want. I don't get the point of that... if you are saying this component can run 6GB data in foobar x32, that's another thing. It can't.

Quote
Also as I've said many times in the past, I would love to use your charts framework - comprehensive libary statistics would be my utopia - but it doesn't get off the starting block (for me!) because the core components crash foobar with the first computation of your framework.
You simply refuse to use foobarx64 and JSplitter, but that's your problem. You can not ask foobar to handle +3gb of ram for things running within foobar without x64 binaries.

Quote
You are naturally looking after your self-interest, but if not derogatory, you are definitely over valuing engineering and under-valuing creativity; while not exclusive, neither is that easy. 
That's just your supposition about me.  ;)  Which is fine, everybody may have opinions. I would love this component to grow and support both sides.

Quote
There has long been a vacuum of simple UI/front-end things here.
That's for sure. But it has not been due to JS usage vs Web View, which is my point. SMP also supports HTML parsing and CSS, is just that some people avoid to use it because it breaks wine compatibility ;)

Anyway I agree HTML and CSS are easier than using just JS, and we share similar thoughts about most things.

Re: foo_uie_webview

Reply #544 –
Quote from: regor on
Quote
Obviously doing so will cost memory, but you're also overlooking webview existing in threads outside of FB which doesn't crash when shit goes bad. I've already tried things in x86 FB that have run webview threads >6GB (which I could always kill manually if necessary) and FB was still running fine.
Obviously if you are running things outside foobar, you can do whatever you want. I don't get the point of that... if you are saying this component can run 6GB data in foobar x32, that's another thing. It can't.


All the things that can't be done, right?

Re: foo_uie_webview

Reply #545 –
Quote from: mjm716 on
Quote from: regor on
Quote
Obviously doing so will cost memory, but you're also overlooking webview existing in threads outside of FB which doesn't crash when shit goes bad. I've already tried things in x86 FB that have run webview threads >6GB (which I could always kill manually if necessary) and FB was still running fine.
Obviously if you are running things outside foobar, you can do whatever you want. I don't get the point of that... if you are saying this component can run 6GB data in foobar x32, that's another thing. It can't.


All the things that can't be done, right?
? That's running outside foobar, as you are showing. Yep xd

That doesn't change that once the component thread tries to access more RAM than available on x32 it will crash. Which may have not happened to you yet, great :) Because no method currently exposed will do that. All current methods work on single paths.

You can obviously load 200 GB in a web view thread outside foobar, that proves nothing. You may well be loading external images, or the entire wikipedia xd Data is not being managed by the component at that point. Wait until there are methods for library management and you try to parse TF over 300K tracks.

Right now all your point is like saying I can run firefox with a CMD command via SMP and load 200 GB there. Obviously, you can. And you can also send back and forth data via JSON as long as you are sending anything under <2~3gb. Which is essentially what this component does (but showing the "firefox" window within a panel). And whenever this component tries to send bigger than that, it will crash on x32. But obviously that will never happen in UI scripts.

Re: foo_uie_webview

Reply #546 –
You are just purposely argumentative and it's not an appealing characteristic whatsoever.

Quote from: mjm716 on
existing in threads outside of FB which doesn't crash when shit goes bad

If you'd like to do something productive, why don't you review the chart data above and show a POC that any of them are even possible with your framework?

Re: foo_uie_webview

Reply #547 –
Not spending more time to prove anything, anyone with a bit of knowledge about how threading works would understand you are simply mixing things. It's not a matter of being able to do X or Y with any component, if you just span 3rd party threads outside foobar, they obviously have ram limits according to their own process. But data exchange between the external thread and component (unless done async in chunks) and storing size limit (this has no workaround) is still limited to x32 limits if you use foobar x32.

Want to test it?
- Use .print(text) method on a JSON parsed data greater than 3Gb.  In fact probably if you pass it as an object it will crash when trying to parse it ::)
- readAllText(filePath, codePage) on any text file greater than 3 Gb. (unless the dev coded it in some magic way to parse the file on chunks or the file is actually read by webView process directly)
- getPlaylistItems(playlistIndex) may also fail if the playlist is too big.
- I suppose the shared buffer only exposes the current playback and not the entire audio file, so that should be safe for big audio files.
- GetArtwork(artworktype) works fine as long as it's called on single tracks. If at some point it may be called on an entire list, it will crash when passing more than 2 Gbs.

The list will continue to grow when more methods are added which return metadata on batch, etc. And obviously you see nothing of this because the current scripts are obviously not designed to do anything of this, and the current component is designed mainly to manage a single track (now playing/selection) and display things for it. Now perform a lookup by fingerprint in the entire library and that's an entirely different thing.

I'm out of this conversation, you seem to not want to understand how thing works on purpose. You are happy that way, fine.

Re: foo_uie_webview

Reply #548 –
Quote from: regor on
I'm out of this conversation, you seem to not want to understand how thing works on purpose. You are happy that way, fine.
@regor

please don't leave mad and when things start to get interesting.

I read your insights but you overlook the point I made earlier:

The API of WebView2 does not support a binary interface besides simple datatypes (integer, string, boolean), at best arrays of those simple datatypes. I could create a 'cursor' API that can be called from JavaScript to handle large data sets but the marshalling will always be thru JSON (unless someone with more experience contradicts me now).

That means that the 'state' of the cursor must be maintained in the component, relying on the Javascript to call an API to release the resources at appropriate times. That's a big responsibility in these days of managed languages.

But I think it can be done.

Re: foo_uie_webview

Reply #549 –
Quote from: pqyt on
please don't leave mad and when things start to get interesting.
Just not continuing arguing about using foobar x32 and saying RAM limits is not a problem for some components (depending on usage).

Quote
The API of WebView2 does not support a binary interface besides simple datatypes (integer, string, boolean), at best arrays of those simple datatypes. I could create a 'cursor' API that can be called from JavaScript to handle large data sets but the marshalling will always be thru JSON (unless someone with more experience contradicts me now).
I know, I know.

Even if no other datatypes are available,  at some point I imagine you would at least provide some method to run a query against the library (even if it just return paths), and also TF evaluation over a list (even if it's over a list of paths on library), etc. That will output either JSON or just an array.  And then, at that point, it's the component the one providing the data (and thus RAM limited on x32).

Quote
That means that the 'state' of the cursor must be maintained in the component, relying on the Javascript to call an API to release the resources at appropriate times. That's a big responsibility in these days of managed languages.

JSP has methods to dispose objects, and that has been the standard in all JS components until SMP, where automatic garbage collection took care of that (although that opens other set of problems if you want to finetune RAM usage). Also callbacks involving objects just pass temporal pointers, and they are invalid after a few ms outside the scope of the callback call (so you are forced to deep clone them before using).

Anyway, without having any idea about the SDK. I don't think you really need to expose the actual internal data of handles at all. You can pass an object compatible with JSON just containing the same data found on SMP. i.e. Raw Path, path, subsong index, etc. All your methods would ingest that object, and the actual matching with tracks would be done internally by your component (being invisible to the web view code) -either by raw path + subsong or with some internal uuid-. That would involve some performance loss, obviously, but it's doable.