GNOME Bugzilla – Bug 658636
Treemap should be squarified
Last modified: 2021-05-26 09:26:27 UTC
Created attachment 196067 [details] Konqueror's File Size View vs. Baobab The current Baobab treemap display uses the slice-and-dice algorithm, which leads to very narrow rectangles. The squarified treemap algorithm (http://scholar.google.com/scholar?cluster=16156845309181182620&hl=en&as_sdt=0,34) is much better at creating layouts with aspect ratios close to 1, which are easier to interpret and use space more efficiently. Squarified layouts pretty popular in many other disk space analysis tools: * http://upload.wikimedia.org/wikipedia/en/e/ee/Spacemonger.gif * http://upload.wikimedia.org/wikipedia/commons/7/7d/TreeSize_TreeMap.png * http://www.spacegremlinapp.com/ * http://imageshack.us/f/440/appsinkonquerorpf1.png/ The attached screenshot shows Konqueror's File Size View plugin and Baobab displaying the gnome-utils-3.0.0 source tree. Though both charts take up the same area, Konquerer's squarified layout fits more information in because the rectangles aren't forced to be skinny. Baobab should adopt the squarified algorithm for its treemap chart. I am willing to contribute code to make this happen.
Thank you, you are more than welcome!
I had a closer look at the Baobab source, and it looks like this is going to take a fair amount of changes to the structure of the code. The main issue is that in a squarified treemap, a child item cannot compute its geometry merely knowing its relative position and size within the parent. Instead, the parent must walk through all of its children and arrange them using the squarified layout algorithm. This requires BaobabChartItem to maintain pointers to its adjacent sibling and to its first child, so that it is possible to traverse the tree. One may also have to change the way calculate_item_geometry is called, but I don't know for sure yet. I can make these changes, but it will take a while as I don't have a lot of free time. :) But I wanted to make sure that as the maintainer you would be okay with these changes. I haven't contributed to open source projects before and I don't really know what the protocol is. P.S. If I have questions about the existing code, should I ask here or should I email you? Or is there some mailing list I ought to join?
Sure, take the time you need, we are frozen for the 3.2 release now, so you have about 6 months before 3.4 :-) Since the changes are not trivial my suggestion would be to take advantage of git distributed nature and create a "fork" on github or gitourius and make your changes there and then point us to the branch so that we can merge it when it is ready. Asking question here is fine, otherwise you can also join irc.gnome.org where you can me with the nickname "pbor" on varius channels (e.g. #gnome-hackers)
*** Bug 650210 has been marked as a duplicate of this bug. ***
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Baobab, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/baobab/-/issues/ Thank you for your understanding and your help.