Important announcements and news about Odilia’s development will be published here.
Important announcements and news about Odilia’s development will be published here.
ever since the first release, things appeared to be quite stagnant, especially from the outside. This is not an imagination of the public, this is actually true, things were quite stagnant for a while, mostly because a lot of the team was busy with real life situations. However, it appears that we have a bit more time now, so what better way to communicate this than sharing the fun with everyone, as well as, of course, the latest feature we were working on?
Notifications are the unsung heroes of a seamless desktop experience across Linux, Windows, macOS, or even smartphones. We need to stay informed about events happening around us, and traditionally, this is achieved through small pop-ups, help balloons (as Windows 7 and earlier versions called them), or tooltips that appear on the edge of our screen, alerting us to events, even when the originating application isn’t in focus. -However, there’s a catch:
I don’t know about other operating systems, but linux doesn’t offer an accessibility focused API to get most system related events, and this includes notifications. Given this, and considering the critical nature of this feature, we’re left with no choice but to…
In response to the absence of an accessibility dedicated API for system information in the freedesktop stack, various hacks have emerged over time. Our approach, while different in execution, isn’t too far off.
In the following, we will describe the hack used by orca, since this is the only one known to do this, along with the reason we didn’t do it this way. Afterwards, we will document, briefly, our own hack and why we chose this method instead
Warning: This section is quite technical. If you’re not technically inclined, feel free to skip to the limitations section
the approach of orca is as simple as it is effective:
Most notification daemons, at least back in the day this hack was made, created a new window, with the role of alert whenever a new notification appeared. So then, that’s exactly what orca does to read them. It monitors the accessibility bus for a window appeared event, it extracts the window title, and then it realises/dereferences the sender to see if it’s an accessible application, and if so, if the root has the role alert. If all of those are true, the notification text is either in the window title, or in a text element which is typically the first such element in the hierarchy of accessibles from that root. The others may or may not be action buttons and other things, but that’s not important to orca, so that stuff is ignored.
there are afew problems with this design though, and that’s why we were not going to use it:
there’s another reason for which we’re not using this method, and it has nothing to do with limitations or design defficiencies in the previously outlined algorythm.
because odilia is a very young project, and furthermore is actively under development, well, more like on and off but still, we don’t currently have the mechanisms required to handle that event, filter based on it, extract information from it, etc. We do for focus and others, but because we don’t for this one, we felt it would be too much work across a longer time frame for not enough benefit currently.
our hack relies on the freedesktop notifications specification to be relevant and implemented by notification daemons, and is unfortunately not as simple as the one implemented by orca, but we believe it could be a bit more resiliant to change in presentation, because of the protocol itself if nothing else. It goes as follows:
this approach has afew advantages compared to the previous one:
there are, however, disadvantages with this one as well, but for the time being, we believe them to not be big enough when ballanced with not having the feature at all:
currently, we can’t reliably extract the source of the notification, because most apps we tryed this with sent an empty response for that part. So, for now, odilia only says new notification, in stead of saying from which app that notification came.
We do intend to fix this in the future, if a reliable method to find that information will be discovered, we hope this will not remain broken forever. If anyone knows anything, feel free to contact us.
you just clone the repository, then run it:
| |
if you’re running from a release, why would you be doing that anyway, since this is such an alpha software? you just pull main again, install and run the new version:
| |
for more information, refere to the installation guide
it has certainly been a very fun couple of days, or maybe weeks at this point, polishing everything and making sure it’s as good as possible in these conditions. Making this feature a reality took about two pull requests, if not three, working on different parts of the stack, to make sure tests correctly pass, no false negatives prevent us from merging, and actual bugs are caught instead. Hell, we did hit a very interesting exception case, which could make odilia hang on exit, and despite our efforts, may still make it do so.
many things were learned as well, especially about some previously unknown dbus mechanisms, the freedesktop notifications specification, github workflow quirks, believe it or not but x11 virtual framebuffers, and we might be missing something, but it was certainly very much fun.
Now, it’s your turn to have fun! Run the new build, test it some more, lament at how weird everything is, but most important, we would be thrilled if you would talk to us about it!
as always, you are a big reason for which we keep developing odilia. Stay safe, and don’t forget, you are a big force in helping us revolutionise the linux desktop, one step at a time!