search

rusio / VokabelTrainer

A small command-line vocable trainer that uses the Leitner box system.
https://en.wikipedia.org/wiki/Leitner_system
MIT License
1 stars 0 forks source link

Contact address in Readme #3

Open ghost opened 7 years ago

ghost commented 7 years ago

I tried to send you an email and got this error:

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of
its recipients. This is a permanent error. The following address(es)
failed:

dolvich@users.sourceforge.net:
SMTP error from remote server for RCPT TO command, host: mx.sourceforge.net (216.34.181.68) reason: 550 unknown user

I guess your email is out of date. If you update it, I'll try resending the email.

rusio commented 7 years ago

Hi ber532k,

this project originates a long time ago on SourceForge, where we used Email way to communicate ideas. But on GitHub there is this Issues space, which might even be better than Email. Feel free to open an Issue and discuss.

Btw, thanks for the pull requests. Are you using the program yourself? I am thinking to port the whole thing to Kotlin and add a graphical user interface.

Regards

ghost commented 7 years ago

Hi,

I usually loose motivation way too fast when studying vocabulary; but I am currently setting it up for personal use anyway. I really like doing stuff from the terminal so I can use some great tools like tmux, mosh and vim with everything I do. That's also one of the major reasons I wanted to have a vocabulary training tool I could use from the terminal and it made me choose VokabelTrainer over some similar gui-based programs from kde (e. g. parley).

I really didn't look too deep into the kde stuff, but I guess their programs are doing something quite similar, so given the competition I'm not sure how much this project would benefit from a gui. What I really liked about it apart from the fact that it is command-line-based was that it is slim, kiss and has an easily readable file format for storing data. Since kde uses a shared file format for data between multiple of their vocabulary training programs, maybe creating some kind of converter might also be an alternative to creating your own user interface. One could then export to or import from their software - and maybe even use their file format natively with VokabelTrainer.

I don't think I'll find the time to dig into the code myself currently, so I guess I'll just be using what I have right now for a while. Btw: I created an AUR-Package for Arch Linux, which you can find as vokabeltrainer-git. I didn't include any licensing information since I couldn't find any on the github page. I believe I read something about GPLv2 on the old sourceforge page a bit later, but didn't act on that yet. If you want me to include some licence in the aur package just drop me a message or upload it to the github page - or both ;)

Anyway if I should find time to look into the code some time I would probably port it to python, since that's the language I'm currently trying to learn and I don't really know anything about groovy or kotlin. Also, what I would probably do first are some (ideally backwards-compatible) modifications to the way data is stored like adding support for directory structures and maybe look into the workings of ncurses in order to make the interface a little less noisy. If you are interested I could create a feature request and elaborate a little more on my ideas, but I can also understand if that's too much trouble given the size and age of your code.

Thanks for the program btw ;) Regards

rusio commented 7 years ago

Wow, such a valuable feedback!

In fact I was thinking about a graphical UI in order to reduce room for error, because I observed my daughter using the program, and she is just starting with Linux, the terminal and the text editor. I had some worries, that such an inexperienced user might somehow mess up the text file, which would lead to loss of valuable data, which has been entered over months. But for users like you (and me) the terminal and the text editor is just fine.

Given these two very different persona, I think of two options for future work:

These would require a bit of refactoring, but it would be a joy to me, because I would love to apply the Clean Architecture model, which enables completely different user interfaces for the same application logic.

Also thank you for the AUR package, I am using Antergos at work and I will check it out :-)

Regarding the programming language, I am versed in Python and it is a possible option. Also since Python is practically built-in in every Linux Distro, no additional dependencies would be needed on Linux. But honestly, I am sick of dynamic typing and I am also exited about the rise of the Kotlin programming language. Just like Groovy, it requires a Java Virtual Machine to run, but is freaking awesome for development.

If you are interested I could create a feature request and elaborate a little more on my ideas, but I can also understand if that's too much trouble given the size and age of your code.

Feel free to share your ideas. The code size and age is less of a problem, but it might take some time, for free time is currently very limited. But this program is definitely something I would like to improve over time.

Best regards from Germany, Rusi

ghost commented 7 years ago

Sry for taking so long with my reply - seems like I really need to have a word with gmx's automated mail filtering preferences some time ...

What you're suggesting about having two different interfaces sounds great to me. (Why not even three - retaining the current one for fallback could hardly be difficult since it's quite basic and it shouldn't have any significant impact on code size or complexity either.)

About the choice of language: I myself am a student in humanities and writing (really basic) scripts is more of a hobby, so if you want to actually rewrite the program yourself don't rely on my preferences too much. I guess any modern Linux Distro should be able to handle either and neither is the performance of small programs an issue with today's computers. In case you end up choosing kotlin I could still happily help out with testing and feedback.

I'll create another issue about my ideas on data storage shortly.

Regards