Any news? Any upcoming version?

[tukanos]

Do not be pathetic! After one year (!!!) of waiting we have still no new release. Probably the developers can postpone the new release to next year (2017?), because there are still many bugs.

You can say what you want about me, I don't care. I'm not in any way associated with Altap.

In the end you have three options:
1) Encourage developers to use different development model like night builds, specs, coverage, etc. - with arguments (not yet heard a single one). You can even help the developers with the faster development if you want.
2) Accept the development model (release when all the reported bugs are fixed) as it is - with which you have apparent issue.
3) You can use different product if you are not satisfied with the development/release cycle.

As you noticed, just complaining will get you to nowhere here. Of course, there will be many other bugs in 3.07 after release, but those will not be reported ones. I think it is always better to wait and have all the reported bugs fixed than release it just for having a release. Release just for sake of a release is total nonsense.

[rollhigh]

I hate to ask it but do we have a new precise ETA for the next version with Unicode Support?

[odinuv]

I hate to ask it but do we have a new precise ETA for the next version with Unicode Support?

I think the work on Unicode support hasn't even started yet

[rollhigh]

Dead project or is there news??

[camper]

1) Encourage developers to use different development model like night builds, specs, coverage, etc. - with arguments (not yet heard a single one). You can even help the developers with the faster development if you want.

I would prefer this option. That way Altap would have alpha/beta-testers and Altap would recognize how important it is for their customers.

I also could imagine further options:
- let users spend money for certain features they like to get (crowd-funding)
- open source AS

Using a different file manager is currently no option for me. Altap Salamander is still too far ahead of the competition - I've tried a lot in the last months. The only which comes close is Double Commander, but it has other (severe) problems.

[Petr Solin]

We are working on it but it is not in state for testing yet, sorry. We will release version in EAP when we get to the point when it can be published.

Unicode and long paths (32k) bring more complications than we expected, e.g. support for bi-directional texts, but it seems we can get through it. We expect we have work at least for next three months now. Please return in February and check state of this project if you are still interested. Thanks!

[camper]

I reckon you can skip the bi-directional text at first. The most users will have LTR languages.

[Petr Solin]

Yes, we expect users to have LTR (left-to-right) languages and we will not support RTL (right-to-left) languages in user-interface. But we are working on support for RTL and bi-directional filenames and paths.

[camper]

Just curious: what is the difference between LTR and RTL for file names? Is it about the input fields in the GUI that need support for that or really the file name? I can't imagine how this influences anything under the hood because IMHO it would just be a plain string.

[Petr Solin]

Yes, it's easy to display one RTL file name, e.g. מזל or טוב. But try to display path which contains these two names: c:\מזל\טוב. Maybe you cannot see what's wrong. First name is displayed on right side, then backslash, and then second name on left side, but in our LTR system it is wrong. It should be: c:\טוב\מזל. Another problem is shortening of these names when column width is narrow to display whole name, ellipsis (...) should be on the left side instead of right side for RTL name. Shortening of path is more complicated. And these things are even harder for bi-directional texts, changing of text direction can be nested several times.

[camper]

I think, this RTL stuff over-complicates the matter for 99% of the users. Maybe I'm wrong, I don't know your actual sales - I'm just judging from our own software. Or do you intent to expand to the RTL markets massively?

[Petr Solin]

We want to support as much of Unicode as possible. I think we will make it.

[tukanos]

1) Encourage developers to use different development model like night builds, specs, coverage, etc. - with arguments (not yet heard a single one). You can even help the developers with the faster development if you want.

I would prefer this option. That way Altap would have alpha/beta-testers and Altap would recognize how important it is for their customers.

I also could imagine further options:
- let users spend money for certain features they like to get (crowd-funding)
- open source AS

Using a different file manager is currently no option for me. Altap Salamander is still too far ahead of the competition - I've tried a lot in the last months. The only which comes close is Double Commander, but it has other (severe) problems.

I would prefer this option. That way Altap would have alpha/beta-testers and Altap would recognize how important it is for their customers.

Well who would not? Everything named costs money - on servers, maintenance. You need infrastructure for the servers and also people for the maintenance and improvements. Who would cover such costs?

- let users spend money for certain features they like to get (crowd-funding)

I'm not sure if that would be the proper way to develop a product or you will find enough people to "buy a feature". I don't know what are the sales and structure, so that is on the developer's decision.

- open source AS

Not possible because the developers would lost their income. Maybe different licensing model is an option, like Total Commander has, being shareware.

[maroon]

If the RTL character is going to be supported, most users of LTR languages would prefer a default setting to not enable this RTL character, as it's useless to them and could be harmfull. If there's a filename like:

Normal_Filenam $+ $chr(8238) $+ fdp.exe

A font like Consolas that doesn't enable the RTL character makes the filename look like

Normal_Filenamfdp.exe

But in a font like Segoe UI Symbol, it looks like

Normal_Filenamexe.pdf

So if someone had compiled the EXE with the PDF icon, it can be easy to accidentally launch an .exe

[Petr Solin]

Great! Thank you for this dangerous file name sample. I have created it on my disk and Explorer shows it as .pdf and starts it as .exe. We may add some detection for such tricky names and show some warning to user before opening such file. But I don't think it is a good idea to not support RTL names in general.

Dangerous sample name in unicode: Normal_Filenam‮fdp.exe