I have created an issue on github to work on the Trash bug (which I have confirmed). Please follow up at:
With regards to the second issue, please follow up here:
Another thought- Maybe can move the mail to the actual Trash like any other Trash move? That action post a pop up window when moved anyway so you wouldn’t need the notifications at all.
Don’t know if I follow this… When you delete an email in EmailViews, the email file is in fact moved to the system Trash (Tracker /boot/trash folder). The system Trash and EmailViews Trash view should always be in synch. If they aren’t, it’s a bug; in that case, please describe the steps to reproduce.
If you referring to the ‘Delete emails in Trash’ from the contextual menu in EmailViews’ Trash view, this deletes all email files in the system Trash permanently, which is why a warning dialog is displayed. I think that is necessary.
Maybe hard to describe.. When I delete a file from the desktop, with a right click→”Move To Trash” a BAlert (quickly) pops up indicating the move. When I delete a file from EmailViews, that BAlert doesn’t pop up so I assume your code is different. Thats what I was referring to.
But Great Work! Thank you for your contribution and glad I can help in any way.
A number of changes have been made to BColumnListView since beta5 that improve performance and also add batch loading operations. Maybe that suffices for what you need?
When I delete a file from the desktop, with a right click→”Move To Trash” a BAlert (quickly) pops up indicating the move. When I delete a file from EmailViews, that BAlert doesn’t pop up so I assume your code is different. Thats what I was referring to.
I wasn’t aware that a BAlert popup is displayed when moving a file to Trash in Tracker. I will check this, and if that’s the case, I will try to follow the same behavior pattern inside EmailViews. Let me look into it.
To be honest, I did not do any profiling with the Santa’s code, as it was visibily very fast. I am not sure what the difference is, but it may be that Haiku’s BColumnListView AddRow triggers per-item overhead? Just guessing.
The BColumnListView is performing some operations on each AddRow(..) such as scrollbar recalibration and area invalidation. If I’m adding 9-10k rows or so and each row has some bespoke field classes such as PackageIconAndTitleField with layout logic then the time-cost to repeatedly recalibrate the scrollbar and area invalidation can add up to be quite a significant delay.
The AddRows(..) reduces that delay by adding lots of rows and then doing the scrollbar recalibration and area invalidation once.
I can’t see how the latter could be slower . Are you able to point me at a branch-diff somewhere to see what the difference between the two approaches looks like in your source code?
The changes with AddRows(..) was made in 5b41bc0066ef4f5bfb85ae05259e7ef2a63862f6 which was on 2025-09-04 (NZ).
TBH; I think what might be nicer in these situations with larger data sets is a view that is a simple table with fixed row height that is able to render data from a “data supplier”. Rather than the Window / controller loading all the data into rows into the BColumnListView, the table would ask the “data supplier” how many rows and then request data on-demand. Putting such a thing into place would take quite a bit of work unfortunately.
With regards to your suggestion, I wonder if that would work with dynamic query views (which is at the heart of EmailViews). That’s way over my head, anyway.
Debugger uses something like this already called TreeTable. However under the hood I think it just loads all rows from the model and inserts them into a BColumnListView. (I also don’t know if the API design is good or not; I haven’t really evaluated its TreeTableModel class in detail.) Eventually we should rewrite BColumnListView to be properly model-based internally, indeed…
Is there a consensus here on the legality of using Santa’s Gift Bag for this project? I see no reason it can’t be used. The license agreement essentially says ‘use it freely, but if you make alot of money from it, send me something..’. This is not a ‘commercial’ project, correct?
If this is the only issue holding back the source code, can we come to an agreement so ilfelice can open the source?
For the future of this software, it might be preferable to use Haiku lib which will continue to be maintained instead. I think it is worthy to spend a bit a time studying if performances can be improved to do so.
If not, the problem will be to document what was modified as requested by the license. Before doing that, you want to fix bugs. Otherwise, you may have to do it again later.
I’ve realized that I made a mistake by releasing a binary without also providing the source code. That’s on me. To correct this, I’ve taken the binary down until I’m able to release the sources. My apologies for the oversight.
A few clarifications:
EmailViews is free software and is intended to be open source (preferably under the MIT license).
I did not use the original Santa’s Bag code directly. Instead, I used Beam’s implementation as a starting point and adapted it to EmailViews’ needs. I already have the blessing of Beam’s author (Oliver Tappe, aka zooey).
My intention is to comply with the Santa’s Bag license in the same way Beam does, by preserving the embedded original source’s license.
I am making a good-faith effort to contact the author of the original Santa’s Bag, but haven’t succeeded yet. If anyone knows how to reach him, please feel free to DM me.
In the meantime, if anyone would like to test the app, just contact me here via DM.
Again, apologies for the inconvenience. I’m new to this and still learning as I go.
Hello! You don’t need to apology Is your work, and you are free to choose how and when is shared. And again, the choose to release or not the sources is totally up to you. Your hard work, your rules, always
. Are you able to point me at a branch-diff somewhere to see what the difference between the two approaches looks like in your source code?
Is your work, and you are free to choose how and when is shared. And again, the choose to release or not the sources is totally up to you. Your hard work, your rules, always 