Imagine 0.8.4.0 - Image/Animation Lister Plugin for TC

[norfie]

[Lefteous]

2icfu

I expect plugin ini files in the corresponding plugin dir just like I expect TC ini file in the TC config dir. Why should a program store its settings in a dir of another program?

TC plugins are just DLLs which run in the same context. That means they need another program to run. This program is usually TC. It's wrong to say it's another program.

I wanna be able to copy/delete plugins and search for the correct config file without any hassle. With more than 50 plugins installed it would simply drive me crazy to keep my dirs tidy.

Please consider that I have to change the security settings for every plugins that wants to write into it's own directory. That's really not fine.

I have many plugins installed and I don't think it's a problem to find a file called imagine.ini or a Imagine section in the appropriate plugin.ini file.
But here we could get some assistance from TC. Plugin configuration could have a new "Uninstall" function. The old "remove" function should be renamed to "disable". The new one could ask the user what to do:

[face=courier]Delete plugin settings too? (yes/no)[/face]

These functions need support from the plugin (GetPluginFiles (interesting for installation too?), GetPluginSettingLocation) which informs TC which are the files to delete and where to find the plugin settings.
The only problem here is that a loaded plugin cannot be deleted if the plugin doesn't support unloading. Maybe delete them on a TC restart?
Something like that:
[face=courier]Plugin could not be unloaded. The operation will be finished on next TC startup. Restart TC now? (Yes/no)[/face]
Any ideas? What do you think of this idea?

But it's a bad idea in general to limit the plugin.ini location to the dir where wincmd.ini is located as this annoys me and other users who prefer to have all settings in one place for easier management.

I can't follow you here. If a plugin stores it's own ini file or uses the appropriate plugin.ini in the directory where wincmd.ini is located you have indeed all settings in one place from my point of view.

[norfie]

[Clo]

2norfie
Hello !
¤ The location of the <imagine.ini> file isn't the main issue currently, in my modest opinion … It doesn't pose any problem for me, since I use a general sub-dir for the plugins inside the TC-dir., like this.
-----------------------------------------------------------
>>> To all :
• Does somebody know a mean to read these damn *.Dat files in Imagine as plain text ?
All suggestions'll be welcome, thanks…

Kind regards - V G
Claude
Clo

[norfie]

[Clo]

2norfie
• Sorry, but you are getting boring; whether you'ld have read that whole thread carefully, instead to post here a n… th.. copy of "Location of ini files" like in other topics, you'ld know that there are some pretty real bugs and lacunæ in that new version of Imagine. They must be fixed up in first, I guess.
- You are no more moderator of anything than me, and I know a good place where you can put your opinion about me…
- If you decided to be on my back, you'll run up against a snag. I am NOT a doggie.

IMO your remark isn't modest but you make a fool of yourself.

- Hey ! For that kind of exercise, you are an expert !
Goodbye
Claude
Clo

[norfie]

[Clo]

2norfie LAST ANSWER

you're the man, who thought

- "German comma", illegal in English…

My capabilities of recognizing and observing are above average

- Not so high as your bloody stupidity.
-English : "Goodbye" is a definitive sentence when used "as is".

[norfie]

[icfu]

@Lefteous:

TC plugins are just DLLs which run in the same context. That means they need another program to run. This program is usually TC. It's wrong to say it's another program.

Talking about the user's view, not the developer's view, isn't that obvious? Wordsplitting is not the game I wanna play. Exchange "program" with "plugin" if you like, it doesn't matter.

Please consider that I have to change the security settings for every plugins that wants to write into it's own directory. That's really not fine.

You can install plugins in %ALLUSERSPROFILE%\appdata if all users should be able to accesss it or %appdata% when a plugin should be limited to a specific user. Anyway, if you feel the need for other directories, I have no problems with that if it's optional, I can only repeat myself.

I want to have ini files associated to the plugin which uses them, you want them in wincmd.ini folder so I have proposed to make it optional. I have no clue why justifications are necessary at all.

I have many plugins installed and I don't think it's a problem to find a file called imagine.ini or a Imagine section in the appropriate plugin.ini file.

I have told why I prefer separate directories (backup, logical point of view, etc..), I think you could respect that like I respect that you want it a different way.

What do you think of this idea?

I suggest you ask norfie, he will know better anyway and I don't waste my time anymore in dead "norfie has taken over" threads. It's too hot for these useless quarrels and I am bored, just like Clo.

I can't follow you here. If a plugin stores it's own ini file or uses the appropriate plugin.ini in the directory where wincmd.ini is located you have indeed all settings in one place from my point of view.

Same place means exactly what I have told before:
ini file in plugin dir, it should be obvious, too.

@Clo:
Good luck.

Icfu

[norfie]

[Lefteous]

2norfie

IMAGINE would support an entry in plugins-dir-located IMAGINE.INI, that would say "Take all configurations data from the wincmd.ini-dir-located IMAGINE.INI". That's a pragmatic solution.

I understand your idea this way: An Imagine.ini in Wincmd.ini always exist, but could point to another directory optionally. That means settings in two locations. That's quite confusing!
Another way could be two have a setting in the Wincmd.ini. Plugin setting location could be set here for all kind of plugins. The problem here is that you'll have to move all existing settings to the new location before changing one of these settings. Otherwise the common INI file for plugin settings will be created a second time and you'll have to merge these files manually.

2icfu

Talking about the user's view, not the developer's view, isn't that obvious? Wordsplitting is not the game I wanna play. Exchange "program" with "plugin" if you like, it doesn't matter.

I don't see a difference between developers and users view here. If plugins are different programs we could simply pass some nice parameters to the plugin to set plugin setting location. This will not work for developers and users equally.

You can install plugins in %ALLUSERSPROFILE%\appdata if all users should be able to accesss it or %appdata% when a plugin should be limited to a specific user.

We'll these directories are not thought to store files containing program instructions. In addition the plugin files would have no protection. The process of writing files to the program directory is not the users job. If he wants to activate a plugin he can choose between those provided by the Administrator and activate it.

I have no clue why justifications are necessary at all.

I'm not talking about justifications. The default should always be system default - that's all. I have mentioned some thoughts about changing the plugin setting location by user above.
The funny thing is that system default is already provided to the plugins, but some plugins authors don't care about this.

I have told why I prefer separate directories (backup, logical point of view, etc..), I think you could respect that like I respect that you want it a different way.

That's an argument to make it configurable. Good suggestions are welcome.
Currently there are many plugins into the wincmd.ini directory and some others store their settings in their own directory. That's why I'm wondering why you wrote

If it is made optional I don't care of course.

Anyway, if you feel the need for other directories, I have no problems with that if it's optional, I can only repeat myself.

You cannot be happy with the current situation (it's pure chaos) too, right?

[norfie]

[Lefteous]

2norfie

an imagine.ini exists in plugin-dir always. But only for compatibility reasons, because Imagine is looking for Imagine.ini in plugin-dir today.

Imagine is compatible to it's current version? Did I get you right? What is the meaning of this?

[norfie]