from gi.repository import Gio s = Gio.Settings.new("org.gnome.libgnomekbd.keyboard") s.set_strv("layouts", ["de"])
Dear Gnome people. Is there a reliable way to right-attach panel applets? May laptop screen and my external monitor have different resolutions, and I havn't found a reliable way (except making two panels) of getting some of my applets to stick to the right. I usually keep my launchers on the left, while vairous system status icons on the right part. But when switching to a higher resolution, at most one will move to the right end of the panel at the new resolition, while the others just stay in place (i.e. left-attached at a given pixel position).
There are so many smart layout managers, GTK pretty much always uses flexible layout managers, why is the Gnome panel relying pixel offsets?
It has been suggested to me a couple of times that I could achieve this via gconf. However, since the gconf changes are not reflected at runtime but frequently overwritten I did not get this to work reliably even just for two applets.
Thank you. If you have any comments, please email me via.
On a side note, this is also the first true post to my new blog. :-)
I use the following python script to choose a random background on login:
#!/usr/bin/python import os, os.path, random, gconf startdir="PUT YOUR FOLDER HERE" gkey="/desktop/gnome/background/picture_filename" imgs= for root, dirs, files in os.walk(startdir): for file in files: base, ext = os.path.splitext(file) if ext.lower() in [".jpg", ".png", ".svg"]: imgs.append(os.path.join(root, file)) img = random.choice(imgs) gconf.client_get_default().set_string(gkey, img)
It's fairly simple, but shows the power of the python libraries. It "walks" the directory tree, collects all files of the given extensions, chooses one at random, then updates the gconf key for the Gnome background image.
P.S. Yes, I know a couple of ways to do that in a shell script, too. However, then one I used failed with whitespace in file names, so I decided to rewrite it in a much more sane language ... the random involved was also a hack.
, one of my favourite (read: must-have) Firefox extensions can also be used with Epiphany (see their 'other browsers' install).
However, whitelisting doesn't seem to work for me. Any pointers?
I've set 'flashblock.whitelist' accordingly in about:config, but it doesn't work... :-(
I've been added to Planet GNOME (thanks jdub!), and this post is just to say hello!
I havn't been a large GNOME contributor so far (I was the Debian maintainer for Galeon some years ago, thats about it), but I recently started a small DBus related project (for exploring the DBus APIs of programs), dbus-inspector, which is now hosted in the GNOME subversion repository.
Other GNOME-related projects I'm thinking of:
I'd like to say thank you for all the great work you did. Having been a Galeon power user, I'm by now quite convinced of the "keep it simple" approach, and I have the impression that not having so many options means that I get more work done (since I don't waste time playing around with infinite options). Thanks for that. And for providing me with a pretty and unobtrusive work environment for the last 8 years or so.
[Scott James Remnant http://www.livejournal.com/users/keybuk/13606.html] accused me of not knowing about memory usage.
I do know about shared libraries and shared memory. Still, loading libraries i wouldn't need to keep in memory otherwise does eat up memory. If you look at the ld output for evolution data server (note that i'm not talking about evolution itself!)
libedata-book.so.1 => /usr/lib/libedata-book.so.1 (0x4002d000) libebook.so.8 => /usr/lib/libebook.so.8 (0x40047000) libedata-cal.so.5 => /usr/lib/libedata-cal.so.5 (0x40075000) libegroupwise.so.3 => /usr/lib/libegroupwise.so.3 (0x4009a000) libsoup-2.2.so.3 => /usr/lib/libsoup-2.2.so.3 (0x400ac000) libecal.so.6 => /usr/lib/libecal.so.6 (0x400d3000) libedataserver.so.3 => /usr/lib/libedataserver.so.3 (0x40172000) libldap.so.2 => /usr/lib/libldap.so.2 (0x4023b000) liblber.so.2 => /usr/lib/liblber.so.2 (0x40270000) libresolv.so.2 => /lib/tls/libresolv.so.2 (0x4027d000) libgnome-2.so.0 => /usr/lib/libgnome-2.so.0 (0x4028f000) libesd.so.0 => /usr/lib/libesd.so.0 (0x402a5000) libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0x402ae000) libgnomevfs-2.so.0 => /usr/lib/libgnomevfs-2.so.0 (0x402d2000) libgconf-2.so.4 => /usr/lib/libgconf-2.so.4 (0x40333000) libbonobo-2.so.0 => /usr/lib/libbonobo-2.so.0 (0x4035d000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0x403b8000) libm.so.6 => /lib/tls/libm.so.6 (0x404b3000) libgnutls.so.10 => /usr/lib/libgnutls.so.10 (0x404d6000) libtasn1.so.2 => /usr/lib/libtasn1.so.2 (0x40536000) libgcrypt.so.7 => /usr/lib/libgcrypt.so.7 (0x40547000) libnsl.so.1 => /lib/tls/libnsl.so.1 (0x40593000) libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0x405a8000) libz.so.1 => /usr/lib/libz.so.1 (0x405ac000) librt.so.1 => /lib/tls/librt.so.1 (0x405bd000) libbonobo-activation.so.4 => /usr/lib/libbonobo-activation.so.4 (0x405c3000) libORBitCosNaming-2.so.0 => /usr/lib/libORBitCosNaming-2.so.0 (0x405d9000) libORBit-2.so.0 => /usr/lib/libORBit-2.so.0 (0x405de000) libpopt.so.0 => /lib/libpopt.so.0 (0x4062d000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x40635000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x4066f000) libdl.so.2 => /lib/tls/libdl.so.2 (0x40673000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x40677000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x4067c000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x4068b000) libc.so.6 => /lib/tls/libc.so.6 (0x40709000) libcrypt.so.1 => /lib/tls/libcrypt.so.1 (0x40845000) libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x40871000) libgnutls.so.11 => /usr/lib/libgnutls.so.11 (0x40886000) libasound.so.2 => /usr/lib/libasound.so.2 (0x408ec000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0x4099c000)
Is there a single library the data server does NOT link on my system?
I guess if i hadn't got 512 MB of RAM i wouldn't be able to run all my beloved GNOME2 stuff, galeon, xchat and the omnipresent evolution data servers...
And program startup times do depend on the amount of libraries they need to load (yes i know that evolution is starting a lot faster because the data server has already loaded all the libraries into memory)
I've been working on an MMU-less embedded ARM system for the last 10 months. Since then i've been a lot less confident in the code quality - especially wrt to memory management - of open source software. (Of course there are many good apps around, too)
I'd love to see studies how much speed difference a more conservative memory use can make on systems that are low on memory (which probably applies to desktop machines with <= 256 MB already nowadays)
I'm playing around with evolution from unstable.
Now that it doesn't crash all the time for me again, i often launch it, since i havn't found a way in =mutt= to provide me with such a nice overview over the amount of unread mails.
But one thing that really scares me, since the gnome clock applet also relies on this information (and the process storing it)
Evolution data server - which doesn't have any gui at all AFAICT, still links against about all gnome libraries - does eat up more than 80 MB of RAM on my machines. And evolution-alarm is quite close, too with 68 MB.
The maildir the data server "monitors" have about 43 MB, since i move the mails into an unmonitored trash dir after 30 days.
So *what the hell do evolution-data-server and evoution-alarm actually need this memory for*?
Seems to me like the Gnome People should add a new focus (i really like their user interfaces, please ignore the most famous gnome troll, ogalaxyo, and his goneme). Not everything is about user interfaces, but a sensible use of resources is also necessary for good applications.