Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Basics... #16

Open
dchapiesky opened this issue Sep 29, 2020 · 3 comments
Open

Basics... #16

dchapiesky opened this issue Sep 29, 2020 · 3 comments

Comments

@dchapiesky
Copy link
Contributor

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?

@magiblot
Copy link
Owner

magiblot commented Sep 29, 2020

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.

@dchapiesky
Copy link
Contributor Author

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.

@magiblot
Copy link
Owner

Thank you. Contributions are always welcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants