More docs, apps, and tweaks
Over a month since my last entry. Anyway.
The Work
I've been busy churning out the August issue of the Gentoo Monthly Newsletter, as well as a GMN Howto. This is a guide that details the process for creating the GMN, from start to finish. Over the last couple of months, it's gone from a simple 15-line cheat sheet to something a lot more useful for future GMN staff and any interested contributors.
A fair amount of documentation updates for the GDP, too. I was curiously unmotivated most of the month of August, though that's in part because of my health; I spent the first bit of it in the emergency room trying to figure out why my insides were coming apart. Still no idea.
And I've updated my devspace. Lots of changes. Lots of new stuff added and rearranged; I expect I broke some old links, but oh well. All that stuff in misc/ really needed organization.
I also poked aballier to get the new version of Decibel into the tree. Oh yeah. Upgrade to 0.11; it adds album cover art, among other things.
The Apps and the Machine
I've also been hacking up various ebuilds for packages not yet in the tree, such as tint2. This is all for my laptop, which I'm trying to slim down even more. Been removing various applications and making it much more of a minimal Xfce environment. Plus, I like pseudo-transparency. Apps like stalonetray, tint2 (ebuild available here), netwmpager, dzen2, and conky are all curiously appealing. I'm trying to find lightweight, useful, complementary apps to Xfce, in my perpetual quest to create the perfect Xfce environment.
I discovered many of these applications by reading urukrama's blog and kmandla's blog. Both are excellent sources of information on small, light apps, and setting up clean, minimal, functional environments. Quite tasty; be sure to give 'em a read. Especially urukrama's Openbox guide. It's loaded with configuration info, application tips, and much more.
The Environment
I've replaced most of my Xfce panel with stalonetray, conky, and a couple of instances of tint. I just installed dzen, and will be investigating it as a possible replacement for conky. Dzen, however, seems to need a lot of initial time-consuming configuration. And it doesn't seem to do transparency. And it doesn't look like it can even do useful fonts like Verdana.
What I'd really like to do is get rid of all but the start button on the panel, but first I need to find an icon launcher bar that does pseudo-transparency. Why not real transparency? Because compositing with the Intel X3100 graphics chip doesn't seem to be too friendly on my battery life. Actually, I'd be happy if tint had launcher capability now; I hear it's going to be in a future release. I'll just use it when that time comes.
Here's my current desktop: 1 and 2. I've managed to find a nice-looking level of transparency regardless of light or dark background, so everything's fairly clear. Too bad conky can't provide transparency and shade, similar to everything else. That left-hand panel will be going shortly; all I really need are the launchers and the start menu button. Must find a way to slim it down; it takes up too much space. Plus I don't care for vertical panel arrangements.
Since folks are always curious about what's what in any given screenshot:
Left to right: Xfce panel, stalonetray, tint, conky, and tint (just date/time). The wicd applet is anchored in the tray, and a few terminals and gtk+ apps are open in tint.
Background: (1) Liquid Crystal, (2) VSE Grass Flow.
Screen: 14.1", resolution of 1280x800. I notice that when viewing it on my 19" 1440x900 desktop monitor, how large the fonts look. Well, they're much smaller on the laptop. The laptop resolution is so high that I have to enlarge things considerably; my eyes aren't what they used to be.
Restoring the Xfce panels
One question that people looking for help with Xubuntu often have is some form of “my panels/taskbar/menu disappeared”. Unfortunately, this is something that happens quite frequently.
The good news is that this is fixed easily. All that’s required is to press Alt+F2 to bring forward the Run program window, and run the command xfce4-panel.
Not only is this a quick fix for the problem, it also makes for a quick blog post that might still help quite a few people 
Update: Xubuntu 9.04 will include Xfce 4.6 which should be able to automatically restore the panel in the event of a crash. Hooray 
Update to that: According to willerlite, the panels do not automatically re-appear. Hmm :S
Mount remote file systems (Tape #2)
I once wrote about sshfs.sh, a shell script to mount a remote file system with sshfs. This is now deprecated!Now I'm giving a try to gvfs-mount. Currently I can mount a volume and list it with gvfs-mount --list, but I cannot browse inside it because it isn't mounted. I played with the --mountable argument, but it must be a joke. I think I need a something fuse daemon from gvfs... I'll keep this up to date.
Update: Everything is alright now. The output of
ps ax | grep gvfs shows the following process: /usr/lib/gvfs/gvfs-fuse-daemon. All your mount operations will be available at $HOME/.gvfs.The recent GTK+2.14 release introduces a widget to ask a password thats called GtkMountOperation (have a look at the GTK+ blog). It might be interesting to start a Thunar plugin, and release it officially with Xfce 4.8.
Update 2: And on a fresh Debian install (or in general anyway) don't forget to install the fuse-utils package (
/usr/bin/fusermount)!
Signals
I meant to write about this a while ago, but I forgot, and it just popped into my head for some reason.
If you’re ever using POSIX signals as a means of primitive IPC, and SIGUSR1 and SIGUSR2 aren’t enough for you, never, ever, EVER make use of SIGRTMIN and/or SIGRTMIN plus some offset. Always use SIGRTMAX and SIGRTMAX minus some offset.
Why?
(Disclaimer: this might only be a problem on Linux, but if you want your app to be portable, blah blah blah…) Depending on what C library you’re using, and what pthreads implementation you’re using, the actual numerical value of SIGRTMIN may not be the same in different applications, depending on – get this – whether or not the app links with libpthread. In my case, the pthread impl makes use of the first 3 SIGRT slots, and so when you use the SIGRTMIN macro, you actually call __libc_current_sigrtmin(), and you get a number that’s 3 higher than what you get when you use SIGRTMIN in an app that doesn’t link against libpthread.
Fortunately, SIGRTMAX (which actually expands to a call to __libc_current_sigrtmax()) seems to be a bit more stable. That is, even if SIGRTMIN gets shifted up 3 slots, SIGRTMAX is still the same.
So, the moral of the story is: I never want to see the SIGRTMIN macro ever appear in your code, unless you really know what you’re doing. Instead, use things like SIGRTMAX, SIGRTMAX-4, etc. It may just save you 4 hours of debugging.
Signals
I meant to write about this a while ago, but I forgot, and it just popped into my head for some reason.
If you're ever using POSIX signals as a means of primitive IPC, and SIGUSR1 and SIGUSR2 aren't enough for you, never, ever, EVER make use of SIGRTMIN and/or SIGRTMIN plus some offset. Always use SIGRTMAX and SIGRTMAX minus some offset.
Why?
(Disclaimer: this might only be a problem on Linux, but if you want your app to be portable, blah blah blah...) Depending on what C library you're using, and what pthreads implementation you're using, the actual numerical value of SIGRTMIN may not be the same in different applications, depending on -- get this -- whether or not the app links with libpthread. In my case, the pthread impl makes use of the first 3 SIGRT slots, and so when you use the SIGRTMIN macro, you actually call __libc_current_sigrtmin(), and you get a number that's 3 higher than what you get when you use SIGRTMIN in an app that doesn't link against libpthread.
Fortunately, SIGRTMAX (which actually expands to a call to __libc_current_sigrtmax()) seems to be a bit more stable. That is, even if SIGRTMIN gets shifted up 3 slots, SIGRTMAX is still the same.
So, the moral of the story is: I never want to see the SIGRTMIN macro ever appear in your code, unless you really know what you're doing. Instead, use things like SIGRTMAX, SIGRTMAX-4, etc. It may just save you 4 hours of debugging.
Signals
I meant to write about this a while ago, but I forgot, and it just popped into my head for some reason.
If you’re ever using POSIX signals as a means of primitive IPC, and SIGUSR1 and SIGUSR2 aren’t enough for you, never, ever, EVER make use of SIGRTMIN and/or SIGRTMIN plus some offset. Always use SIGRTMAX and SIGRTMAX minus some offset.
Why?
(Disclaimer: this might only be a problem on Linux, but if you want your app to be portable, blah blah blah…) Depending on what C library you’re using, and what pthreads implementation you’re using, the actual numerical value of SIGRTMIN may not be the same in different applications, depending on — get this — whether or not the app links with libpthread. In my case, the pthread impl makes use of the first 3 SIGRT slots, and so when you use the SIGRTMIN macro, you actually call __libc_current_sigrtmin(), and you get a number that’s 3 higher than what you get when you use SIGRTMIN in an app that doesn’t link against libpthread.
Fortunately, SIGRTMAX (which actually expands to a call to __libc_current_sigrtmax()) seems to be a bit more stable. That is, even if SIGRTMIN gets shifted up 3 slots, SIGRTMAX is still the same.
So, the moral of the story is: I never want to see the SIGRTMIN macro ever appear in your code, unless you really know what you’re doing. Instead, use things like SIGRTMAX, SIGRTMAX-4, etc. It may just save you 4 hours of debugging.
xfce trunk
Some of you may have recognized that xfce-4.6 alpha (aka pinkie) still isn't released.I just decided to pack xfce directly from trunk.
It's available at xfce.rpath.org@xfce:devel.
there are some minor problems when updating to group-xfce=xfce.rpath.org@xfce:devel, so that you probably need to remove some packages not needed anymore.
It's not build automaticly from trunk (yet) and I still use the xfce goodies from fl:2.
using trunk for xfce-goodies would be a next step though.
Here are 2 screnshots:
This is xfce with thunar and a "rolled in" Terminal
But thunar hides the mouse, so I closed it
