Since no one on the Gnome mailing list seems to be able to answer these questions I thought I’d try some other venues for getting them answered. The audience for my blog isn’t that big, but just maybe there’s someone out there who knows the answers to these questions related to Gnome configuration. Mail one and mail two.
1: Running GUI tool after NM has brought up network
I run dropbox on my laptop, but their software is crap at handling that the network comes up only after the dropbox service has startedi
I know of the possibility of dropping a file in /etc/NetworkManager/dispatcher.d/, but that doesn’t work in this case since I need the program to run “in my desktop”. Well, at least I haven’t managed to get the dropbox server to throw up an icon in my Gnome tool bar like it should, unless I run it from inside the desktop environment.
Any suggestions on how to solve this problem?
2: Changing background of the Gnome screensaver
I think Gnome comes with quite possibly the ugliest background for a screensaver I’ve ever seen. It’s a close-up on a green leaf or something. Absolutely hideous. I want to change it. To something nice, like a solid black. Actually just about anything else would do. But how?
I’ve noticed no problem when network goes away and then comes back, dropbox picks that up just fine. But if the network isn’t there to start with, that it can’t handle. I’m somehow at a loss how to write a program that handles the former but not the latter. [back]
The script is somewhat artificial, who would ever use the construct true | while ...? I’ve used this just to show the point while keeping the examples short. Feel free to replace that part with something more useful, like cat myfile | while read ....[back]
This is another one of those posts that I make mostly for myself, you know for
organising and help my memory
There are as far as I can see three ways to deal with sockets in Haskell.
There’s the type Socket which is used throughout Network.Socket. From
that it’s possible to get to the underlying filedescriptor, and it in turn can
be converted to a Handle.
When coupled with fork+exec it’s crucial to make sure the child process can
find the socket Leaving it in a predictable place seems to be the easiest way
to do that, and as far as I can see that requires using dupTo from
System.Posix.IO. So, on the child-side it’s necessary to find a way to turn
an integer (CInt) into something that can be treated as a socket (i.e. a
Socket, a Handle, or a filedescriptor).
A basic parent-child which obviously won’t work since the child’s socket is
represented as a Socket:
import Control.Concurrent
import System.Posix.Process
import Network.Socket
childFunc s = send s "Ping from child">>return()
main =do(childSock, parentSock)<- socketPair AF_UNIX Stream defaultProtocol
print(childSock, parentSock)
child <- forkProcess $ childFunc childSock
recv parentSock 10>>=print
Let the child take a CInt and turn it into a filedescriptor:
import Control.Concurrent
import Control.Concurrent.MVar
import System.Posix.Process
import System.Posix.IOimport System.Posix.Types
import Network.Socket
childFunc sInt =dolet fd = Fd sInt
fdWrite fd "Ping from child">>return()
main =do(childSock, parentSock)<- socketPair AF_UNIX Stream defaultProtocol
let childInt = fdSocket childSock
print(childInt, parentSock)
child <- forkProcess $ childFunc childInt
recv parentSock 10>>=print
Let the child take a CInt and turn it into a Handle:
import Control.Concurrent
import System.Posix.Process
import System.Posix.IOimport System.Posix.Types
import Network.Socket
import System.IO
childFunc sInt =do
h <- fdToHandle $ Fd sInt
hPutStr h "Ping from child"
hFlush h
main =do(childSock, parentSock)<- socketPair AF_UNIX Stream defaultProtocol
let childInt = fdSocket childSock
print(childSock, parentSock)
child <- forkProcess $ childFunc childInt
recv parentSock 10>>=print
Let the child take a CInt and turn it into a Socketi:
import Control.Concurrent
import Control.Concurrent.MVar
import System.Posix.Process
import System.Posix.IOimport System.Posix.Types
import Network.Socket
childFunc sInt =do
s <- mkSocket sInt AF_UNIX Stream defaultProtocol Connected
send s "Ping from child">>return()
main =do(childSock, parentSock)<- socketPair AF_UNIX Stream defaultProtocol
let childInt = fdSocket childSock
print(childInt, parentSock)
child <- forkProcess $ childFunc childInt
recv parentSock 10>>=print
With Python being dropped as a language for extensions in epiphany 2.28 I needed to replace epilicious. I tried writing it in JavaScript (seed was integrated in 2.28), but I gave up due to hitting too many hurdles on the way. Instead I decided to rewrite epilicious using Vala and a minimal layer of C.
It turned out to be very doable, despite epiphany’s extension API lacking Vala bindings (Cosimo Cecchi, I’m looking at you ). Basically I did the following setup:
Add a rule in the extension’s Makefile.am to generate a C header file for all the Vala code, for use from C.
Then I started writing the actual extension. I did the minimal amount of work in C, trying to escape as soon as possible into Vala. In the few places I needed to call from Vala into C I would declare a delegate in Vala, and pass a function from Ci.
I call this new version BMS, for bookmark synchronisation. I have a patch for BMS that applies to epiphany 2.28.1. (The file also contain a PKGBUILD in order to delight Arch users )
I should probably point out that while epilicious never could be called polished, BMS is even less so. I might find the time to make it multi-threaded, so that it’s possible to do some sort of progress dialogue, but don’t hold your breath. In the back of my mind is also the thought of rewriting it yet again, in JavaScript/seed.
The format of .vapi files are unknown to me, and I haven’t managed to find much documentation. Using function pointers seemed like an easier way, especially given that I needed this in exactly 3 places.[back]
A few days ago I noticed that there were a few Haskell packages on AUR that
had received updates. This was the excuse I had been waiting for to address
the second part of keeping my Haskell packages up-to-date (I’ve written about
the first part before, dealing with an update to GHC).
It’s easy to find the packages with available updates:
% yaourt -Su--aur
Unfortunately it isn’t as easy as just updating the listed packages. Any
package that depends on an updated package really should be re-compiled and
re-installed to guarantee that the entire system behaves as expected after the
upgrade. Of course pacman can handle it:
% pacman -Rcn<all pkgs with updates>
This will list all packages that will be removed. After removing them all,
they can all be re-installed. That is of course not quite as nice as it could
be, since they all then will be explicitly installed, it would be nicer to
just re-install the “top-level packages”. This is one way to achieve this.
I did a bit of refactoring and put the Arch-related functions from the
previous post in their own module, Arch. Then I added a function that takes
a package and recursively inspects Required By until a “top-level package”
(i.e. a package that doesn’t require any other package) is reached:
getTopRequiredBy pkg =let
tops =do
first <- getRequiredBy pkg
ifnull first
thenreturn[pkg]else liftM concat$mapM getTopRequiredBy first
in liftM nub tops
After that it’s straight forward to write up a little tool which offers some
advice on what to do:
![[Digg]](http://therning.org/magnus/wp-content/plugins/bookmarkify/digg.png)
![[Reddit]](http://therning.org/magnus/wp-content/plugins/bookmarkify/reddit.png)
[back]