Whiskey is now on launchpad, in 2 places since I can't figure out how to link habanero (trash80's and my project name) to my personal account. https://code.launchpad.net/~compgrokker/+junk/whiskey and https://code.launchpad.net/~habanero/+junk/whiskey.
Update on the gui: since pyglet will never upgrade to python 3.0, I'm using pyjamas. PIL hasn't upgraded yet either, but it's tempting to grab the bits I need (a small subset of the whole module), fork it, and upgrade it. I haven't decided on that yet, but for right now whiskey still depends on python2.6 (arch's stable python, and the highest version I know of that PIL will work with), although I'm writing my code to be upwards compatible with 3.0.
Although whiskey is up on launchpad, it doesn't have a PPA yet simply because it's not particularly useful yet. Hence why it's still in experimental. Arch has the debian buildtools though, so once whiskey is close to what I'm aiming for (or at least close enough that I feel comfortable opening it up to a wider audience), look for a PPA.
Showing posts with label python. Show all posts
Showing posts with label python. Show all posts
1.02.2011
12.29.2010
whiskey db backend
After playing around with it and reading the specs, yaml is not the right tool for the job. It's too hard to have multiple attributes for the same key (ie, colours: grey, blue, green) and even harder to parse that back out and search it. Some sort of nosql db seems to be what I'm looking for, and mongodb seems to be the friendlier of the python-supported nosql dbs out there. So... scratch the yaml stuff (until it comes time for config files, that's still a good idea), mongodb is going to be the db backend. And I should have some working, prealpha code going up on launchpad soon. No promises though, my work hours have expanded (yay money, boo exhaustion) so it's tough to get anything done but work, chugging coffee, and sleeping. But I'm trying. :)
9.26.2010
Whiskey
Now I'm working on a desktop-agnostic wallpaper manager. I jokingly called it 'whiskey' one night in a chat, and the name kinda stuck. Anyhoo, it walks through the user's home directory, looking for jpegs, gifs, pngs, and xcfs, looks at the size to determine if it's a wallpaper by its size (4:3 and 16:9 sizes are supported), and if it's not a standard size, it asks the user if they want it added to the database. The database is written in YAML. What will be stored in the database is the filename (full path), format, size, aspect ratio, colours, and design details. The colours and design details will be user-supplied. The gui will be done with pyglet. The image processing library I'm using to parse the metadata and will be displaying the preview in the gui is PIL (Python Image Library). Though, PIL's docs say the function to display the image is really inefficient, so if it turns out to suck too badly, I'll find something else to handle that.
I'm thinking to handle tiling, I'll grab the screen resolution (somehow) and use PIL to paste the image over and over into a bigger image the size of the screen, then save it as something like "foo.tiled.png" or so.
I'm still not sure exactly how I'm going to actually set the wallpaper, whether I'll shell out to fbsetbg/esetbg/etc., or write my own routine to handle it.
The way to look through the wallpapers is a slideshow. There'll be a 'set' button, and a delete button that'll trigger a menu to either simply delete the file from the database, or from the system.
So far that's all I have planned out. Which I suppose kinda makes sense, since all I have coded so far is the function to walk down the home directory, and the function to read the metadata prior to writing it to the database. And I have a sketch of the UI (not my work, my fiance is my design person).
I'm thinking to handle tiling, I'll grab the screen resolution (somehow) and use PIL to paste the image over and over into a bigger image the size of the screen, then save it as something like "foo.tiled.png" or so.
I'm still not sure exactly how I'm going to actually set the wallpaper, whether I'll shell out to fbsetbg/esetbg/etc., or write my own routine to handle it.
The way to look through the wallpapers is a slideshow. There'll be a 'set' button, and a delete button that'll trigger a menu to either simply delete the file from the database, or from the system.
So far that's all I have planned out. Which I suppose kinda makes sense, since all I have coded so far is the function to walk down the home directory, and the function to read the metadata prior to writing it to the database. And I have a sketch of the UI (not my work, my fiance is my design person).
7.30.2010
Manifesto Time
OK, I'm bored with the kernel thing right now, and we need something to install before I really get into it. So I'll be moving on to hacking pacman to use a git repository and rewriting package dependencies. But right now it's time to clear my head, step back, and look at the bigger picture-- so on to the promised jet-fu manifesto.
The over-all aim of jet-fu is to be a small server. This means:
> Only dependencies for packages will be the bare minimum to run the package.
- trash80 described it better than I ever could in his first post, but basically just because a package *could* need something to enhance its features, doesn't mean it should automatically be installed. If the server admin wants it, (s)he can grab it themselves. Optional dependencies will be listed in at least one place for reference so they can be installed as well if the admin so desires. I like that pacman already simply lists optional dependencies on install, I wouldn't change that feature, others may disagree though. If mainstream pacman changes this behaviour, we may fork. Another possible place to list dependencies would be a wiki or something.
> Small, customized kernel from the moment of install.
- Rather than having to roll your own kernel to clear up all the cruft and extra drivers a distro kernel installs (and which the kernel trudges through on boot each time to see which ones need to be loaded), the installer will only put in the base kernel and the drivers needed to run the exact hardware/software that's configured at the moment. Additional modules will be available online (on the package server?), and can be downloaded on-the-fly when they need to be loaded, and then become persistent in the system.
> No gui, because servers don't need guis.
- Sounds simple enough. No X or anything like that available, just command-line access or a web interface. Something along the lines of webmin, but better. Since this is already geared towards LAMP servers, all the tools are there and running, just log into the admin interface and do what you need to do.
Obviously, right now we're basing the distro on arch, to some degree. They have the most featureful package manager that still runs on a distro that's close to what we want to achieve. I realize the apt suite and *rpm* are at least as featureful as pacman, but debian has gotten bloated over the years, and rpm-based distros have always tended to be bloated.
Some ideas we're playing around with that may or may not make it to release are: git repo server, ditching HAL (since it seems only certain gui apps like thunar use it now) and writing our own udev. Again, these are subject to change. I may also have forgotten some things, so there may be a manifesto part 2 in the future.
One last thing, all tools we write will be in python. We're going with python 2.6 as our standard version, with our code geared to 3.0, then upgrading to 3.0 when it becomes more mainstream.
The over-all aim of jet-fu is to be a small server. This means:
> Only dependencies for packages will be the bare minimum to run the package.
- trash80 described it better than I ever could in his first post, but basically just because a package *could* need something to enhance its features, doesn't mean it should automatically be installed. If the server admin wants it, (s)he can grab it themselves. Optional dependencies will be listed in at least one place for reference so they can be installed as well if the admin so desires. I like that pacman already simply lists optional dependencies on install, I wouldn't change that feature, others may disagree though. If mainstream pacman changes this behaviour, we may fork. Another possible place to list dependencies would be a wiki or something.
> Small, customized kernel from the moment of install.
- Rather than having to roll your own kernel to clear up all the cruft and extra drivers a distro kernel installs (and which the kernel trudges through on boot each time to see which ones need to be loaded), the installer will only put in the base kernel and the drivers needed to run the exact hardware/software that's configured at the moment. Additional modules will be available online (on the package server?), and can be downloaded on-the-fly when they need to be loaded, and then become persistent in the system.
> No gui, because servers don't need guis.
- Sounds simple enough. No X or anything like that available, just command-line access or a web interface. Something along the lines of webmin, but better. Since this is already geared towards LAMP servers, all the tools are there and running, just log into the admin interface and do what you need to do.
Obviously, right now we're basing the distro on arch, to some degree. They have the most featureful package manager that still runs on a distro that's close to what we want to achieve. I realize the apt suite and *rpm* are at least as featureful as pacman, but debian has gotten bloated over the years, and rpm-based distros have always tended to be bloated.
Some ideas we're playing around with that may or may not make it to release are: git repo server, ditching HAL (since it seems only certain gui apps like thunar use it now) and writing our own udev. Again, these are subject to change. I may also have forgotten some things, so there may be a manifesto part 2 in the future.
One last thing, all tools we write will be in python. We're going with python 2.6 as our standard version, with our code geared to 3.0, then upgrading to 3.0 when it becomes more mainstream.
Subscribe to:
Posts (Atom)