How a window manager with tiling layouts makes a 1024x600 resolution livable.
I spend a lot of time in front of a screen, and for the past year I have
used only my netbook. No desktops, no laptops. Just a cheap $200 computer
that is nearly a kid's toy. The most challenging thing about this is
dealing with the 1024x600 screen resolution. When I moved to this screen
from something with many more pixels, it at first seemed very cramped.
After a year, I think that the most important part of coping with the small
screen is the flexability and customizability of layouts provided by the
Xmonad window manager. In this post I will explain a few layouts I have
developed for fitting specific tasks onto the netbook screen.
(I assume that you know maybe 0.1% of Haskell (about what I do),
and can read Haskell code without having a brain aneurysm.)
web browsing
It's important that the web browser have as few toolbars and other
cruft as possible, as horizontal space is especially at a premium. I've
configured both Epiphany and Firefox to put everything in one tool bar.
But now I use Chromium, which comes pre-configured that way.
What the netbook is designed for. You just want a web browser, taking up
the full screen, and with its own tabs. So far, so easy: that's Xmonad's
Full layout.
But, you sometimes want to see two websites side-by-side. This layout
accomplishes that, allowing the sizes to be adjusted as needed. It also
uses Xmonad's
Magnifier to zoom the smaller window when it's focused,
which is useful if you briefly need to see more of a web site.
mySplit = magnifiercz' 1.4 $ Tall nmaster delta ratio
where
-- The default number of windows in the master pane
nmaster = 1
-- Percent of screen to increment by when resizing panes
delta = 3/100
-- Default proportion of screen occupied by master pane
ratio = 60/100
web development
If you're doing web development, you'll want probably one big web browser
window, but also with a nice wide terminal on the same screen, in order to
see web server logs. A simple way to do this is to mirror Xmonad's
Tall
layout by 90 degrees.
myWide = Mirror $ Tall nmaster delta ratio
where
-- The default number of windows in the master pane
nmaster = 1
-- Percent of screen to increment by when resizing panes
delta = 3/100
-- Default proportion of screen occupied by master pane
ratio = 80/100
The
myWide layout uses the full screen width for a single terminal,
and splits the width when there are more. This is sufficient for viewing logs
and doing minor things at the shell prompt, in between testing the result in
the web browser. Of course a terminal can be temporarily moved to the master
area by pressing
mod-return, if you need it to be larger.
chat
Tips on configuring Pidgin for a netbook: Set it up to use vertical tabs to
save horizontal space. Configure the input area to only 1 line tall, and
turn off as much other cruft as you can. The menu bars, sadly, cannot be
disabled, nor can the excessively large borders. In my screenshots, you
can see that stuff wasting space that could be used to show four more lines
of text.
For chat, you want to put the buddy list on the side of the
screen, and use the rest for conversation windows. Xmonad's
IM module
takes care of allocating a sidebar on the screen for the buddy window. The
rest of the screen can be occupied by any layout you choose.
I like to have the conversation windows be as wide as possible, and
typically only want to see two conversations at a time. But sometimes I
might have a dozen visible. A good layout to cope with those needs is
Grid.
myChat' l = withIM size roster l
where
-- Ratio of screen roster will occupy
size = 1%5
-- Match roster window
roster = Title "Buddy List"
myChat = myChat' Grid
The
withIM layout puts the buddy list on the left; I prefer it on the right
for some reason, so I tweaked my layout to do that. All it took was
using the
reflectHoriz layout modifier to get a mirror image of
the layout. Then I reflect the inner layout back to its normal orientation.
Being able to throw in a few function calls and mutate a layout like that
is where Xmonad shines.
myChat' l = reflectHoriz $ withIM size roster $
reflectHoriz $ l
logs
Ever notice that
tail -f wastes the last line of the terminal? On a netbook
this matters.
shorttail
lets the last line be used.
I have a dedidated workspace that I use to tail logs, and as a place to
send long-running tasks (such as compiles). The layout for this needs to
keep windows wide, to see whole logged lines, but they need only be five
or so lines tall. And it's convenient to have one bigger window with the
small ones below. Xmonad has a perfect layout for this, called
Dishes,
because it's sorta like a stack of plates.
myDish = limitWindows 5 $ Dishes nmaster ratio
where
-- The default number of windows in the master pane
nmaster = 1
-- Default proportion of screen occupied by other panes
ratio = 1/5
In the second screenshot above, I have 6 windows open, but only 5 are
visible. The limitWindows 5 accomplishes this. It's handy mostly because
gnome-terminal has a bad habit of crashing when resized to 0x0.
(That's gotta be a bug in something!)
Notice that the screenshots above also have Procmeter in a sidebar on
the right. I (ab)used the
withIM layout to do that:
myLogs' l = reflectHoriz $ withIM procmeterSize procmeter $
reflectHoriz $ l
where
-- Ratio of screen procmeter will occupy
procmeterSize = 1%7
-- Match procmeter
procmeter = ClassName "ProcMeter3"
myLogs = myLogs' myDish
coding
Everything above was easy. Doing coding (or writing) on a small screen is
where it gets hard. When I'm coding I want to have one window that is
exactly 80 columns wide, and as tall as possible, where I do the main
development. Then I need a minimum of two other windows also visible: one
action window for running tests and the like, and one to view references
(emails, man pages, other files, etc). I may need to view any of these
windows fullscreen at any time, of course.
As an example of the three window rule:
While I'm writing this post, I have a reference window open
with my .xmonad/xmonad.hs, and an action window open where I am
managing screenshots.
Often, deep into something, I will accumulate many other reference and action
windows. But three seems to be the magic, minimum number for me;
use of
screen or anything else doesn't reduce it; if I can't see all
three at once, I will waste time and concentration flipping back and forth.
The Xmonad layout I've developed to handle this is based on the handy
FixedColumn layout, which automatically keeps the master window 80
columns wide. I modify this by adding the
Magnifier, so that my action
and reference windows "pop out" over the master window when focused.
myCode = limitWindows 3 $ magnifiercz' 1.4 $ FixedColumn 1 20 80 10
The 1.4 was carefully tuned, to magnify a window to be big enough to be
usable for editing, reading, or command-line, while not obscuring too much
of the other two windows. And again I use
limitWindows, to only show
three windows, in order to keep them all as big as possible. Other windows
are hidden offscreen, but I can rotate to them with alt-tab as needed.
reading ebooks
When I'm reading an ebook, I want to have the reader in the middle of the
screen. But a widescreen netbook like mine is too wide to comfortably
read text all the way across, so it's nice to have margins. (In the margins,
I put terminals, or notes.)
The
ThreeColumns module has a layout that does just that.
myBook = ThreeColMid nmaster delta ratio
where
nmaster = 1
-- Percent of screen to increment by when resizing panes
delta = 3/100
-- Default proportion of screen occupied by master pane
ratio = 2/3
putting it all together
I join all my layouts together, so Xmonad will allow switching
between them. These three combinations all have the same layouts,
only ordered differently, so that different workspaces can have
different default layouts.
codeFirst = myCode myWide myGrid myDish
dishFirst = myDish myCode myWide myGrid
gridFirst = myGrid myDish myCode myWide
Xmonad layouts can be decorated with things like title bars. To save
horizontal space, I leave off the title bars on layouts where they
are not needed to disambiguate windows. Two helper functions can be applied
to add or remove titles (and also cause the layout to avoid the Gnome
panel.)
withTitles l = noFrillsDeco shrinkText myTheme (desktopLayoutModifiers l)
noTitles l = desktopLayoutModifiers l
I have semi-dedicated workspaces; one for each of the above activities.
To assign a layout to a workspace, I use the
PerWorkspace module.
Notice that the "web" workspace has only two available layouts.
Meanwhile, the "book" workspace always uses the specialized myBook
layout; I don't use that layout elsewhere.
perWS = onWorkspace "logs" (withTitles $ myLogs' dishFirst) $
onWorkspace "web" (noTitles $ (mySplit myWide)) $
onWorkspace "chat" (noTitles $ myChat' gridFirst) $
onWorkspace "book" (noTitles $ myBook) $
(withTitles $ codeFirst)
Finally, I allow toggling between the currently selected layout and
fullscreen mode, and use
smartBorders to avoid displaying borders when
there is only one window onscreen.
myLayout = smartBorders $ toggleLayouts Full perWS
Xmonad layout optimised for the small screen of a netbook:
Done!
(For now...)
PS: Thanks to
#xmonad regulars for always having the answer
I need up their sleeves.
So, one of the things I get to do during work hours for Collabora is to contribute code, and do maintenance tasks for WebKitGTK+, and have been doing so since early last year, working on all kinds of things, from improving the network backend to handle the real-world web, to fixing scrolling problems, while reviewing patches from the many awesome developers who have been joining us (more on that later =D).
One of the big features I have worked on this past month or so, along with Xan Lopez is the Page Cache. The page cache is a feature of web browsers that makes going back, and forward between pages in the same view very fast. It s better explained in this post, but to summarize, the idea is that instead of destroying all the work you have done since downloading the resources, and having to reparse/rebuild the structures the view uses to display the page from the cached resources, you hit pause on the page, and store the whole thing as is, and when coming back to it, you just hit play. You can see in the video two instances of Epiphany, one with the page cache enabled, one with it disabled. Easy to see which was has it enabled. Thanks to KiBi for the suggestion regarding a page that shows this easily =D.
<video controls="controls" height="302" src="http://kov.eti.br/media/webkit/page-cache.ogv" width="450"></video>
We initially thought we had this feature enabled, since our initialization functions (that exists since before the current maintainers were involved) did setup the number of desired pages in the cache, but during the hackfest we held in December we found out we were fooled all this time. Enabling the page cache does make going back faster, but also made lots of things become unstable and crash.
Since then, we have been working on figuring out all the problems, and fixing them, using help from adventurous users of in-development software ;D. I believe we re now at a point in which I can happily declare the GTK+ port has a working page cache in trunk! If you re interested in the nasty details, bear with me!
Let me go back in time a bit, and show you what problems we had. First, some background: the GTK+ port deviates a lot from the other ports when it comes to scrolling. This is because, when designing this part of the port, Holger Freyther had a very nice idea in mind: that the WebView should be a first-class citizen GTK+ scrollable widget. Meaning it would use GTK+ s adjustments for scrolling, and be able to interact with any parent scrolling widget, be it a GtkScrolledWindow, or a MokoFingerScroll.
We cannot just throw away all the rest of the scrolling code in WebCore, though, that deals with all the details related to interacting with the DOM, and JavaScript code. This means our WebView contains adjustments that need to be set, and unset on our port s version of WebKit s own representation of the view, called the FrameView, to interact with it, and to get updates on the bounds of content, and such. For every load, in the non-page-cache case, a new FrameView is created, the previous one is destroyed - this means we need to set the adjustments on every load.
The problem starts when you have the page cache enabled, because the code path used to do what is called commit the load of a cached page (that is, start replacing the content that is currently being displayed by the one that should now be displayed) is completely different, and we were not setting the adjustments on this new view, so we started with that.
But all was not well. We were still having weird behaviour with scrollbars disappearing, and becoming the wrong size, and worse, crashes when back was hit. We then started investigating in more detail how it is that the page cache does its magic, to try and figure out the source of all evil.
It turns out that when you leave a page that can be cached, the existing FrameView is no longer destroyed - it is stored as is in a CachedFrame to be restored if you go back, and a new one is created for the new page. This was having the undesired effect of having the adjustment be set in more than one FrameView at once, causing all kinds of (predictable, after we knew for real what was going on) unwanted effects. Thus, we reworked the code to make sure the adjustments are only ever set in one FrameView at once, making sure they are unset when the FrameView is being frozen, and reset when it s being restored from the page cache.
Last, but not least, it was discovered that going back to a page that contained resources with data: URIs (such as Google results pages which contain a small number of image hits) also caused a crash. This was because our network backend was not storing the data: URI in the ResourceResponse objects it fed into WebCore. The page cache relies on those responses to recreate the requests it uses to artificially replay the load when restoring the page from the page cache, so we fixed that as well.
What can be taken from all this? Building browsers is a lot of hard work! I can t think how we could deal with this level of complexity without the awesome testing suite of WebKit. The good news is all of those issues I talked about in this post are now covered by the automate tests that run as part of the normal buildbot cycle in our bots, so we re covered for the future, at least for these specific problems =D.
Multiple Sclerosis is a disease of the central nervous disorder that weakens the immune system. A study showed that obese adolescent girls affected by MS have opportunities in the future.
During the 40-year study of 238,000 women found that adolescent girls suffer from obesity at the age of 18 years had twice the risk of MS affected than teens of that age have more slender bodies.
Fatty tissue which accumulates as a teenager allegedly memproduki substances that affect the immune system that triggers the possibility of MS.
However, body size during the children and adults are not found in relation to risk of MS. Researchers have made a study report in the journal Neurology. Researchers still need to take further evidence to confirm these findings.
Researchers from the Harvard School of Public Health used data from the nurses about diet, lifestyle factors and health. During the study, 593 women are diagnosed with MS, a disease caused by loss of nerve fibers and myelin sheath in the brain and spinal cord that makes nerve damage.
Researchers compared the risk of disease with body mass index (BMI) or weight to height ratio, in women aged 18 years. Studies show those who have weight BMI 30 or greater at the age of 18 years had twice the risk of MS.
Our results indicate that body weight during adolescence is very important in determining the risk of MS, said Kassandra Munger ScD from Harvard School of Public Health in Boston, as quoted by BBC News, Monday (9/11/2009).
There are many studies that support that adolescence is an important time for the development of the disease, so what we found was associated with it, he said.
He added that obesity prevention early adolescence is an especially important step in reducing the risk of MS in the future.
Previous research has found vitamin D levels are high can reduce the risk of MS and the researchers showed that obesity associated with low levels of vitamin D in the body.
It might be quite premature, but in 
This year, at DebConf 10, I'll very probably have the pride to attend the conference
along with my 22 y.o. son, Jean-Baptiste.
JB began a 3 year cycle to graduate in electronics and industrial
computing at 
In Ubuntu, I uploaded an rng-tools that supports the 
I got involved with open-source software before I learnt about
software development in a university course. Naturally, when my
profs tried to teach the 
Registration is now open for DebConf10. The 
Agile Business Analysts?
I have recently been fleshing out my thoughts on the role of business analysts in an Agile team. This is something I have historically addressed on a case-by-case basis with clients, but when thinking about it last week at a client site, I realized that I do have a general take on how the role and responsibilities of a business analyst change when a group moves to using an Agile process. Per the usual, I ll be using Scrum as the example process where needed.
The Classical Roles
Historically the business analyst has had two primary roles. In a process where cross-functional communication and collaboration are minimized, these roles are essential. What little communication that takes place between the business and the software development teams purporting to serve them passes almost exclusively through one or more business analysts. I view the business analyst in a phased development approach as having two roles; Translator and Gatekeeper.
The Translator
The business analyst is primarily tasked with taking the needs of the business and translating them into a written document that is then handed to the software developers and testers. This role s necessity is based upon some fundamental assumptions. First, programmers and testers are on the whole, too socially retarded to actually talk to the business persons and find out what they want. Second, the business is primarily viewed as being unable to focus its thought long enough to tell the programmers and testers what they need. Since a key value of an Agile approach to software development is to have individuals and their interactions be the driving force rather than processes an tools (see 
