masneyb / gftp

gFTP is a free multithreaded file transfer client for *NIX based machines. 56 language translations available.
http://www.gftp.org
MIT License
116 stars 21 forks source link

Help/About Dialog - Cleanup and Improvements, misc others #165

Closed sedwards closed 1 year ago

sedwards commented 1 year ago
sedwards commented 1 year ago

This one was a real pain in the ****, way more work than I expected...like how hard should it be to read in a file with a bunch of text like the AUTHORS file and render it?

Apparently it should be very hard...

wdlkmpx commented 1 year ago

Doesn't compile on linux i686 (and probably all cpu architectures other than x86_64), the code is not portable ld: i386:x86-64 architecture of input file 'authors.o' is incompatible with i386 output

Some projects create a custom dialog window with a GtkTextView, read the installed AUTHORS file and store it in a char* variable, then print it in the GtkTextView

It's also possible to use that char* variable in GtkAboutDialog.. convert '\n' to '\0' and create a char array with pointers to each line, the last pointer(s) must be NULL, this new char array is used as the authors property

sedwards commented 1 year ago

Good point, I didn't think about other CPUs/arch. Freaking Gnu Autoconf and make is so bloody painful and cryptic. I'll work up a portable solution for that.

The reason I didn't try to read in the authors file using like an include was because I was worried about problems parsing various people's names with Unicode chars and that causing problems, by reading the whole thing in as a binary and then converting it as needed, my hope was to actually make it simpler but I still ended up having to do all this damn text manipulation anyway.

I tried to use the gchar* variable/pointer combination and convert to gchar** as you were saying and kept getting segmentation faults, which was another reason why I wanted to read the binary data right in and then break it in to array members without trying to do as much text parsing.

I started actually going down the route of trying to do a memcpy and memmove directly and then doing the conversion to switch the \n to \0 but ran in to some issue with that.

I will rework the object-copy to be more portable and try to simplify the logic doing a straight binary conversion and if you think it's still too messy and convoluted, I'll see if I can dig up a simpler solution someone else has already implemented.

sedwards commented 1 year ago

I have greatly simplified the string handling, the number of passes and consolidated everything in to one function. We also don't need the end of the binary block created by obj-copy just the start of the pointer to that FILE stream.

Let me know if you like this a bit better. I will dig in to the obj-copy autoconf/makefile issues now.

sedwards commented 1 year ago

Portability fixes