Open dchapiesky opened 4 years ago
Hi dchapiesky!
Yes, I agree that the current lack of version numbering and shared library support prevent Turbo Vision from being distributed and used like anyone would expect.
One of the reasons for that not having been done yet is the lack of time. I should be working on my Bachelor's thesis right now instead.
A second one is that I envisage ABI-breaking changes happening before Turbo Vision can be considered stable. Most notably, 24-bit color support. If users were to depend on dynamic libraries by the time that feature lands, I would have to be very careful about shared library numbering. So I get the impression that by offering these features I would have to spend a lot more time on the project that I would like to.
But when it comes to differentiating this Turbo Vision from the others, I don't think the project's name is an issue. The currently most popular port, by Salvador E. Tropea, does not conflict in binary names or include directories (librhtvision.so
, include/rhtvision
). The only widespread port which sticks to the name tvision
is the one by Sergio Sigala, but nobody uses it anymore. Additionally, both mine and Sigala's ports are mostly compatible at the source code level.
I don't think a change of name is necessary for this project to stand out above the others. For example, there is currently just one video on YouTube with Turbo Vision as the main topic. It wouldn't be too difficult to exploit that platform, as well as other ones, in order to attract new users to this repository and gather attention.
Additionally, by preserving the original name, I can just tell people to read books written in the 90's instead of providing a proper documentation :) .
Still, renaming the project is not a bad idea, as it prevents any further conflicts and makes things clearer. But it definitely won't be TVision2020, as it would become outdated in just three months :) . I'm not a big fan of using year numbers in project names. Another easy name would be tvision++
, but I don't think it's a good choice either, as users would feel betrayed after they realize that Turbo Vision uses 0% of the STL but 100% of raw pointers and C casts. Another one would be tvision2
, but it reminds me of the case of dosemu2
and its lead developer regretting the decision.
Ah... the hardships of being a project maintainer... lol
I am going to probably add shared lib support soon for my project.... so if it is OK with you, I will occasionally throw another CMakeLists.txt at you to integrate as you see fit... again.. well done on the project and good luck with school.
Thank you. Contributions are always welcome.
A version number would be great - something that differentiates your working version from some of the other tvisions out there...
Might even be worth renaming to something like TVision2020
Shared lib compile?