(09-06-2013, 06:57 AM)xemnas Wrote: [ -> ] (09-06-2013, 05:49 AM)neobrain Wrote: [ -> ]There are two points I'd like to mention here: One is that it's often a better not to let users make too many choices (you'll likely disagree; it's one of those things end users never understand). The other (and more important) one is that there are other (and better) ways to provide choices to users.
You can provide default plugins. The rest is up to the users. If it doesn't work, they can revert to the defaults.
Yes. It's "up to the users" is a good thing to say when you're not the one having to deal with the newbies who come to the forums crying that they have no idea what they're doing. That's one of the many points why adding choices is often bad. But well, this argument is going a bit off-topic...
(09-06-2013, 06:57 AM)xemnas Wrote: [ -> ] (09-06-2013, 05:49 AM)neobrain Wrote: [ -> ]Yes, that way you end up with lots of useless issue reports because people use outdated cores/plugins and/or incompatible plugin combinations. Also if people decide to only update plugin X while keeping everything outdated, that's the best way not to get any testing done on anything but plugin X. So you end up with less issue reports on stuff that's happening currently and more invalid reports. But it's cool, because users have had choice after all.
I don't see how it's a useless issue reports. If it's plugin-based, it's expected that users will mix and match plugins.
Yes, in an ideal world that would be true. Now, emu projects usually don't have any sort of at least (semi-)professional QA team, so things break. Plugin interfaces get used in ways which are perfectly fine within the scope of their documentation but yet hit edge cases which haven't been considered in the old implementation. Or plugin interfaces just get misused unnoticedly because the current plugins just seem to work while older versions crash.
(09-06-2013, 06:57 AM)xemnas Wrote: [ -> ]Also, what is more likely to happen is the user will use a stable version of the core and update all plugins or use the latest version of alternative plugins.
You'd think that. Heck, we still have people running around with Dolphin r7719 on our forums...
Some people do everything to fix some bug or to get more performance out of there build and call it a day once they're happy with it, ignorant against any sort of possible improvements that happen once they've made their choice.
(09-06-2013, 06:57 AM)xemnas Wrote: [ -> ] (09-06-2013, 05:49 AM)neobrain Wrote: [ -> ]Yes, thanks to Dolphin's plugin interface lots of people went ahead and wrote their custom video plugins. Oh wait, they didn't.
Also, just because you "can write code" doesn't mean you a) know how the emulated hardware works b) have any idea of how to code emulation software. There's exactly zero benefit for inexperienced people to write new plugins. And the experienced people who write plugins from scratch anyway suffer from NIH.
That won't happen in reality. I think nobody expected that a lot of people will write custom video plugins but it provides the possibility. I don't see your point though. What is the difference from non-plugin? It's no benefit either if inexperienced people try to write code for a non-plugin. Regarding writing the plugin from scratch, it's the same as writing non-plugin code from scratch.
Having a plugin interface encourages people to screw existing code and rewrite it from scratch. Not providing such an option while using an open development model instead encourages people to look at existing code and improve it, which generally is favorable. I don't see any point why it would not be favorable, anyway.
Even more, once people get in the uncomfortable situation of having 5 different plugins for each thing, it'll drive away new developers: when you want to fix some bug but have to chose between one of 5 different dumb code bases which you need to get familiar with just to chose one to work with and improve on - would you still be motivated to actually do that or would you rather end up being confused enough to not improve anything at all?
(09-06-2013, 06:57 AM)xemnas Wrote: [ -> ]I just said that plugins are quite popular.
Yes, my point was that you really cannot compare Firefox's addons with emu plugins. I guess we agree on that.
However, if instead of developing separate plugins developers just focused on improving a single code base, there would be no user desire for being able to switch plugins in the first place.
(09-06-2013, 06:57 AM)xemnas Wrote: [ -> ] (09-06-2013, 05:49 AM)neobrain Wrote: [ -> ]You don't have to "see" the source code of the core module to build it.
When testing a plugin you'll have to build the plugin before testing either way, and there's effectively zero difference between compiling a plugin and compiling the "plugin" code and relinking the application. You don't need to rebuild the core each time you change your plugin code because build systems take care of not rebuilding everything when only a part of it changed..
Maybe I chose the word incorrectly. It would be more accurate to use "have" instead of "see". It doesn't need to be the source code. It could be compiled libraries. In any event I need to have them to build a non-plugin application. For plugin-based I just need the minimal related dependencies. I don't need to sync any code, it doesn't matter because it will be plugged to a main module which could be built separately. I'm not saying which way is better; I merely point out the difference.
Yes, that actually makes sense. It's one of the things I wouldn't consider as important though.
