Isotype, a universal visual language. Looks like excellent material for simplified icons.
Isotype, a universal visual language. Looks like excellent material for simplified icons.
Since I got interested in woodworking, I have used various inadequate surfaces to work and hold the wood. A wooden saw-horse that our builders left behind, the edge of the balcony, the quasi-vertical edge of the bathtub. This is all extremely uncomfortable, and so for the past months I have been working on a real woodworker's bench.
This is the back view of the bench, with a few bar clamps and a chisel holder.
André Roubo was a French cabinetmaker from the 18th century, who wrote a massive treatise on all the then-known techniques for working wood. The woodworking community online has been abuzz with a translation of Roubo's book that is being prepared by the editors of Popular Woodworking magazine.
In his book, Roubo describes a workbench and its accessories in detail. This bench is a variation of that one.
My bench is built from a thick slab of cedar on pine legs. The thick slab makes the bench heavy and stable — it is a royal pain in the ass to use hand planes on a bench that slides around the room. The legs are joined to the surface with through-dovetails and tenons. I am not exactly sure why Roubo built dovetails and tenons like that, but it has something to do with wood movement — you want the face of the legs to remain flush with the front face of the top, so that you can have a continuous surface for clamping.
The legs have short stretchers with double-wedged tenons, and long stretchers with tusk tenons. This kind of joinery is done without glue; that way if any joint comes loose, I can just hammer it back into position.
This is how the bench top is joined to the legs.
The main function of a workbench is to hold a piece of wood steady when you are working on its faces, edges, or ends. The bench needs to let you hold things in the X/Y/Z axes so that you can work on them.
Here you can see the leg vise. You can use it to hold a board to work horizontally on its edge or vertically on its end. The leg vise is built using a commercial steel screw. The bottom rail keeps the vise vertically parallel to the leg. The holes in the rail are so that you can fit a metal peg on the outside of the leg, which acts as a fulcrum for the vise.
To hold the wood down and work on its face, you use holdfasts. A blacksmith made these for me. They have a 3/4" shaft, which you then fit through holes on the surface of the bench. To secure a holdfast, you just bang on the top of the curve with a mallet. To loosen it, you bang on the back of the curve. The holdfast gets "stuck" inside the hole where it fits, and that is what keeps it steady. The main advantage of holdfasts over clamps is that while you can only use clamps close to the edge of the bench, you can use a holdfast in any place that there is a hole.
Finally, there is a square block of wood which you can move up and down to use as a stop for planing the faces of boards. The stop keeps the wood from moving forward as you plane it. There is also a crochet, or hook, which you use to hold the end of long boards while planing their edge; the other end gets clamped in the leg vise.
People have been talking a lot about workbenches. This is the material that I used as reference:
Bob Rozaieski's epic videos on building a workbench without using a workbench, using only hand tools:
Chris Schwarz builds (yet another) workbench:
Roy Underhill makes sliding dovetails look easy:
and the Fibonacci sequence. Universal scaling. Biophilia.
2. Geometric Recursion and Fractals: the Sierpinski gasket. Perforation, bending, and folding. Anti-gravity anxiety. Architecture of the horizontal.
3. Universal distribution of sizes. Fractal design, ornament, and biophilia. Sustainable systems.
4. Cellular automata. Sierpinski carpets and sea-shells. Design in hyperspace and connection to the sacred.
5. Architectural harmony. Christopher Alexander’s theory of centers. Design as computation. Computational reducibility.
6. Alexander’s 15 Fundamental Properties. Three laws of architecture.
7. Biologically-inspired computation. Genetic algorithms. Computation versus memory retrieval. Evolutionary regression.
8. Emergent systems. Examples from Artificial Life. Inhuman experiments. Architectural education.
9. Symmetry production. Symmetry breaking. Classical moldings. Elementary particle symmetries. Binding energy.
10. Generative codes and their application to building and urban morphology. Secularization destroys public space. Spiritual architects. Legalizing codes.
11. Duany-Plater-Zyberk (DPZ) codes. The New Urbanism. Stephen Mouzon’s project. Tall buildings.
12. Implementation of generative codes in design. Urban plazas. Designing for children. Favelas and social housing.
Harmony-seeking Computations, what Christopher Alexander has been working on after the publication of The Nature of Order.
I used to have a hard time distinguishing jhbuild-controlled shells from normal shells. To help with this, I just pushed a small change to jhbuild. Now it sets an UNDER_JHBUILD environment variable, so your "jhbuild shell" can customize its prompt. You can add this to your .bashrc:
if [ -n "$UNDER_JHBUILD" ]; then PS1="[jhbuild] $PS1" fi
With this, my prompt now looks like this when I'm inside a jhbuild shell:
Visualization of the drug war in Mexico. This guy's blog is awesome, and his code is on github.
It is Hack Week this week, when all of Novell's hackers work on whatever project they want for the whole week.
The infrastructure for Document-Centric GNOME is coming along just fine. The Zeitgeist hackers are kicking all sorts of ass with the engine and the activity journal — that's what lets you see your work in a nice timeline.
Another part of the document-centric vision is to allow comfortable flow or circulation through your files, which is sorely missing right now.
Let's say you open a document. It doesn't matter how you open it — by double-clicking on it in Nautilus, by clicking on an item in your activity-journal's timeline, or by a File/Open command. The document window you get is something like this:
This document window tells you the title or filename, but it does not let you see where the document is stored. It also does not let you access documents which may be near the place where the original document is stored.
The user interface does not give you any hints about the place in which your document lives. Your document is effectively placeless, you have no way to orient yourself, and you have every reason to feel lost.
What would Christopher Alexander do?
There are several patterns in A Pattern Language that deal with how you move from place to place and how you orient yourself, either in the city or in a building. To solve the problem of disorientation and placeless documents, I think we can grab ideas from these patterns:
Main gateways. "Any part of a town - large or small - which is to be identified by its inhabitants as a precinct of some kind, will be reinforced, helped in its distinctness, marked, and made more vivid, if the paths which enter it are marked by gateways where they cross the boundary. [...] Mark every boundary in the city which has important human meaning - the boundary of a building cluster, a neighborhood, a precinct - by great gateways where the major entering paths cross the boundary."
Circulation realms. "Lay out very large buildings and collections of small buildings so that one reaches a given point inside by passing through a sequence of realms, each marked by a gateway and becoming smaller and smaller, as one passes from each one, through a gateway, to the next. Choose the realms so that each one can be easily named, so that you can tell a person where to go, simply by telling him which realms to go through."
The flow through rooms. "The movement between rooms is as important as the rooms themselves; and its arrangement has as much effect on social interaction in the rooms, as the interiors of the rooms. [...] As far as possible, avoid the use of corridors and passages. Instead, use public rooms and common rooms as rooms for movement and for gathering. To do this, place the common rooms to form a chain, or loop, so that it becomes possible to walk from room to room [...]"
Circulation for your files
File managers like Nautilus let you navigate down in the hierarchy of folders until you reach an actual document. But once you open a document window, you cannot navigate up to look for related files, or even to see the folder in which the document is stored. If you open the document with something other than the file manager, you will have a hard time knowing where the document is.
We can solve this by adding a "Show folder" button to document windows, preferably so that it is close to the document's name or filename.
When you click on that "Show folder" button, it takes you to the document's parent folder. In turn, we can make folder windows in the file manager similar, with a "Show parent" button to go further up in the hierarchy.
By adding a single button that is close to the document's or folder's name, we can let you navigate up in the hierarchy, just as you can currently navigate down with the file manager. This adds circulation and flow to your files.
Every time that I click on a PDF link while I'm browsing the web, the following happens:
The PDF gets downloaded and put somewhere. Sometimes in /tmp, sometimes in ~/Downloads, depending on which button I click in Firefox's "what do you want to do with this file?" nag-window.
Evince opens up to show me the PDF. In a few seconds I can tell if the PDF is something worth keeping.
If I decide to keep or delete the PDF, I cannot move it easily to a good place or to the trash— I have no way to visit the PDF's parent folder so that I can drag it to another place. This would be solved with the "Show folder" button described above.
For some reason, PDFs always seem to have terrible names: presentation.pdf, 2010.pdf, 10.1.1.55.8788.pdf. CiteSeer, I am looking at you. And yet there is no easy way to rename the document right there.
This also happens when someone sends me an email attachment. They give it a crappy name, I want a better one, but there's no easy way to do it right there.
In the mockup screenshots above, you can see that windows for documents and folders actually let you edit the filename right there. Instead of having a static filename in the title bar, you actually have a text entry that you can edit. If I could rename 10.1.1.55.8788.pdf right from Evince as I view the PDF for the first time, my ~/Downloads folder would be a much friendlier place.
This is akin to having physical gateways with big name tags. You always know where you are, and you always know that you can go to a place nearby.
Unfortunately, window managers don't let you customize a window's title bars like that.
The valiant Cody Russell has been working on the client-side-decorations branch of GTK+. With this, you would be able to have a toplevel window and decorate its frame yourself, without the window manager's intervention.
Having control of a window's frame means that we can stick a GtkEntry there for the rename-able filenames, and a GtkButton for the "Show folder" action.
(Yes, this would also let programmers add all sorts of crap to their windows, but apps will shitty UIs will just kill themselves.)
However, having an application paint the window's frame by itself also means that it should paint it exactly in the same way the window manager would, or the window will look out of place.
My Hack Week project is to rip the code from Metacity/Mutter that reads a window manager's theme, and paints the window frames, and make that code reusable for GTK+. This way document windows would look exactly like normal managed windows, but with the addition of the few extra controls we need.
This is the story of two little olives.
Hello, my friend, what have you been doing?
Let me tell you about my deadly battle with a fierce toothpick.
Don't you say! How impressive, what valour!
The toothpick was about this thick.
Tell me no more, I can't bear to hear it!
Now more than ever, we olives have to stand together.
No more toothpicks, only red peppers will pierce our hearts!
Script - Oralia
Puppets - Luciana
Photos - Federico
This is how a GtkBox lays out its children. Yellow is the spacing that you specify in gtk_hbox_new() or gtk_vbox_new(). Beige is padding, which I'll convince you to set to zero. Orange is the actual child widgets inside the box.
In the first example, you see a box with a spacing of 2 (trust me, that yellow is 2 units). The children are thus uniformly spaced, and everything is nice and easy to understand.
In the second example, you see a box with the same spacing of 2 units between children, but each child has a different padding. The leftmost child has a padding of 1 unit, which you see on both sides of that child. The second child has a padding of 2 units, the third child has a padding of 3 units, and the rightmost child has no padding. This is a big mess.
Spacing is the uniform space that GtkBox puts between child widgets.
Padding can be different for each child, and it gets applied on both sides of each child. So each child gets an allocation of at least (padding + requisition + padding).
Other containers like GtkTable also have their own padding parameters for children (GtkTable lets you set different paddings in the X and Y directions).
Summary: if you are using a padding different from zero, you are making a mistake in 99% of cases. Use a good spacing, and a padding of zero. Otherwise you make it really hard to align other widgets in the container hierarchy when someone else has to modify your code. If you really need padding, it's generally better to use a GtkAlignment around your widget and pad that instead of messing up the parent container.
This has been a public service announcement.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!