Shoutbox

Hi,

I noticed that at least 2 plugins save a file in the directory where they're installed (I already alerted the developers to change this.) This shouldn't be done and the reason is that if you install things as an administrator user and then change to a normal user, it probably won't have permissions to write in the plugin's directory (normally normal users don't have permission to write inside the "Program Files" where most plugins are). That's why I suggest you to save your plugin's files in a folder like this: Documents and Settings\username\Application Data\Plugin dir

It's a good idea, and suggestion.. But I doubt this will be taking as a serious note.. .. I don't think many developers wants to do this... And the easiest place to have a plugin save it's data is in the same folder as the program is installed.. That's pure sense...
IMHO (But this is probably beacuse i'm running without user accounts and the likes) I hate when other programs put loads of shit into my documents and settings, and Application Data... I just HATE it... I don't want random programs to store random things a place like that.. If I decide to install my program to my d drive because i'm in lack of harddrive space on my c drive (or any other reason), then this program is supposed to stay and only use space on my d drive... No where else... This is just my view and probably only because of the way I use my computer and orginise my shit on my hard drives...
Though, I see the problem that plugins migt not be able to write to the "Program Files" dir... Though why don't you just install messenger plus a place where the users have access to write to?... Messenger Plus have an option to change installation path... And all plugins makes sure they are installed in this path and saves their data their.. This kinda eliminates your problem...
Anyways.. Your suggestion is still good and developers should really listen to it, this is the way WinXP is build... But then again, we would then have to make extra code to be backwards compatible with the older windows, since they don't have the same kinds of Application Data folder...
This was not ment to be rant or anything.. Was just that coders have to think about the consequences before they act...

Why not just save settings to the HKEY_CURRENT_USER\Software\Company\Program section of the registry wouldn't that make the most sense?

quote:

---

Why not just save settings to the HKEY_CURRENT_USER\Software\Company\Program section of the registry wouldn't that make the most sense?

---

Yes... but can you save pictures and other files in the Registry...?

quote:

---

Originally posted by Matty
Why not just save settings to the HKEY_CURRENT_USER\Software\Company\Program section of the registry wouldn't that make the most sense?

---

indeed.... That is what that place is made for...

But that is for registry settings...

------------

I know what n0n4m3 means though. I too hate it when each plugin (or program for that matter) starts saving stuff in places I don't like (doesn't matter where it is, it should always be customizable!).

But CyBeRDuDe also has a point: most programs save their files in the program folder. At least, most older programs do this; newer programs also indeed tend to use Documents and Settings\<username>\Application Data\<program folder>. The thing with that is: if they do, not all are customizable, which is a bi**h.

But we are talking plugins here. Plugins aren't programs! And all plugin developpers know that all the plugins are stored in the same directory. So, IMO, no, it doesn't make sense that plugins save their data to the plugins folder (especially not when it isn't customizable); imagine that every plugin does this, you'll soon end up with a big mess in your plugins folder, not to mention possible file name conflicts...

IMO, Plugins, if they absolutely need to save a file, need to save this, by default, in a subdirectory of the plugins folder. Or in %appdir%\<program folder>. But mostly, it must be customizable by the user! This is the most logical and user friendly way to go... IMHO.

-----

PS:

quote:

---

Originally posted by (CyBeRDuDe)
But then again, we would then have to make extra code to be backwards compatible with the older windows, since they don't have the same kinds of Application Data folder...

---

No you don't, you simply need to call the appropiate Window API's. There is an "application directory" in every Windows version.

Besides, even if there were no such API's, isn't making a plugin backward compatible and compatible with all possible Windows versions (which Plus! also can run on) the right thing todo anyways?

quote:

---

Originally posted by Tobiaz

quote:

---

Why not just save settings to the HKEY_CURRENT_USER\Software\Company\Program section of the registry wouldn't that make the most sense?

---

Yes... but can you save pictures and other files in the Registry...?

---

Yes, you actually can though (to some extent). You need to store them as binary data, which is rather easy to do... But I wouldn't recommend it though as the registry is loaded entirly each time you start Windows. This also means if you store many data files and stuff like 20MB of pictures, you'll soon see that your startup time (and maybe even Windows in general) is becomming extremely slow...

quote:

---

Originally posted by (CyBeRDuDe)
It's a good idea, and suggestion.. But I doubt this will be taking as a serious note.. .. I don't think many developers wants to do this... And the easiest place to have a plugin save it's data is in the same folder as the program is installed.. That's pure sense...
IMHO (But this is probably beacuse i'm running without user accounts and the likes) I hate when other programs put loads of shit into my documents and settings, and Application Data... I just HATE it... I don't want random programs to store random things a place like that.. If I decide to install my program to my d drive because i'm in lack of harddrive space on my c drive (or any other reason), then this program is supposed to stay and only use space on my d drive... No where else... This is just my view and probably only because of the way I use my computer and orginise my shit on my hard drives...
Though, I see the problem that plugins migt not be able to write to the "Program Files" dir... Though why don't you just install messenger plus a place where the users have access to write to?... Messenger Plus have an option to change installation path... And all plugins makes sure they are installed in this path and saves their data their.. This kinda eliminates your problem...
Anyways.. Your suggestion is still good and developers should really listen to it, this is the way WinXP is build... But then again, we would then have to make extra code to be backwards compatible with the older windows, since they don't have the same kinds of Application Data folder...
This was not ment to be rant or anything.. Was just that coders have to think about the consequences before they act...

---

Yes, you made a point there. I was only thinking from the win XP point of view because this is the ways most applications should work in XP (save its data to Application data). What I thought was something like this:
- a user would change to the admin account (i think this is done by only 1% of the people that use windows because most people use an account that has administration rights, I admit that i'm also one of those that does this)
- normally people install their programs to the program's default dir in msgplus case it would be "program files\messenger plus! 3\", then they'd install plus
- plugins are normally installed to the plugin's folder inside plus directory, so this would require the plugin to be installed with admin rights.
- plugin's data would be saved to the Application Data dir without any problems.

Of course people could do what you said, install plus to an user accessible folder or just only the plugin, but this could cause problems for users sharing the same computer if only one user had access to that directory.

There's also the solution of saving the data in registry but if it's too much data, it should go into file(s).

Maybe my approach to the problem wasn't the best but developers should think of this because of people with multiple users in one computer (permission to write a file in a dir) and there are some plugins that don't allow to choose a directory when installing.

Hope it's more clear now

quote:

---

Originally posted by CookieRevised

I know what n0n4m3 means though. I too hate it when each plugin (or program for that matter) starts saving stuff in places I don't like (doesn't matter where it is, it should always be customizable!).

---

Yes... That's true... Customization is the way..

quote:

---

Originally posted by CookieRevised

But we are talking plugins here. Plugins aren't programs! And all plugin developpers know that all the plugins are stored in the same directory. So, IMO, no, it doesn't make sense that plugins save their data to the plugins folder (especially not when it isn't customizable); imagine that every plugin does this, you'll soon end up with a big mess in your plugins folder, not to mention possible file name conflicts...

IMO, Plugins, if they absolutely need to save a file, need to save this, by default, in a subdirectory of the plugins folder. Or in %appdir%\<program folder>. But mostly, it must be customizable by the user! This is the most logical and user friendly way to go... IMHO.
Subdirectories in the Plugins folder make a good alternative.. .. Infact it should really be comon sense, though I know I haven't been good at that.. But most of my plugins never really reach beyond Beta stage , and they have all the way just been experimental and in constant development.
The best alternative is to store the settings in the registry, and I like to store them in the "HKEY_CURRENT_USER\Software\Patchou\MsgPlus2\<email>\Preferences\Plugins" key. This immediatly gives an organised "save setting" place, and I think most plugin developers do this?
If files are needed to be stored,
-----

[size=1]PS:

quote:

---

Originally posted by (CyBeRDuDe)
But then again, we would then have to make extra code to be backwards compatible with the older windows, since they don't have the same kinds of Application Data folder...

---

No you don't, you simply need to call the appropiate Window API's. There is an "application directory" in every Windows version.

Besides, even if there were no such API's, isn't making a plugin backward compatible and compatible with all possible Windows versions (which Plus! also can run on) the right thing todo anyways?

---

, 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.
I myself personally don't care about compatibility with older windows, because I make these plugins for free, by own will, and by request. 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... So, I guess there is not much demand for it?... But anyways, if it was a bigger plugin, a plugin/program that cost money you would more or less expect it to run on all versions, besides that then it's only a bonus if the plugin runs on Win98....
Also all the customization programming takes time... The worst part of making a plugin is to make it highly customizable and user-friendly... The hard-coding of the plugin is rarely the hardest/most time-consuming part of the creation of a plugin...
Though I myself likes it when the users have more customization freedom, like where to save settings etc.

Tobiaz:
You suggestion is good, and I will try to remember it from now on, or at least think more about what I do with my save settings and other data savings, but as long as plugins are beta's and only being tested by the people here that are willing to test these plugin you can't expect it to save data like that and customization of all stuff, but when a program is declared as "Final Version"/Out of testing, then it's a good idea that the programmers implement such things as saving to the application data folder... .. 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... ...

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"...

what n0n4m3 has picked up on is very relevant for anyone using a public or semi public network. We've got one at uni which you have an individual logon, and as such the programs are installed with restrictions on who can edit the files (for security). This means that this idea would be a useful funtion.

Really good post Cookie..
This thread seems to be starting something, someone or all plugin developers here should really start to agree on some "standard" things.. Such as this case, we should have a sticky thread where we discuss things like this, and get other peoples views on different savings location, etc. Then we might be able to agree on some default things, and this should be posted as the top post in the Sticky Thread...
This would be a great way of starting to get all the developers to follow these guidelines...