Links to this post

You can use this BBCode to create a quick link to this post. Such links are created from yourforum URL and will stay valid in case your forum should move to a different URL at a later time.Hit Ctrl+C to copy the BBCode to the clipboard.

Re: For how long you stopped developing TabSRMM 3? |

Remember, this is a volunteer open source project. Right now, enough time is not available.

Folders support works as it should. No need for changes and relative paths are working fine as long as you install everything properly. Support for "weird" installation methods will not be provided. Just install the skins where they are supposed to be installed (in your profile) and you won't run into troubles. You won't even have to use folders.

__Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.My SMF-based forum fork

Re: For how long you stopped developing TabSRMM 3? |

And on what basis have you decided that the normal path to the skin is necessarily in the profile folder?

On common sense. That's why Miranda has profiles, profile folders and things like %miranda_userdata%. Anyone who understands this concept won't run into troubles.

Userdata belongs to %APPDATA$, nowhere else and this well known concept of a user "home directory" for separating user data from applications has been working on other operating systems for like 40 years and nobody ever complained. The fact that Windows allowed you to put user data just everywhere was a design problem in Windows and MS has realized this way too late. And this is why so many users have problems with UAC, folder permissions and try to fix it by running applications with administrator privileges.

We still have mirandaboot.ini and this is enough customization because it allows you to put the profile in the program folder. This makes sense for portable installs, but anything more just means asking for troubles.

As for skins - TabSRMM 3 will not allow you to open skins from locations outside its profile folders. It will behave like other plugins (e.g.popup+ or some tipper modifications) and only allow skins from a specific location. This feature is not yet implemented, but will be and it will solve all problems with relative pathnames. Also, skins will be identified by their names, not their filename locations.

__Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.My SMF-based forum fork

Re: For how long you stopped developing TabSRMM 3? |

By your logic, plugins should be placed in profile folder too. Skins are used by all users, they are common, like plugins, sounds and icons. They are not overwritten and there is no problem with UAC.

You don't seem to understand. Or maybe you don't want to. No need to further discuss, sorry.

Hint: Plugins are NOT user data.

Hint #2. It is not MY logic, it is common sense and a concept which is more than 40 years old and proven to work in millions of situations. But maybe YOU know better than all those developers.

And then tell me why most (if not all) modern applications like Opera, Firefox, Thunderbird, Chrome and many more put skins in the user profile under %APPDATA%? Because they are ALL doing it wrong, by your logic?

__Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.My SMF-based forum fork

Re: For how long you stopped developing TabSRMM 3? |

You probably didn't know that Firefox stores in profile folder not only skins, but the extensions too (which are essentially plug-ins). Thus each user have his own skins and extensions. And Chrome altogether totally lives in %APPDATA% (and each user must setup it again). That's why I mentioned about your logic, but so far it only works apart from all other modules and Miranda itself. Is it well or not, a moot point. Not only I believe that the skins can be stored in a Miranda folder, it's more convenient to users and there is no need to create duplicates of skins for users. But you are depriving the right to choose. Miranda was famous because it allows user to decide and adjust preference as necessary. You violate this idea. By the way, for some reason icons are still stored in the Icons folder in the root of Miranda, why?

Re: For how long you stopped developing TabSRMM 3? |

You probably didn't know that Firefox stores in profile folder not only skins, but the extensions too (which are essentially plug-ins). Thus each user have his own skins and extensions.

