Hi Nate and others, let me fill in some minor notes from my side,
Am Fri, 14 Oct 2022 13:14:11 -0500 schrieb Nate Bargmann <n...@n0nb.us>: .... snip .... > > Having dabbled with porting a GTK program from GTK 2 to GTK 3 I have > come to appreciate that GUI toolkits are not not for the faint of > heart. Similar experience here. > So, for a general cross-platform GUI > toolkit there are really just two choices that I am aware of, Qt and > Fltk. Both are C++ libraries so writing code in C is pretty much out > of the question (perhaps I am wrong here) and so coding must happen > in C++. Is it possible for a mortal hobbyist programmer to work in > C++ effectively? With its templates and other additions to its more > recent standards, I decided that my time was better spent in code > much more simple. For the point of using FLTK or Qt for GUI that is doable. There are ways to mix C++ and C code. .... snip .... > > The code in TLF is difficult to understand and follow in part because > of NCurses calls scattered throughout the code. Historically TLF has > not been implemented in an MVC design, as I understand MVC which may > be wrong. True. We have invested quite some time to untangle the tight web and I think it got better in last time. But sure, there is still quite some work to do. > Most programmer hams have probably taken a look at the TLF > code base and been scarred for life! No, it's not that bad but it is > typical of hobbyist projects where the primary object is writing code > and adding features. From a technical point of view there is not only the Ncurses TUI which makes the code difficult to handle. Further points are: - Internal information was (and still is) stored in a lot of global variables which are accessed from everywhere without no encapsulation. As the historical naming of some of them is not really intuitive it takes some time to got an understanding what a variable is used for and where it is used (and changed). - Quite a lot of information was handled as strings and gets converted back and forth. As C is no good in safe string handling that was a source of a lot of run time errors ( It even led to the point that Tlf could no longer be build in around 2008 because of buffer overruns everywhere). While the problems are not solved completely there was a lot of work in the last years to add data structures, pass data by parameter to and from functions and to move away from and/or to safer string handling. So TLF has a much more manageable code base now compared to some years ago. But let us not forget - part of the complexity comes also from the broad range of functionality TLF has to handle. > While I have contributed to TLF I am just a > small contributor compared to Tom, Zoli, and others who understand it > much better than me. And thanks again for all that contributions. 73, de Tom -- "Do what is needful!" Ursula LeGuin: Earthsea --
