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: [COMPONENTS][WEB PAGE] Far better display of components, regarding compatibility (Read 4283 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

[COMPONENTS][WEB PAGE] Far better display of components, regarding compatibility

Hi there,
I tried the forum search and couldn't find a thread about the state of the component tab. I guess we all agree that the tags section is rendered completely useless by now.
More important:
  • Intranparent whether components are available to V2.0+ or not.
  • Impossible to see what components bind a user to V1.x

I suggest the component list gets
  • a better grouping
  • a new column to be sorted by type
  • a new column to be sorted by availability to different architectures/versions.

Thanks for comments.
Willing to spend a night or two sorting.
 

Re: [COMPONENTS][WEB PAGE] Far better display of components, regarding compatibility

Reply #1 –
And if a components page rework would be done, it would be great to add:
  • License.
  • Link to source code if available.

And I would go further. Force developers, which want to add components to the web, to share the source code and use licenses which allow other people on the future to update it and create new releases. In case someone has a real reason to not do that, nothing stops u to share the component via other medium.

If that was done years ago, we would not have the problems we have today... which is pretty stupid, since we are talking about a plugin for a media player, not a job. But we still get discussions about licenses for plugins not maintained since years, while most of them are fully abandoned,  produce crashes, are not compatible with later versions, etc.

Re: [COMPONENTS][WEB PAGE] Far better display of components, regarding compatibility

Reply #2 –
Quote from: regor on
Force developers, which want to add components to the web, to share the source code and use licenses which allow other people on the future to update it and create new releases

Sorry, but no, I'm completely against it.

- The decision to share code or not can only be made by developers themselves. If you don't trust the dev/binary - don't use it. "But if it's open-source, then you can verify it!" you can say. And you would be almost completely wrong, since nobody compiles plugins from source (and open-sourced components rarely provide a proper build environment for that matter), so to "verify" the component you will have to disassemble the pre-built binary and compare against source code (good luck with that - been there, done that).
- `copyleft` licenses usually means that original developer either can't commercialize his work if he wants to and/or he can't stop others from commercializing his work.

These changes will just demotivate potential (and already very scarce) component developers or force them to ignore component repository altogether.

Quote from: regor on
If that was done years ago, we would not have the problems we have today
A lot (if not most) of most popular components are closed source (Facets, Lyric Show Panel 3, Panel splitter to name a few), and "If that was done years ago", then it's quite possible that we wouldn't have those components at all.

FWIW, I do encourage open-sourcing components with permissive licenses, but I'm completely against forcing it on anyone (f you, Stallman, and your viral GPL license nonsense).

[EDIT] And sorry, I don't believe that "if you open-source something, then if it's abandoned open-source community will rise up and take the maintenance upon themselves". It could happen, sure, but it's as rare as non-pirated versions of WinRAR. I'm using quite a open-source apps (some of them are still pretty popular, and much more popular than most fb2k components) that's been abandoned since forever and there was not a single person willing to fix even a trivial bug in them.

Re: [COMPONENTS][WEB PAGE] Far better display of components, regarding compatibility

Reply #3 –
First, to the original question:
fb2k v2 is still in beta, so even if you think components are a mess at the moment, nothing says it is supposed to stay that way.
Which doesn't mean your question is stupid, it could very well be that there is still room for good ideas.
... if I can come up with one myself: fix the list so that the components available for all, are in boldface or <strong> or whatever is easiest accessible to the vision impaired.
(But isn't it so that the components are soon supposed to include one for each, that the fb2k version will select by itself? Or do I remember wrong?)


As for open sourcing ... I sympathize with both FOSS and the view that software without source code is undocumented, and surely it must have been a PITA to re-implement facets (abandoned by one of HA's supermods) from scratch. But:
 * fb2k itself is not FOSS. That reduces the benefits of a FOSS mandate: those who insist on FOSS will not use fb2k in the first place.
 * There are authors who want to keep their components in their own repositories, there is no requirement to make them available at the official page. foobar2000 is not your cellphone app store and thank God/Dog/Alien Cat for that, but I still would not put up any rules that discourage the use of the official components page.
 * Once the SDK is out, you cannot really stop it from being used. IIRC one SDK license update had a laconic comment that common sense cannot be enforced or so.
 * The way it is now ... it doesn't work perfect, but it works.

Re: [COMPONENTS][WEB PAGE] Far better display of components, regarding compatibility

Reply #4 –
@TheQwertiest

If you read my entire post, I explicitly added a condition "to have the component on the web"... so your concerns are not applicable given that no one is "forced". You want to continue like now, nothing would stop you to post your component here on the forum in such case (?) So this simply move would simply incentivize developers to not create plugins which will never be maintained by someone, while allowing anyone to post their components without code at any other place.

The current situation is simply ridiculous, we have a web component page with tons of outdated components which can not be updated, even if other developers would do it in just a day of work, just because... then we also have a sticky forum post asking to not recommend broken components, while the web announces non-updatable broken components. Don't you see the irony?

Don't really get your other concerns.

No one is making money with components from here, but one developer. And that one is being maintained right now and has its own web, which was my point. And lets not be ridiculous, no one else will make money here. Selling what?  ::)  ::)

Quote
A lot (if not most) of most popular components are closed source (Facets, Lyric Show Panel 3, Panel splitter to name a few), and "If that was done years ago", then it's quite possible that we wouldn't have those components at all.
That's not true. Facets is now discontinued because... XD oh V2. Unless the developer updates it, it's dead. Last update from 2011...

Lyrics show panel has been discontinued since years, with people trying to hack it and add an infinity number of lyrics plugins
 to make it work years later, like every lyrics plugin. Now we have an open lyrics plugin, no more need to continue that stupid situation.

Your argument of popularity brings nothing to the table when all the components which have been open sourced are also popular and have been actively maintained. Also it makes zero sense to compare lyrics plugins popularity when there has been no open sourced one on years... so obviously popularity falls in whatever there is.

Quote
And sorry, I don't believe that "if you open-source something, then if it's abandoned open-source community will rise up and take the maintenance upon themselves". It could happen, sure, but it's as rare as non-pirated versions of WinRAR. I'm using quite a open-source apps (some of them are still pretty popular, and much more popular than most fb2k components) that's been abandoned since forever and there was not a single person willing to fix even a trivial bug in them.
With all due respect, all your "concerns" are effectively nothing. Like you didn't really give a single argument to not ask developers to post source code if plugin is shown on the web.

Even this last argument is just a complain about something which may never happen (?). i.e. if it's closed source and developer disappears, it's gone forever. If it's open source, it may well be abandoned. Yes. Or maybe some day someone will fix X thing. What's the problem with that? XD like your complain is applicable the same to closed source software. At least here there is a possibility to maintain it at some point, even if that never happens.

Don't really understand your reply, since it seems to me based on experience from other software or external personal opinions more than the real situation of this specific software and user-base.

Re: [COMPONENTS][WEB PAGE] Far better display of components, regarding compatibility

Reply #5 –
I don't think I have enough understanding to debate one way or another about licensing and sharing source code, but I can give my viewpoint as a long-time user of foobar2000.

It's very difficult to find some components, and oftentimes when you look you will be directed to older versions linked in old forum posts or shady sites that make you think you're installing malware. It would be nice to have one central location with component downloads so you can both find the plugin you've been looking for in a known-safe place as well as for discovery of new components you weren't aware of yet. Additionally, it really sucks when old components that you rely on break with newer versions of foobar2000, and then you have to decide whether to forgo any future update to foobar or abandon the plugin you have been using because there is no way for anyone to update it without an author who stopped work on it years prior. Lastly, it would be tremendously helpful to be able to click a button in foobar2000 64-bit that would just look at your old 32-bit install, see the plugins, and download all of the 64-bit versions of those. Right now such a thing is impossible.

Thank you for reading.
Think millionaire, but with cannons.

Re: [COMPONENTS][WEB PAGE] Far better display of components, regarding compatibility

Reply #6 –
Quote from: regor on
Don't you see the irony?
No. I see the big one-time problem, but not the irony.
"one-time" in that you don't expect a foobar2000 v3.0 that would kill 64-bitness in ... quite a while.

You cannot retroactively solve the 64-bit compatibility problem. You can of course speculate about the counterfactual: what if the official component page had required source code from day one. You would likely have experienced two effects:
* stricter requirements leads to less availability. Fewer components registered there (and some not published at all, likely, but if people cannot find it it doesn't matter whether it exists).
* stricter requirements leads to those remaining on the components page, complying.

So yes sure. Two sides to it - in a hypothetical world.
As of 2023, the real situation is different: if you tighten the requirements now, you will not get back the old abandoned components, you will only have to throw them out. As far as those components go, it will only make the problem worse. Maybe one could possibly succeed at retrieving source for some new or currently maintained component by thereatening them to be excluded, but it is not going to change the past.

And, if Peter contemplates to enforce such a requirement "from now on" for new components to be listed, he will have to weigh that against all the grumpy e-mails he will get with "but this has no source!" and "this has no source and it is even your own!"


As of now, there is an option to link to source. I'd guess the lesser of the evils is to keep it that way.
(Which, of course, is not my decision.)

Re: [COMPONENTS][WEB PAGE] Far better display of components, regarding compatibility

Reply #7 –
Quote from: Porcus on
Quote from: regor on
Don't you see the irony?
No. I see the big one-time problem, but not the irony.
"one-time" in that you don't expect a foobar2000 v3.0 that would kill 64-bitness in ... quite a while.
It is not only 64 bit compatibility I'm talking about, but broken components since more than 10 years which continue to be listed on the web, there is no source code and developers are absent. Why?

Quote
* stricter requirements leads to less availability. Fewer components registered there (and some not published at all, likely, but if people cannot find it it doesn't matter whether it exists).
* stricter requirements leads to those remaining on the components page, complying.
I don't see the problem here. If people is so lazy to only look at the components page, then:
- It doesn't matter what you do, because they don't read anything.
- The components page should only serve working components and compatible with actual versions to ensure the user gets the right experience. Either you consider the user capable of reading and spending some time looking for things, or you don't. But both can not be at the same time.
- You can put a big warning at top pointing to this forum, for non published components, in case we consider users capable or reading.
- I continue not seeing the problem with people missing things. What's the problem with a component loosing popularity?

Quote
As of 2023, the real situation is different: if you tighten the requirements now, you will not get back the old abandoned components, you will only have to throw them out. As far as those components go, it will only make the problem worse. Maybe one could possibly succeed at retrieving source for some new or currently maintained component by thereatening them to be excluded, but it is not going to change the past.
If they are broken and there is no source code,  I don't understand what we lose. (?) They have to be thrown out. That will happen whether we like it or not.

Your real situation description is not applicable in my opinion. If a developer has not updated a plugin in 10 years and has not given any sign of life, it's absurd to speak about "threatening" or "saving" a component. They will simply don't do anything more with the plugins, that's all. And at some point those plugins will have to be phased out, no matter what we discuss. foo_plorg is broken and gives reproducible crashes deleting playlists, and that's on V1 and V2, for ex. How many more years will be that component listed? 10 more? Why? There is not a coherent policy at all.

https://hydrogenaud.io/index.php/topic,30719.0.html
Quote
The FB2K development team has come to the conclusion that it does not want any known broken components recommended to users on the forums anymore.

There have been a few knowingly broken components causing a lot of stability issues with FB2K. This makes tech support and searching for serious bugs by the developers and moderators very difficult and time consuming.

It's pretty simple, is not about threatening anyone, a popularity plugin contest, or other moral implications of open-source. Either we want maintained components or not. Sharing the source code ensures there is a possibility for that. Simple. No need for overthinking..

I get some of the given points on a general/abstract context, really. But no one has given a single argument about why the current model is working the way it is or how closed source components have helped in any way. Just arguments against my points or hypothetical situations.

The components list needs to be cleaned at some point, there is no way to deny that, and with V2 now is the time. So we can either put some logic for the future or simply repeat the same process from the last 10 years, which is clearly not working.

It's obviously Peter's decision, but I'm surprised to see you answers considering we have more than 10 years of experience with the current model. And it is not working. So I don't really get why there is so much negativity about a change.

Re: [COMPONENTS][WEB PAGE] Far better display of components, regarding compatibility

Reply #8 –
Quote from: regor on
And it is not working
It *was* working though and for ten whole years at that. It only broke because Peter made a 64bit version. And, mind you, he was really against implementing it for quite a long time precisely because of this reason (i.e. component support).

Quote from: regor on
So I don't really get why there is so much negativity about a change.
I fully support original poster ideas for improving components page, so that users can find components for their version of fb2k (and avoid installing components for wrong version) more easily. There is info available about version compatibility though, but it's just not really integrated with the rest of component repo (e.g. text like this Supported processor architecture: x86 32-bit. Works with foobar2000 v1.6.1 and newer).

The only thing I'm against is about *enforcing* open-source'ness.

And Porcus raised a good point: it would be pretty hypocritical to force everyone to open-source their components, while fb2k itself (and it's built-in components) is not. And Peter said many times that he won't open-source fb2k (not while he's still maintaining it at least).

[EDIT]~~~~~~
Regarding broken components: it's a double-edged sword:
On one hand, removing components that causes crashes will make repo "clean" and fb2k to seem stable, which, I agree, is a good thing.

On the other hand, any sufficiently complex component (or program for that matter) will contain bugs with almost 100% certainty. Additionally, all (citation needed) components are purely hobby projects (heck, some component developer don't even have any other programming experience aside from working on those components). So, if we remove all components that can cause a crash, it may include almost all non-trivial components (and even fb2k itself :D).

Similarly, both JSP and SMP (and WSH) were crash-ware at some point (some say that they still are xD). But users still continued to use them despite this, because they offered functionality not available otherwise. Would removing them really benefit anyone?

Another good example is foo_hacks, which is VERY hacky and REALLY unstable, it's not even listed on component repo, but it still had quite a big user-base (judging by the amount of post-v2.0 posts that complained about it being broken).

I.e. a lot of fb2k users consider component functionality to be more important than stability.

A better compromise, IMO, would be to add some sort of a note on the component page, that states the component can cause crashes. But then again, you'll have to put this notice on almost any non-trivial component...

[MORE EDIT]~~~~~~~~~~~~
Quote from: regor on
Your argument of popularity brings nothing to the table.
Why though? My argument is quite simple: forcing developers to submit to FOSS philosophy might dissuade them from making component altogether. Those closed-source components serve as an example of what we (as community) could've lost if such enforcement was in place (it's all theoretical, of course, since I'm not a mind-reader nor can I predict the future).
Yes, v2 broke them. But if FOSS was forced, there might've been nothing left to break at all.


Quote from: regor on
Selling what?
Selling some product based on the parts of component code. For example (IIRC), Peter uses parts of fb2k code for his commercial product.


Quote from: regor on
Don't really understand your reply, since it seems to me based on experience from other software or external personal opinions more than the real situation of this specific software and user-base.
I think the reason why we can't understand each other is that you consider FOSS as something that devs do not care about at all and something as trivial  as "just upload your sources", while I think that for some devs FOSS enforcement might be important enough to abandon the idea of working on a component altogether. I.e. you think that forced FOSS won't impact component dev scene (or that such impact would be negligible) and I think that we might lose much more that we can potentially gain.

PS: I should also add, that such enforcement would also require devs to setup a proper VCS system and maintain it's state, which is a tall order for devs that lack such experience (e.g. for quite sometime I stored all my code on my local machine, because github seemed very hard and I didnt see any value in it).

PPS: And, yes, I do like myself some friday holy-wars :D

Re: [COMPONENTS][WEB PAGE] Far better display of components, regarding compatibility

Reply #9 –
Quote from: regor on
It is not only 64 bit compatibility I'm talking about, but broken components since more than 10 years which continue to be listed on the web, there is no source code and developers are absent. Why?

Because it is better to warn that OK, only use it if you are willing to take a few additional crashes, than remove them altogether?
There is no "perfect / useless" dichotomy. I have used several buggy components. Annoying when crashing. Sometimes worth it.

That "developers are absent" doesn't mean you can shout "open source it!" and they will return with the source code.


Quote from: regor on
Quote
* stricter requirements leads to less availability. Fewer components registered there (and some not published at all, likely, but if people cannot find it it doesn't matter whether it exists).
* stricter requirements leads to those remaining on the components page, complying.
I don't see the problem here. If people is so lazy to only look at the components page, then:
- It doesn't matter what you do, because they don't read anything.
What? Those users who are lazy enough to only look at the components page, it surely matters then whether a component is listed.
That is one of the reasons to have the components page in the first place! We are lazy, we want to use it, we prefer finding it in an official repository where at least it will be removed if malware is detected.

Quote from: regor on
Either you consider the user capable of reading and spending some time looking for things, or you don't.
That is a false dichotomy. I am more than happy to make life easier for myself. Heck, I have a dishwasher even if I am capable of doing the dishes by hand.

Quote from: regor on
If they are broken and there is no source code,  I don't understand what we lose. (?) They have to be thrown out. That will happen whether we like it or not.
Again, there is no such dichotomy. Sure there are components that could be thrown out, but some should stay there until a better alternative is in place (foo_facets comes to mind), and that is a gradual process until one is reasonably safe that a useful component is completely obsoleted.

Quote from: regor on
Your real situation description is not applicable in my opinion. If a developer has not updated a plugin in 10 years and has not given any sign of life, it's absurd to speak about "threatening" or "saving" a component.
No, it is absurd to make those threats.


Quote from: regor on
Either we want maintained components or not.
Again, false dichotomy. We want useful components, and if that means we have to stick with an unmaintained - not ideal, but better judge case-by-case whether it offers value added.

Quote from: regor on
Sharing the source code ensures there is a possibility for that. Simple.
Good idea. Just do some magic and give us the source code of every useful component. Simple!

Quote from: regor on
But no one has given a single argument about why the current model is working the way it is or how closed source components have helped in any way.

Look, if you cannot even realize that components like foo_verifier or foo_bitcompare can help anyone in any way, I suggest you leave the discussion to those of us who actually use them.


Edit @TheQwertiest : I do not find it necessarily hypocritical to demand source code for hosting a component - like, a (sincere!) "listen, this isn't about FOSS principle, it is that whenever something crashes something else I want the code to debug!" would be more a practical concern and I wouldn't call it hypocritical per se.
It will be prone to grumpy accusations of hypocrisy though, and that is bad in itself if you value your time and copypasta-explaining over and over again that "this isn't hypocrisy, it is just the least impractical solution even if it doesn't look consistent" is not your fave pastime.

Re: [COMPONENTS][WEB PAGE] Far better display of components, regarding compatibility

Reply #10 –
Quote from: Porcus on
I do not find it necessarily hypocritical to demand source code for hosting a component (...) (it) would be more a practical concern
Fair enough =)
Just too used to people bringing up enforced FOSS as means to "ensure security of the code", so I conflated issues a bit.

Re: [COMPONENTS][WEB PAGE] Far better display of components, regarding compatibility

Reply #11 –
Quote from: TheQwertiest on
It *was* working though and for ten whole years at that. It only broke because Peter made a 64bit version. And, mind you, he was really against implementing it for quite a long time precisely because of this reason (i.e. component support).
At the risk of sounding like a curmudgeon, quite a few people were asking for a 64-bit version ten years ago. It certainly wasn't needed back then, but it was easy to see this situation would be much worse the later it was created. However, there is nothing we can do about that now.

What would be the best course of action moving forward? I can think of a few things for certain.
- The components page should be purged of broken components that reliably cause issues or simply do not work anymore for their intended purpose. Perhaps they can be linked elsewhere as an archive, but they should not be presented in the main area where most people will look.
- The components page should have a column showing whether each component has 64-bit support or not. It already has a column showing last update.
- The component page should have a link to the source code for components which are already open source. (I think some already do, but not all of them.)

As just a long-time user and not a coder by any means, I'm sure I shouldn't be the one making policy. But I believe regor is correct that right now with the release of 2.0 and 64-bit is the time when future policy should be decided and the components repository should be conformed to said policy.

Sorry if I have overstepped my bounds. Thank you for reading.
Think millionaire, but with cannons.

Re: [COMPONENTS][WEB PAGE] Far better display of components, regarding compatibility

Reply #14 –
Quote from: TheQwertiest on
Quote from: regor on
And it is not working
It *was* working though and for ten whole years at that. It only broke because Peter made a 64bit version. And, mind you, he was really against implementing it for quite a long time precisely because of this reason (i.e. component support).
Just a clarification, when I talk about broken components I'm not talking about components which  could have bugs.

I'm pointing to components which are known to have crashes related to their most basic functionality, without a fix or workaround, not developed since years and without source code. So nothing can be done about it.

I thought that was clear enough... because you have put so much focus on the "forcing devolopers" part, while I'm only asking about some common sense here.

It makes no sense to have plugins listed from 10 years ago, not working on V2 and which also crashes on V1. And unless someone comes with a better solution, I find asking for source code a good compromise for the future. Let me repeat it again. FOR THE FUTURE. (so please, stop saying stupid things about forcing someone to post the code for a plugin from 10 years ago)

The "hypocrisy" argument, being foobar closed source, does not bring anything to the topic for me... I mean, that's just  meta-talking. It's not a reason to do X or Y. I'm asking to solve a practical situation, which is totally different to the philosophical POV of it. Even if we agree it could be ironic.... who cares? If it works, fine. Don't see the FOSS police coming here to arrest us.

Quote
Why though? My argument is quite simple: forcing developers to submit to FOSS philosophy might dissuade them from making component altogether. Those closed-source components serve as an example of what we (as community) could've lost if such enforcement was in place (it's all theoretical, of course, since I'm not a mind-reader nor can I predict the future).
Yes, v2 broke them. But if FOSS was forced, there might've been nothing left to break at all.
Well that's an opinion, everyone has one. I mean... can you prove such statements? No. Nobody knows what would happen, we are just talking about an hypothetical future XD

We only know what has happened up to V2 and simplifying the situation to "before V2 all was great, V2 broke it" is wrong. There were dozen of broken components before, abandoned components, etc.

WSH, SMP, JSP has only been possible thanks to FOSS btw  ::) The same for themes.

Quote
Selling some product based on the parts of component code. For example (IIRC), Peter uses parts of fb2k code for his commercial product.
Peter is Peter, and the rest is the rest. If we go back to the current situation instead of possible future situations, there is zero units of components developers selling anything. But one, which has their own web (so this doesn't apply to they).

Will say it again. I'm not asking about forcing FOSS or a license. I'm asking to publish source code if component is listed on the official foobar web.
- You can post source code with restrictive licenses  ::)
- You can post your component, without source code wherever you want.
- Nothing stops you to create a topic here.
- The "restriction" only would apply if component is listed on the web.

So... really... if doing that means a developer doesn't want to create a component, having dozens of options to publish it,... well... for me that would bring nothing to the community.

Quote
I think the reason why we can't understand each other is that you consider FOSS as something that devs do not care about at all and something as trivial  as "just upload your sources", while I think that for some devs FOSS enforcement might be important enough to abandon the idea of working on a component altogether. I.e. you think that forced FOSS won't impact component dev scene (or that such impact would be negligible) and I think that we might lose much more that we can potentially gain.
I don't really see any reason yet. Sorry. I don't necessarily think developers don't care, or whatever... I'm just being realistic here.

- Foobar is not Spotify.
- There is no money playing here.
- The entire foobar ecosystem is driven by community support, without it is nothing.
- Many developers create a few things, years later move on and disappear. Life happens. In such cases components are lost forever if no source code is provided.
- Most users are looking for components which usually require constant development due to the use of APIS and webservices: lyrics, bio panels, scrobbling, listen brainz, discogs...  Point me to how many of those plugins are closed-source ;) and also point me how many of the closed-source version of those are still working years later XD (none) Well... they have been replaced by open-source versions which allow third-parties to update them when required. What a surprise.

I have not seen any of the supposed "benefits" of the current system, but I'm able to recognize where it fails and also features which will not exist in V2 thanks to the closed-source nature of some plugins without alternatives (like the UPnP/DLNA Renderer, Server, Control Point).

Re: [COMPONENTS][WEB PAGE] Far better display of components, regarding compatibility

Reply #15 –
Quote from: Cannonaire on
Quote from: TheQwertiest on
It *was* working though and for ten whole years at that. It only broke because Peter made a 64bit version. And, mind you, he was really against implementing it for quite a long time precisely because of this reason (i.e. component support).
At the risk of sounding like a curmudgeon, quite a few people were asking for a 64-bit version ten years ago. It certainly wasn't needed back then, but it was easy to see this situation would be much worse the later it was created. However, there is nothing we can do about that now.
Agree.

When 64 bits was asked, usually a stupid discussion followed it. From time to time users pointed to foobar crashing due to RAM limits. It has been delayed for years using the "components compatibility" argument, while at the same time nothing was done to ensure the components created on the last 10 years could be ported.  ::)

It was warned it would be worse if done later.... now here we go.

I see this discussion from a similar POV. Like "we have been doing this for years, you can not change the past". Ok. We can change the future. The current page could even add a "legacy section" pointing to those "old useful" components without source code. I see your arguments as starting points to refine my proposal, not as something which negates it entirely.

I laugh at some of the examples given... like "Facets". Well, if source code was available, then Peter would have not had to recreate it.   ::)

The current situation of having to use "old useful components until a new version appears" only exists due to the current system.... and we are ignoring that. 

We can continue using patches (like ensuring a component from 13 years ago is listed on the main page because it's "useful" even if it's dead or crashes and will never be fixed) or we can fix the root of the problem. At some point, 10 years on the future, we will see where that goes.

In any case, the transition period will be painful for some (developers and users). Obviously. But some of you are seeing this as a false dichotomy because you prefer to do so. Not doing anything, and continuing like before, does bring its own set of problems too. You can not simply ignore them and point to the possible problems FOSS would bring.

It's fine and healthy to discuss problems if FOSS is enforced in some way, but we also have to analyze the last 15 years with objectivity: How the entire 64 bits topic was delayed and treated, which plugins have been developed and why, how Spotify/last.fm/discogs/music brainz/lyrics/Bio plugins have been created (and which ones have survived), how many times a feature has been rewritten due to missing sources, which themes still work, etc. You can not simply ignore one side of this topic or negate the main point by giving some exceptions (which could be treated with an appropriate components policy).

Re: [COMPONENTS][WEB PAGE] Far better display of components, regarding compatibility

Reply #16 –
FWIW...

Arguments about v2 being beta notwithstanding, I think some kind of compatibility matrix/table would be useful (including which is the latest version compatible with what).

As a "consumer" as opposed to "contributor/developer", the way I see it is that I am grateful for what other people have been able to produce, for their own interest and kudos.  If some component I happen to like works in v1 but not in v2, so what?  I just stick with v1, but it would be nice to know what that subset is and what the other subsets might be.  If I'm not mistaken, the value of 64-bit is being able to handle huge music libraries... a first-world problem, surely.

Being able to trace source code with the possibility of somebody else carrying on development of abandonware is a developer thing not a consumer thing, so could be separated away from consumer-level information.
It's your privilege to disagree, but that doesn't make you right and me wrong.

Re: [COMPONENTS][WEB PAGE] Far better display of components, regarding compatibility

Reply #17 –
Btw, about the popularity argument, usefulness and why developers create things...

I find ironic that some scripts like Wil-B's Bio, or last.fm related scripts are not shown on the components page, because well... they are scripts. But components with same features not working today, are there. :)

I mean... if we really cared about developers recognition, I would say the Biography or Library tree script for SMP deserves much more. Many SMP or JSP scripts are more popular or even useful than the native components but they are not posted on the components list. Is "something being useful" or" developer recognition" the key to maintain the current system? Then apply it to all cases and include them.

Btw... scripts are FOSS. And oh surprise, I would say they have been actively developed and created to fix and implement missing things on foobar and components  ::) And whenever someone was scared due to FOSS nature (XD), months later was replaced by another script.
I would go even further, they would grow bigger if more tools are provided to create complex UI elements, popup panels, etc.

I know it's a "script", but hey... that exemplifies some of my points. There is not a clear policy about components, and some of you are just throwing arguments without really thinking how it applies to the entire foobar community. The current system is just a mix of incoherent ideas during years, without a clear roadmap for the community. Some day we say 64 bits is useless, next year here we go V2. Then we rewrite the same plugin 4 times because the previous version it's not working, and later who knows.

Quote
I'm not mistaken, the value of 64-bit is being able to handle huge music libraries... a first-world problem, surely.
The x64 being a first world problem.. well that applies to the entire Foobar. Not sure what's the point  ::)

I mean, it's really ironic some developers are against supporting XP or WIN7 but hey, let's maintain 32 bits 15 years more than it should be. And meanwhile let's block any discussion about switching to 64 bits. (this forum has been like this for years)

At least we don't read anymore posts against x64 XD, it is an improvement.

Re: [COMPONENTS][WEB PAGE] Far better display of components, regarding compatibility

Reply #18 –
If you go to the components page and click on most components (maybe all) the description page contains the following: 'Supported processor architecture: x86 32-bit. or Supported processor architectures: x86 32-bit, x86 64-bit.' Sure its an extra click but that is not really so bad.

Re: [COMPONENTS][WEB PAGE] Far better display of components, regarding compatibility

Reply #19 –
Quote from: oberon0470 on
If you go to the components page and click on most components (maybe all) the description page contains the following: 'Supported processor architecture: x86 32-bit. or Supported processor architectures: x86 32-bit, x86 64-bit.' Sure its an extra click but that is not really so bad.
The extra clicks add up when you're looking for the latest version for 20+ components. I see the eventual release of stable 2.0 as likely the best time to refresh my install from the ground up to get rid of any cruft that has built up over the years. It is possibly also a good time to move to 64-bit as a future-looking measure, but only if the components I rely on work with it.
Think millionaire, but with cannons.

Re: [COMPONENTS][WEB PAGE] Far better display of components, regarding compatibility

Reply #20 –
Well unless it has been updated since 8-18-2022 you know it is 32 bit. That eliminates most of the components right there. So you read through the ones that are left and if you see any you are interested in you click on it to see if it is for x64. The whole operation will probably take less time than it did for me to post this.

Re: [COMPONENTS][WEB PAGE] Far better display of components, regarding compatibility

Reply #21 –
The most prolific, knowledgeable and helpful component developer is Case and he's always made a point when asked in the past that his components are not going to be open sourced. I think it's safe to say no changes are ever going to happen to the official component repo in this regard. If you lot want to waste your time on hypotheticals, knock yourself out but you won't get anywhere with it.

Re: [COMPONENTS][WEB PAGE] Far better display of components, regarding compatibility

Reply #22 –
Quote from: marc2k3 on
The most prolific, knowledgeable and helpful component developer is Case and he's always made a point when asked in the past that his components are not going to be open sourced. I think it's safe to say no changes are ever going to happen to the official component repo in this regard. If you lot want to waste your time on hypotheticals, knock yourself out but you won't get anywhere with it.
That's fair. As much as open source would help components, I feel like this thread has gotten a bit derailed seeing as that wasn't even brought up by OP.

The fact remains that the current system, or the current repository at the very least, is a mess. It is causing users undue stress, and I agree with OP and others who have spoken here that the repository could use improvements for both usability and clarity presenting information. I believe v2.0 is a great time for such change, but I also concede that I'm not the person who would need to put in the work to make it better.

My points in above posts are still valid, even though in all likelihood there will be no open source requirement. Lastly, I just want to affirm that I understand how much impact Case has had, and that it felt like a godsend seeing how Case recompiled the Stereo Convolver plugin I use for v2.0 and 64-bit.
Think millionaire, but with cannons.

Re: [COMPONENTS][WEB PAGE] Far better display of components, regarding compatibility

Reply #23 –
In the Japanese wiki, we prepared early (Not all from the beginning).
New Components, Change log, Easy usage, Update information is necessary.
There may be errors due to lack of knowledge, differences in interpretation by language.
It's Japanese, but I hope I can be of some help.

foobar2000 Wiki for Japanese Users

Components for foobar2000 v2.0 beta 32bit/64bit
https://foobar2000.xrea.jp/?Components+for+foobar2000+v2.0+beta+32bit/64bit

Update (foobar2000, Components, SMP/JSP Scripts, Codec, Audio Tool etc...)
https://foobar2000.xrea.jp/?%E6%9B%B4%E6%96%B0%E7%8A%B6%E6%B3%81
SHURE SRH1840, SENNHEISER HD660S2, SENNHEISER HD 490 PRO, DT 1990 PRO, HiFiMAN Edition XS, Bowers & Wilkins P7, FiiO FT5, 水月雨 (MOONDROP) 空鳴 - VOID, Nakamichi Elite FIVE ANC, Bose QuietComfort 45 (made a Upgrade/Balanced Cable by myself)

Re: [COMPONENTS][WEB PAGE] Far better display of components, regarding compatibility

Reply #24 –
I worked since some months in my spare time on getting Components Wiki pages updated.
Since November they are to some degree in sync with things happening in components world, but nonetheless far from complete.
I just posted information and status here:
Foobar2000 Components Page(s) - Migration to 2.0

Cheers, Oby