quote:
Originally posted by (CyBeRDuDe)
, yeah forgot about that. Of course it's easy finding the path to the AppData using the right API's, or just simple %AppData%, or the likes. Well, yes the right thing to do is to make all plugins compatible with older Windows, but this is just a pain for the developers, most plugins never reach out of testing stage, or they might be released as a final, but they will never truly be completed 100%, and spending time testing the plugins on other windows version and different scenarios is just to time consuming, where you would spent much time on this, you could instead be spending the time on making the plugin more usefull and more functionallity or better functionallity.
Isn't that what a good decent developper does? I mean, every beginning script kiddie can make something, it is only a good developper who thinks about such stuff as customizations or how his program will react in different environments or even simply thinking about how and where to safe data... And then I'm not talking about making something downwards compatible with all windows versions at all, but simply the fact to use the proper methods and thinking about user experience etc, because there can be a very good reason to not make something downwards compatible or it can be a choice by the developper. But that doesn't mean he shouldn't be thinking about the stuff anybody will expect, especially when releasing something in public.
If a developper can't bring it up to do some little research or to think about some stuff then I rather call those developpers lazy or even script kiddies, to put it in a very rude way for the sake of this discussion (no pun intended)... You don't need to do/learn much to know most obvious things (eg: a file save dialog instead of a hard coded location, or at least a reg setting, etc.)
Also, without these proper methods and proper ways of thinking, I can't see how you can improve something or make something more usefull or with better functionallity. As it is exactly those things which are the basis for more usefullness and better functionallity to begin with. If you don't think about that, all you create is a bunch of incoherent half-working features. You might have many features in that way, but what good is that if half of them don't work with half the users, or contain bug after bug, or are missing obvious things, things which would make them actually usefull?
quote:
Originally posted by (CyBeRDuDe)
I myself personally don't care about compatibility with older windows, because I make these plugins for free, by own will, and by request.
Yes, I know what you're saying. But compatiblity isn't the real issue here.
(That API comment about the %appdir% is only given as response to that specific example. But even with that, you don't need to do much research, it is well documented and if you use the proper API you can be sure it is compatible, you don't need to put lots of tricks and tweaks in your code to make something comptaible -most of the time-)
As said, compatiblity can be a choice or not. But what I'm talking about are the (little) things which are almost obvious or mandatory for anything you put in public. Eg: a simply way (doesn't need to be fancy or good looking or whatever) to choose where to save something. This can be a dialog, a reg settings, heck even a resource hack or whatever.
quote:
Originally posted by (CyBeRDuDe)
If there is a special request for it to be able to run on lets say Win98, I might do some research in it, but until now I haven't seen much requests like this...
True, but what I mean is, if you use the proper method, you don't need to do research at all or make it compatible, it will be automatically compatible anyways and you will have your "bonus" automatically without any special effort.
eg: to take that %appdir% example again. Simply provide the user with a way to choose it for himself. Result: never problems at all, in any circumstances. It will even save you time because then you wouldn't need to fix your code or answer requests from users.
As for demand for plugins. Plugins are almost only created "on demand". But as soon as someone requests something, most developpers make something for the public, not for that specific user. This also means the plugins should be using the proper methods and not some method specifically to that user. Otherwise you wont release a plugin in public. Because, afterall, you only want your plugin to be used by as much people as possible if I'm not mistaken. And if not, you'll explicitly say it in a post that it is especially custom made and may not work...
The thing is, as developper, you at least need to think about such stuff (you even don't need to implement it for all I care, but simply be aware of such stuff). And thus not bluntly do something without thinking about it, because then you'll get a request for X and a request for Y and bug rapport A and bug rapport B...
And of all the many plugins I've seen, there are very extremely few which are not made with the thought of
"make it for the wide audiance" or
"make something so everybody is happy", even if they were requested by only 1 person... and even fewer which are explicitly marked as unfinished or beta or something (most plugins are not beta, or don't have a clear distinction between beta and final and are mostly simply published directly as "finished")...
And in that aspect, and to conclude my rant
, some set "guidelines" (thus guidelines, not rules), as meant by n0n4m3 are very good indeed.
quote:
Originally posted by (CyBeRDuDe)
Maybe we all could agree to save the data in "Application Data/MsgPlus Plugins/<Plugin Name>" since this would make sure that users don't suddenly have 100 different folders in their Application Data folder which already is filled with lots and lots of folders... Or something like that... 
...
I, as a plugin user, would sure like that if that is done by default...
... Well that's to say, I rather see it happening in a subdir of the plugins folder though... (even only for the fact that programatically getting the plugins folder is far more easier than getting the proper appdir, and the plugins folder is also far more easier to get to in Windows for the average user, etc.)
(and thus, certainly also a way to customize that, IF possible )
So my vote would go to (for saving data files), in this order:
1) make it customizable (it doesn't really matter where it points to, by default, in this case. Although, of course, it would be nice if also has the same order of preferences as said in point 2, 3)
- by means of a configuration dialog setting
- by means of the regisrty
- by means of a hack (eg: resource/patch)
2) a sub directory in the Plus! plugins folder (with prefereable the name of the plugin/DLL)
3) in the same (!) main folder as where Messenger Plus store his custom sounds. This means if this is the appdir from the current logged in user, use that one, if this is the appdir from "all users" use that one, if this is a "data" subdirectory in Messenger Plus! own directory, use that one. The name of the subdir should be the plugin name/DLL.
Point 3 also shows another problem you might have with getting the same main folder as where Plus! store his sounds (usually appdir). Though the plugin save folder doesn't need to be in the same path as the one from the custom sounds, but I think this is the most usefull, friendly way without creating more chaos.
Also in defense of point 2, think about backing things up (or the likes, like copying and whatever). It is far more easier (and logical) for the user to backup all the plus! files including it subdirectories, than to backup the plus! files and then also needing to navigating to appdir or what not and make another backup of that.
--------
PS: all this said, I think I remember that at one time I also made such a request for a guideline. But that one was for the location of plugins settings in the registry as some plugins save them in the "Plus! plugins" map, some in the "VBA settings" map, some in the "software" map, etc... not to mention the difference between "current user" and "local machine"...
/ 