I know a lot about Firefox (in fact, I've contributed to its code, years ago), and I think that, ideally, Miranda should do the same. Only default plugins should be in the program folder and there should be a plugin folder in the profile. I believe that this idea should and will be implemented at some time in the core. It would be a requirement if Miranda will ever get a automatic plugin installer/updater and it would easily allow a "safe mode" where Miranda would only load standard plugins in case of troubles (e.g. crashes on startup).

Plugins in the profile folder would then have the ability to "override" standard plugins, so TabSRMM would be installed in the profile and automatically override srmm and chat (technically, this is already possible, because we have Interface GUIDs) and if you deactivate it in the plugin option screen, Miranda would automatically revert to srmm. This is still something that doesn't work in current Miranda and one of the reasons is that we mix standard and 3rd party plugins in the same folder.

Quote

Not only I believe that the skins can be stored in a Miranda folder, it's more convenient to users and

Skins = user data, therefore they should not be stored in the application folder. The only skin which would have a right to exist in the application folder would be a default skin (one that comes with the plugin and is installed when you install the plugin - like Opera, for example, which installs its mandatory default skin in the application folder, but ANY other skin is installed to the profile). But this is only because Opera *needs* a skin to work, Miranda and TabSRMM don't require a skin, they are totally optional.

And more convenient? That's a joke, right? If you think, it is in any way convenient when you need administrator privileges to install a user skin, then you are really wrong. No well-written app that I'am aware of needs admin rights for installing a skin.

Quote

But you are depriving the right to choose. Miranda was famous because it allows user to decide and adjust preference as necessary. You violate this idea.

I violate nothing. I only clean up the mess it once was and I tend to write software which sticks to common standards. And rightfully so, because if you would care to read the forums, you would know that there are TONS of problems with plugins that do NOT follow the rules (mostly old and unmaintained plugins which never had to deal with limited user rights).

Miranda is famous because it allows you to customize all important aspects. The location of files is NOT an important aspect, in fact, it's totally irrelevant where files are stored and the user shouldn't care. Miranda is flexible enough to give you all the control you need, you can use folders plugin, you can use mirandaboot.ini to relocate your profile. I'am only talking about the defaults, not the options you have with additional plugins or customization methods.

Quote

By the way, for some reason icons are still stored in the Icons folder in the root of Miranda, why?

Which icons? The icon.DLLs? They are part of the plugin(s). They are not to be modified and are installed together with the plugin. See above, if TabSRMM would have a default skin, it would be installed in the program folder. But there is no default skin, all skins are optional and must be installed by the user. That's why the profile folder is the ONLY correct location to do so.

__Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.My SMF-based forum fork

Re: For how long you stopped developing TabSRMM 3? |

You don't include one, you don't give users have common skins (which administrator considered necessary to provide by default).In case if user wanted to use personal skin, he will is as it should add it to profile folder.And about the icons, you probably have forgotten that there still exist icons protocols? (Status, XStatus/Mood, Connection)

Re: For how long you stopped developing TabSRMM 3? |

Sorry, there was a misunderstanding about skins because of a translator's (human's) mistake. And my English not everywhere is good. Alright, the points is to keep Folders support.

Ok, no problem then.

I was just not understanding your point. In fact, the changes I have commited to the skin selection code are not dramatic. You can still have skins in your own custom folder, but you must use the folders plugin for this feature. I don't see a problem here, because the folders plugin is a requirement anyway when you want to customize your profile folders and most advanced users will most likely already use this plugin.

The new system enforces a more strict directory layout (e.g. one skin per folder) and users can no longer directly select skins by using a file selection dialog. This was bad, because it could cause problems with relative pathnames. Now it is easier to use, because the drop down list will show you all available and properly installed skins by name - no more need to navigate to the skin folder using the file selection dialog. The skin loading dialog will also display the current skin root folder so users should instantly know to which folder they have to copy their skins.

__Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.My SMF-based forum fork

Re: For how long you stopped developing TabSRMM 3? |

All true (Everything is as you said).But, with the latest updates from trunk, skins are not applied. They are visible in the list and can be selected, but nothing happens when you click "Apply skin now" and nothing written in the database. This is how it should be now? Also, maybe it might be better to remove buttons "Apply skin now" and "Unload skin"? They're no longer needed, since the list already have item "<no skin>" and the applying must already be on system buttons OK and Apply.

Re: For how long you stopped developing TabSRMM 3? |

All true (Everything is as you said).But, with the latest updates from trunk, skins are not applied. They are visible in the list and can be selected, but nothing happens when you click "Apply skin now" and nothing written in the database. This is how it should be now?

No, that's of course not how it should be.

Is the database value Tab_SRMsg/ContainerSkin updated when you select an entry from the list (it should contain the relative path name for the selected skin - relative to the skins root folder)?

Quote

Also, maybe it might be better to remove buttons "Apply skin now" and "Unload skin"? They're no longer needed, since the list already have item "<no skin>" and the applying must already be on system buttons OK and

Yes, that's the next step. Unload skin will go away, because selecting <no skin> in the list should be enough, no explicit unloading necessary. Apply skin will be converted to a Reload button, so that skin developers can easily force a skin reload.

__Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.My SMF-based forum fork

Re: For how long you stopped developing TabSRMM 3? |

1. It only written to the database from the third item in the list (second skin). First skin is not written to the database (although with it somehow offered to close the container);2. Despite the fact that the second skin is written to the database, it is still not working.3. And it does not work because of the Name parameter in the section [Global], which was recently announced by you, if it is deleted, skins are applied properly.

Re: For how long you stopped developing TabSRMM 3? |

3. And it does not work because of the Name parameter in the section [Global], which was recently announced by you, if it is deleted, skins are applied properly.

That's strange. Looks like the Name= confuses the skin loader, but I have no idea, how and why.

Can you zip up your skins root folder and send it by email (see my signature for the address, same as the Jabber ID).

__Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.My SMF-based forum fork

Re: For how long you stopped developing TabSRMM 3? |

But item 1 is still relevant, first skin in the list is not loading at all.

Yes, already found that. Silly index mistake (using 1 instead of 0 for the <no skin> entry, so the first "real" skin (which has the index value 1) cannot load at all.

__Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.My SMF-based forum fork