WWW.TOTALCMD.NET is out (new site about Total Commander)

[ghisler(Author)]

I'm still updating my page within about a week when I get plugin updates for existing plugins. Of course it's better when I can link directly to the author's site, then it's clear that the author himself is responsible for the plugin.

I'm currently not accepting new pligins easily, especially when they are very new. In such cases, I ask plugin writers to annouce them in the plugins forum first, and to put them on totalcmd.net.

[Lefteous]

Sounds as if it's even easier to get an app approved by Apple

[JOUBE]

I just find it too risky (from a legal point of view) to give plugin authors direct access to my site to upload their own plugins as it is possible with sites like totalcmd.net...

Ok, understandable. Maybe you have misunderstood it: The plugin page may completely separated from the site ghisler.com, but should technicely administrated by you (to prevent/handle infections and downs) und owned by you (to prevent site is suddenly totaly removed from the web). All other things are discussible.

JOUBE

[Flint]

I updated the site scripts a little, so now there is a special field for storing link to 64-bit plugin versions. In addition, I activated a dedicated field for the forum discussion link, so authors can just fill it instead of adding link to the main description body.

[ghisler(Author)]

2Flint
Normally 32-bit and 64-bit should be in the same zip or rar, except for large plugins. Could you add a link for "combined" or so? Any better ideas?

[Flint]

ghisler(Author)
Hm… On the Russian forum there is already request to allow combining plugin with the source code in single package — some authors do so already. Too many combinations arise…

[MVV]

I think writers may just specify same link for both fields if same archive contains both versions.

Or maybe additional radio buttons (32-bit, 64-bit, both) and theese two fields, for 32-bit or both only first field is enabled, for 64-bit - only second one.

Or third solution: checkboxes near '64-bit link' and 'source code link', if checkbox is checked, main link is used.

Search field may be improved also: e.g. if I type "64: hlp", search result list contains only thoose that support 64-bit.

[tbeu]

I updated the site scripts a little, so now there is a special field for storing link to 64-bit plugin versions.

Downloading the x64 version does not increment the download counter

[MVV]

tbeu, it was done to exclude double increment if user downloads both versions. If you have both 32- and 64-bit versions in a single package, you may leave 64-bit field empty.

[tbeu]

If you have both 32- and 64-bit versions in a single package, you may leave 64-bit field empty.

I did so.

[Flint]

Normally 32-bit and 64-bit should be in the same zip or rar, except for large plugins. Could you add a link for "combined" or so? Any better ideas?

OK, now I added checkboxed so that authors could specify what they include in their packages. So now it's possible to mark the package as containing both x32 and x64 versions, and it will be shown on totalcmd.net page as "Download (x32, x64)".

[Alextp]

X32 should be called x86 (more correctly). Or "32-bit"

[Flint]

X32 should be called x86 (more correctly). Or "32-bit"

"32-bit" is longer, don't want to waste space.
"x86" sometimes leads to misunderstanding ("Did you know there are not only 64-bit systems, but also 86-bit?"). Naming architectures like "x86" and "x64" sounds to me like "one is red, another is big": first is general name derived from 8086–80486 era, while second is just "bitness". If you wish "x86" then the second should be named "x86-64", but again, it's longer, and not as widely known as "x64".

[Alextp]

Sounds correct. Ok