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.
Saturday, August 13, 2011
liblrzip is go
Another day, another project done. Liblrzip is the latest, a full API for the excellent LRZIP for which I wrote a build system way back in March. Straight to the code, here's a VERY simple example of a decompression app using the library:
#include
#include
#include
#include
#include
static const char *suffix_me(const char *file)
{
const char *p;
static char buf[4096];
p = strrchr(file, '.');
if (p && (strlen(p + 1) < 4))
strncat(buf, file, p - file);
else
strcat(buf, file);
return &buf[0];
}
int main(int argc, char *argv[])
{
Lrzip *lr;
if ((argc != 2) && (argc != 3)) {
fprintf(stderr, "Usage: %s file [outfile]\n", argv[0]);
exit(1);
}
lr = lrzip_new(LRZIP_MODE_DECOMPRESS);
assert(lr);
lrzip_config_env(lr);
assert(lrzip_filename_add(lr, argv[1]));
if (argc == 2)
lrzip_outfilename_set(lr, suffix_me(argv[1]));
else
lrzip_outfilename_set(lr, argv[2]);
assert(lrzip_run(lr));
return 0;
}
Yes, I am too lazy to figure out the CSS to preserve whitespaces for indentation.
#include
#include
#include
#include
#include
static const char *suffix_me(const char *file)
{
const char *p;
static char buf[4096];
p = strrchr(file, '.');
if (p && (strlen(p + 1) < 4))
strncat(buf, file, p - file);
else
strcat(buf, file);
return &buf[0];
}
int main(int argc, char *argv[])
{
Lrzip *lr;
if ((argc != 2) && (argc != 3)) {
fprintf(stderr, "Usage: %s file [outfile]\n", argv[0]);
exit(1);
}
lr = lrzip_new(LRZIP_MODE_DECOMPRESS);
assert(lr);
lrzip_config_env(lr);
assert(lrzip_filename_add(lr, argv[1]));
if (argc == 2)
lrzip_outfilename_set(lr, suffix_me(argv[1]));
else
lrzip_outfilename_set(lr, argv[2]);
assert(lrzip_run(lr));
return 0;
}
Yes, I am too lazy to figure out the CSS to preserve whitespaces for indentation.
Monday, August 1, 2011
XMPP: The infinite messaging protocol
It has been a while since my last post, and I have been extremely busy. There are no shortage of projects to waste time on, and today I'll be talking about one of them. Since a screenshot is best, let's start off with one:
This is a chat client that has been co-developed by Iván Briano (Sachiel) and me over the past month or so. It is still in the very early stages of work in terms of its UI, but it is very usable.
Above you can see a screenshot of the client's contact list window and an empty chat window. The open menu is an early implementation of the status menu, and it allows the user to set the status of the account. The other component of the status menu is the status entry, which allows the user to set status messages; it can be seen at the bottom of the contacts list window.
This is another feature in development which uses a very unfinished Elementary widget called "gengrid." This widget allows a developer to autogenerate a grid view of objects. This view is toggled from a menu, and can be switched to at any time. As I mentioned, this widget is not very polished, and so it does not look as good as the list view :)
Here we see a shot of the chat window, where I am in a deep conversation with Leif Middelshulte (T_UNIX). Since XMPP allows its clients to connect multiple "resources" (devices) to the same account, this client allows for users to determine exactly which resource, or all of them, will receive messages. By default, it will abide by the priority value set by other users' clients, but if I click on this radio button in the menu, Leif will suddenly be receiving a lot of SMS on his phone!
One of the biggest strengths of the EFL is its integration with media. This next shot showcases what is, IMO, the best feature that this client offers:
Any time an image is linked in conversation, its URL is automatically parsed. This URL is then downloaded and cached to be made available as a tooltip on mouseover of the address, as seen above. Any images downloaded using this mechanism are automatically saved to disk using their SHA1 hash, preventing them from being downloaded again in the future and saving bandwidth. We hope to provide similar effects for other types of media as well!
One might ask what libraries I have used to power this client. The following is a list of all components involved:
Non-EFL technologies
The insanely fast PugiXML parser. I use this in all of my projects involving XML because of its amazing speed, concise API, and very friendly+helpful author :)
LibB64. If it uses base64 encoding, you'd better be using this or you're just wasting memory and CPU cycles.
EFL
ECORE: The networking API here makes connecting to XMPP servers a snap, and it also handles the STARTTLS mechanism of the protocol with ease.
Elementary: The EFL widget toolkit. Despite being under heavy development and containing lots of potentially unwanted "features," ELM still packs a punch and gives the developer a lot of freedom and control over how an app looks, feels, and acts.
This client is not yet available in the public E svn repository, but it is LGPL licensed and will be moved there once it is ready for public use. Keep your eyes peeled!
This is a chat client that has been co-developed by Iván Briano (Sachiel) and me over the past month or so. It is still in the very early stages of work in terms of its UI, but it is very usable.
Above you can see a screenshot of the client's contact list window and an empty chat window. The open menu is an early implementation of the status menu, and it allows the user to set the status of the account. The other component of the status menu is the status entry, which allows the user to set status messages; it can be seen at the bottom of the contacts list window.
This is another feature in development which uses a very unfinished Elementary widget called "gengrid." This widget allows a developer to autogenerate a grid view of objects. This view is toggled from a menu, and can be switched to at any time. As I mentioned, this widget is not very polished, and so it does not look as good as the list view :)
Here we see a shot of the chat window, where I am in a deep conversation with Leif Middelshulte (T_UNIX). Since XMPP allows its clients to connect multiple "resources" (devices) to the same account, this client allows for users to determine exactly which resource, or all of them, will receive messages. By default, it will abide by the priority value set by other users' clients, but if I click on this radio button in the menu, Leif will suddenly be receiving a lot of SMS on his phone!
One of the biggest strengths of the EFL is its integration with media. This next shot showcases what is, IMO, the best feature that this client offers:
Any time an image is linked in conversation, its URL is automatically parsed. This URL is then downloaded and cached to be made available as a tooltip on mouseover of the address, as seen above. Any images downloaded using this mechanism are automatically saved to disk using their SHA1 hash, preventing them from being downloaded again in the future and saving bandwidth. We hope to provide similar effects for other types of media as well!
One might ask what libraries I have used to power this client. The following is a list of all components involved:
Non-EFL technologies
EFL
This client is not yet available in the public E svn repository, but it is LGPL licensed and will be moved there once it is ready for public use. Keep your eyes peeled!
Subscribe to:
Posts (Atom)