05-29-2024, 01:36 AM
(This post was last modified: 05-29-2024, 01:44 AM by Rev.
Edit Reason: More info
)
(05-29-2024, 12:37 AM)grindstone Wrote: It was just my first thought in case you didn't and were still faced with too many characters.
Well, the problem is the parsing itself, not the actual storing of the data, most ini parsers will just segfault when it reaches that long line. So I just decided to have my own parser and just skip the [Desktop] section for now and retrieve the path via extraction of the other sections, since every path has its own section, basically, I'm just bypassing the issue altogether.
However, I did end up creating a second way of dealing with it, where I created another ini parser that just dynamically allocates the line length and stores all the files' key-value pairs in a hashmap, but I was not happy about storing the Directories list value in the hashmap since you would still need to parse that data also.
I might end up redoing the implementation in the future, but now that it is working and has a "good enough" implementation I'm not going to worry about it.
There are far more important features that need to be done, and right now, I'm currently changing the data structure for the Desktop entries from a dynamic array to a Binary Search Tree (BST), which will allow me to still sort the entries while not allowing for duplicates like Okular which have like eight different Desktop entries with the same name.
Anyways, here is a good resource that I used to help get me started. https://specifications.freedesktop.org/i...atest.html
It explains quite a lot and provided me with some pseudo-code which was pretty nice.