Merge liblarch into gtg

[diegogangl]

Having the code split in two gets old really fast. AFAIK nobody else is using liblarch, so no it won't cause any problems to others. We only need the treemodel though, since we are dropping treeviews.

[nekohayo]

Got an idea during my sleep... would it change anything if you had it in the same folder as a git submodule, or this is not about files but about having two repos?

From a purely theoretical standpoint (I don't really have a stake in this), I'm not sure if it's best to de-librarize liblarch; you say it had no adoption outside of GTG, yet liblarch was initiated in 2011 and up to 2013, just before GTG's big "development hell" refactoring of 2013-2015. It appears to me that it didn't really get a chance to live out there in the wild to get recognition for potential adoption by others. Maybe I'm just being too optimistic about that library potentially interesting others, and maybe it's just a pain to package (?) vs integrating it into GTG itself?

@ploum probably would have a much better-educated opinion than me on that one ;)

[ploum]

Let's put some historical context: 1. I started to write the whole gtktreeview from scratch until I realised that it was not always easy to figure out which tasks were displayed. 2. I had the idea to put an abstraction layer between the data-model and the view. That abstraction was called "filteredtree". 3. As more and more usecases appeared, filtered tree became a huge beast with a lot of bug. Solving a bug was creating 10 more. 4. I decided to abstract the whole thing into a library in order to separate those bugs from bugs in GTG itself. 5. As a library, liblarch has one major advantage: I could write unit tests. Liblarch was, at some point, nearly fully test covered. So, from a GTG development, perspective, I think that it was a very good decision and still is. Reintegrating liblarch into GTG means trading simpler packaging for a hell worse development platform. In the long term, the only sane way to get rid of liblarch would be, IMHO, to change the backend from XML to Sqlite an have everything handled as SQL queries. This *may* work but I'm not sure (I always loathed SQL). My recommendation for now: don't touch that. Make a release of GTG and liblarch separetely (not sur a liblarch release is necessary). There's a reason why we did it and undoing it will not get GTG out of dev hell.

[diegogangl]

Got an idea during my sleep... would it change anything if you had it in the same folder as a git submodule, or this is not about files but about having two repos?

Good idea! My initial "first step" was copying liblarch files inside the gtg repo, but a submodule would be much better.

In the long term, the only sane way to get rid of liblarch would be, IMHO, to change the backend from XML to Sqlite an have everything handled as SQL queries. This may work but I'm not sure (I always loathed SQL).

I don't understand why a backend change would help us remove liblarch. I can't see any XML writing or reading there, it's only the treemodel and treeview stuff. We need to use a treemodel either way, and do all the filtering/searching inside it. Whether we use XML or SQL we have to load all data into a treemodel at the beginning, and then write it back.

Having liblarch in the main repo isn't so much about packaging (flatpak takes care of that nicely), it's easier to work with and debug. It's also easier for new contributors.

In any case, this is only a first step while we migrate to listboxes and figure out exactly what we need.

5. As a library, liblarch has one major advantage: I could write unit tests. Liblarch was, at some point, nearly fully test covered.

Why wasn't it possible to write unit tests while it was part of gtg?

[ploum]

1. The idea with SQL is that you may not need to load the whole tree in memory and do every action with SQL queries. It might be fast enough. So it could, theoritically, remove the need for liblarch. But it takes someone really motivated and with lot of SQL experience to make that experiment. 2. Yep, we could have written unit tests inside GTG but making liblarch a separated library allowed us to be very strict: no gross hack. We should define a clear API and use that API. We don't have the choice to workaround the API (which is what we always ended doing before liblarch).

…

On ven, 24 avr, 2020 at 19:10, Diego Gangl ***@***.***> wrote: > Got an idea during my sleep... would it change anything if you had > it in the same folder as a git submodule, or this is not about files > but about having two repos? > Good idea! My initial "first step" was copying liblarch files inside the gtg repo, but a submodule would be much better. > In the long term, the only sane way to get rid of liblarch would be, > IMHO, to change the backend from XML to Sqlite an have everything > handled as SQL queries. This /may/ work but I'm not sure (I always > loathed SQL). > I don't understand why a backend change would help us remove liblarch. I can't see any XML writing or reading there, it's only the treemodel and treeview stuff. We need to use a treemodel either way, and do all the filtering/searching inside it. Whether we use XML or SQL we have to load all data into a treemodel at the beginning, and then write it back. Having liblarch in the main repo isn't so much about packaging (flatpak takes care of that nicely), it's easier to work with and debug. It's also easier for new contributors. In any case, this is only a first step while we migrate to listboxes and figure out exactly what we need. > As a library, liblarch has one major advantage: I could write unit > tests. Liblarch was, at some point, nearly fully test covered. Why wasn't it possible to write unit tests while it was part of gtg? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#286 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJNCA3SHK3RVU4IDSG4F4LROJBAVANCNFSM4MGGC67Q>.

[diegogangl]

Closing this for now, I will open a new issue with a broader scope for the next release cycle.

[nekohayo]

My memory and knowledge is fuzzy regarding the current situation, but it is my impression that the big GTK4 + core rewrite of the last few years towards 0.7 has essentially gotten rid of liblarch, am I right?

Now I'm seeing @SqAtx essentially proposing to remove the liblarch code (again!) in #1145.

Reopening so that the historical context and comments above are on their radar.

[SqAtx]

Yeah I couldn't find where it was used, and my understanding was that the functionality was replaced in the GTK4 port. I've been meaning to double-check that PR, rebase it and open it for review, but I just haven't taken the time.

[diegogangl]

Yeah, liblarch usage is gone in the GTK4 port. I probably didn't remove the dependency though