After saying I'd do it for quite a while, I finally made some progress in my promise to write some E-related RSS stuff for Boris Faure, aka 'billiob': eRSSd is in git now, and it's moderately tested and (should be) fully functional.
Methodology
Originally, Boris was working on a standalone app called ERSS on github. I chipped in a tiny bit to improve his Azy usage, since it's the easiest way to get and parse RSS feeds, but then, as E developers tend to do, I drifted away from the project and absolutely did not forget about it.
Over the time that I wasn't working on it, I wrote a ton of other projects and contributed to even more. Along the way, I realized that what would be great for RSS was if we had an underlying daemon which could then be accessed by all the apps and widgets, and which could run in a distributed fashion by synchronizing with other daemons over a network.
Implementation
The hardest part of any project, aside from naming it, is starting the work. Aside from working out a number of kinks in Azy related to HTTP/1.1 chunked encoding, the whole thing was written in a weekend. During this process, I spent some time learning the ins and outs of the new dbus integration library, edbus2. It's certainly an improvement over the original, which was basically just libdbus, but it still feels pretty rough around the edges; iterators in particular are not great to work with.
Anyway, the basics of eRSSd:
Adding feeds
* Add a feed from cmdline of daemon or over dbus (or remote api once I iron it out)
* Feed is fetched and cached using eet
* Feed and items become available for use over dbus (and remote API)
Using feeds
* Feed is fetched on interval based on various http/rss attributes which indicate optimal cache length
* dbus signals sent to indicate freshness and new items
* Clients use eet to directly read cache file using local client API wrapper to avoid sending tons of data over socket
* Clients send signals back to daemon to mark items/feeds as read
Deleting feeds
* Client calls dbus delete method on daemon with URL for feed
* Daemon deletes feed, removes cache
* Signals sent over dbus (and remote) to indicate deletion of feed so UIs can be updated
A utility library for clients is provided, allowing developers to avoid having to write any eet/edbus2 code themselves and focus entirely on presentation/usage. At present, only a dummy configuration UI exists, but plans are in motion to create some cool stuff in the near future. RSS is a useful and common enough tool that we should spend some effort integrating it more!
Monday, April 1, 2013
Sunday, August 26, 2012
bits and pieces
finally getting back to some theme stuff; gotta get darkness e/elm into shape before The Big Release (TBR). new hoversel theme:
needs a little tweaking so the edge image doesn't overflow the hover, but I'll tackle that another day when I care more
needs a little tweaking so the edge image doesn't overflow the hover, but I'll tackle that another day when I care more
Monday, July 16, 2012
New Footrest
So I got a mail at work earlier today stating that I had received a package. It was so incredible that I thought I would share: behold, my new footrest!
Friday, July 6, 2012
Physics
As some people may have noticed, there's a new module that hit SVN recently: Physics.
Using the new ephysics library which has been written by ProFUSION workers, this module attempts, and sometimes succeeds, at applying basic physics effects to windows on the desktop.
There were a number of hurdles to making this work at all. To begin with, E17 is very particular about where windows are placed. The callback chain for simply dragging a window around is fairly extensive, and it would have been impossible to successfully add physics in. To get around that, I was forced to add a hook on literally the line prior to a window's position being updated; this callback allows a user to receive and, optionally, adjust the coordinates.
On top of this, the version of ephysics which I based the first version of the module on did not allow easy changing of velocity, so the only possibility was to add "impulses", as they are called in Physics Library World. These set initial velocities which decay over time based on friction and collisions, and are much less precise -- obviously quite a problem when working with something that we want to be precise such as moving windows around the desktop. As a result, the current physics movement is inconsistent and feels a bit clunky; I only had one chance to apply the impulse to a window, and adjusting it was impossible due to another bug:
"Boundaries" in Physics Library World are objects which exist at the edges of the world (screen) which should prevent any other object from getting past them; instead, an object will bounce off it. Unfortunately, when applying impulses repeatedly to an object it will tend to accelerate uncontrollably and rocket past these boundaries into offscreen territory, leading to lots of lost windows. I learned to enjoy the "Cleanup Windows" functionality during tests here. Eventually I decided that the best way to prevent this was to try to be less precise -- only setting the window in motion at one point based on a configurable number of drag frames.
I quickly encountered another fun feature: while windows would no longer reach escape velocity, they would actually get stuck in the screen boundaries and be immovable. More workarounds were added here to disable all physics if a window somehow moved into a screen's boundary area, and now a user can freely move them in such cases.
There's a lot of work to be done on this module, and a lot of possibilities for it, some of which I've listed in a TODO file in the module's directory on svn. Graphical effects are doable, and probably worthwhile, but the biggest thing at first is obviously going to be improving the accuracy and "feel" of the physics. Right now it's barely even a toy, but I want to be able to play Jenga with my windows!
To conclude, don't expect to get any work done running this module. Keybind moves won't trigger physics, but having your entire desktop bouncing around probably won't increase productivity by much.
PS. check out my other blog
Using the new ephysics library which has been written by ProFUSION workers, this module attempts, and sometimes succeeds, at applying basic physics effects to windows on the desktop.
There were a number of hurdles to making this work at all. To begin with, E17 is very particular about where windows are placed. The callback chain for simply dragging a window around is fairly extensive, and it would have been impossible to successfully add physics in. To get around that, I was forced to add a hook on literally the line prior to a window's position being updated; this callback allows a user to receive and, optionally, adjust the coordinates.
On top of this, the version of ephysics which I based the first version of the module on did not allow easy changing of velocity, so the only possibility was to add "impulses", as they are called in Physics Library World. These set initial velocities which decay over time based on friction and collisions, and are much less precise -- obviously quite a problem when working with something that we want to be precise such as moving windows around the desktop. As a result, the current physics movement is inconsistent and feels a bit clunky; I only had one chance to apply the impulse to a window, and adjusting it was impossible due to another bug:
"Boundaries" in Physics Library World are objects which exist at the edges of the world (screen) which should prevent any other object from getting past them; instead, an object will bounce off it. Unfortunately, when applying impulses repeatedly to an object it will tend to accelerate uncontrollably and rocket past these boundaries into offscreen territory, leading to lots of lost windows. I learned to enjoy the "Cleanup Windows" functionality during tests here. Eventually I decided that the best way to prevent this was to try to be less precise -- only setting the window in motion at one point based on a configurable number of drag frames.
I quickly encountered another fun feature: while windows would no longer reach escape velocity, they would actually get stuck in the screen boundaries and be immovable. More workarounds were added here to disable all physics if a window somehow moved into a screen's boundary area, and now a user can freely move them in such cases.
There's a lot of work to be done on this module, and a lot of possibilities for it, some of which I've listed in a TODO file in the module's directory on svn. Graphical effects are doable, and probably worthwhile, but the biggest thing at first is obviously going to be improving the accuracy and "feel" of the physics. Right now it's barely even a toy, but I want to be able to play Jenga with my windows!
To conclude, don't expect to get any work done running this module. Keybind moves won't trigger physics, but having your entire desktop bouncing around probably won't increase productivity by much.
PS. check out my other blog
Sunday, December 4, 2011
Sunday, September 11, 2011
Projects. Lots.
Over the past couple weeks I finished projects. Eeze mounting. Pulseaudio integration. Other things that I don't remember doing.
One thing that I did, mainly over the last couple days, is get some time to work on everyone's favorite XMPP client. Add/remove contacts is implemented, status icons are in, there's toolbars, and everything just looks much nicer overall. Also I finally fixed the big shutdown crash (fingers crossed).
One thing that I did, mainly over the last couple days, is get some time to work on everyone's favorite XMPP client. Add/remove contacts is implemented, status icons are in, there's toolbars, and everything just looks much nicer overall. Also I finally fixed the big shutdown crash (fingers crossed).
Friday, August 26, 2011
Quick Update
I keep putting off the giant advanced Azy tutorial entry that I've been writing off and on for the past few months, mainly because I hate how code looks on a blog. It'll be up sometime, but probably not today. Or tomorrow.
Shotgun has gotten a lot of updates and features over the past few weeks. Crashes only occur "sometimes" now, and copying links is possible with right clicking. There's probably other things of import, but it seems to be fairly usable overall. I know there are people out there who have already switched from Pidgin, which is pretty neat for a small hobby project. With some luck, I will get more time to continue work on it soon.
Esskyuehl now compiles with recent versions of MySQL. Hooray!
I have spent the past week working on small bits and tests related to eeze mounting in EFM. All in all, I would say that I have accomplished a net of zero improvements. The main issue is the whackamole-like style of the bugs and my own inability to reproduce them regularly. Frequently, mounts will occur with no issues. Other times nothing will happen. Sometimes I get a crash. I'm getting closer, but the project is very demoralizing since there are no milestones.
Pulseaudio integration is still untouched since my last headaches in July. Once I sit down with it and take some painkillers I can probably bang it out in a few more days of awfulness, though no doubt Lennart has left me plenty more "features" which will hamstring my efforts.
Another project that I will probably use as a "relaxing" item is libarchive integration of lrzip. I have been reviewing the required API, and it seems fairly sane - what a delightful surprise! The downside is that I will likely use the command version of the API instead of directly integrating using liblrzip, meaning that my work there will continue to be unused. The upside is that libarchive will be able to build lrzip support without needing to check for a valid lrzip installation.
In closing, fuck everything about cnp in ELM.
Shotgun has gotten a lot of updates and features over the past few weeks. Crashes only occur "sometimes" now, and copying links is possible with right clicking. There's probably other things of import, but it seems to be fairly usable overall. I know there are people out there who have already switched from Pidgin, which is pretty neat for a small hobby project. With some luck, I will get more time to continue work on it soon.
Esskyuehl now compiles with recent versions of MySQL. Hooray!
I have spent the past week working on small bits and tests related to eeze mounting in EFM. All in all, I would say that I have accomplished a net of zero improvements. The main issue is the whackamole-like style of the bugs and my own inability to reproduce them regularly. Frequently, mounts will occur with no issues. Other times nothing will happen. Sometimes I get a crash. I'm getting closer, but the project is very demoralizing since there are no milestones.
Pulseaudio integration is still untouched since my last headaches in July. Once I sit down with it and take some painkillers I can probably bang it out in a few more days of awfulness, though no doubt Lennart has left me plenty more "features" which will hamstring my efforts.
Another project that I will probably use as a "relaxing" item is libarchive integration of lrzip. I have been reviewing the required API, and it seems fairly sane - what a delightful surprise! The downside is that I will likely use the command version of the API instead of directly integrating using liblrzip, meaning that my work there will continue to be unused. The upside is that libarchive will be able to build lrzip support without needing to check for a valid lrzip installation.
In closing, fuck everything about cnp in ELM.
Subscribe to:
Posts (Atom)