Posts from the ‘Gnome’ Category
Adding a custom theme to GIMP
GIMP running on .nix distributions that support the Gnome desktop environment can be used with custom themes. Following is a brief how-to which covers doing this on OpenIndiana oi_151a x86, with GIMP 2.6. The method should be very similar or identical for Linux distributions (e.g. Ubuntu).
First, let’s locate a sample GTK theme. I am using a rather nice theme called “Darkilouche” found here:
http://art.gnome.org/themes/gtk2/1285
Simply download the compressed file in the above link, and extract the contents to disk.
Next, we need to locate the gtkrc file in the uncompressed theme folder. The sample theme we are using contains the following files and directories once uncompressed:
$ ls -al total 7 drwxr-xr-x 4 dave staff 5 2012-03-07 22:47 . drwxr-xr-x 3 dave staff 3 2012-03-07 22:47 .. drwxr-xr-x 6 dave staff 9 2007-02-28 00:22 .svn drwxr-xr-x 3 dave staff 4 2007-02-28 00:22 gtk-2.0 -rw-r--r-- 1 dave staff 240 2007-02-28 00:23 index.theme
The gtkrc file sits within the gtk-2.0 directory, and appears to be the only critical file that is needed.
Next, we copy the gtkrc file into the GIMP themes directory. In this example, I am using the global GIMP themes directory at /usr/share/gimp/2.0/themes. We simply create a directory named after the theme we are installing (in this case “Darkilouche”), and copy the gtkrc file into it.
Finally, we launch or restart GIMP and test that the theme is accessible at Edit -> Preferences -> Theme. The following screengrab illustrates that GIMP has found the theme, and, it is also the active theme:
OpenShot video editor for Linux – watch out iMovie…
I’ve recently begun to use OpenShot on Ubuntu Linux to edit a series of short screencasts with, and holy smoke what a pleasant surprise. Stable, easy to use (including a polished and smoothly responsive UI), a nice selection of effects and transitions, and pretty darn stable to boot:
It’s pretty much based on the iMovie paradigm, before Apple screwed too badly with it. Lots of advanced goodies which the competition doesn’t have, like fancy 3D animated and SVG titles via integration with Blender and Inkscape. Built-in support for insta-upload to YouTube. Even the documentation is great. Between Ubuntu, ffmpeg, and OpenShot (oh, and Audacity for the audio), it’s entirely possible to put together high-quality screencasts for zero software cost.
OpenShot is totally worthy of a donation, which I have happily made.
recordMyDesktop, Ogg video files, and OpenShot – part 2
A quick follow up to my post here. As it turns out, VLC refuses to play back any Ogg file generated by recordMyDesktop at normal speed: playback jumps all over the shop, with the net effect of it appearing to run much faster than the speed it was actually originally captured. So, we are shit out of luck with using it to transcode recordMyDesktop files for editing in OpenShot.
You can read what the VLC core developers thought of this issue in posts 8 and 9 here:
http://forum.videolan.org/viewtopic.php?f=2&t=94169
Frustrating that recordMyDesktop is so close to being perfect for my needs, but as it’s a defunct project I am forced to look elsewhere. Turns out that the ffmpeg command line utility can be used to capture a live desktop (loads of guides on the web on this topic), so in a follow up post I will outline my efforts to use this instead.
Like this:
Interview with Damien Sandras, creator of Ekiga
As posted on the Ekiga users mailing list, this is an interesting interview conducted recently with Damien Sandras. Lots of good stuff here, from his views on the future of the project to how it compares with the default VoIP apps in Ubuntu.
OpenIndiana 151a is out – and powered by Illumos
In case you haven’t already heard, OpenIndiana development release 151a is out. The critical change in this release is that it’s now based on the Illumos kernel, developed by star ex-Sun Microsystems talent in the wake of Oracle’s compeltely styleless killing off of OpenSolaris. Substantial new features which you won’t be seeing in Solaris 11 anytime soon such as KVM support are built-in and tightly integrated. And yes, KVM support for AMD CPUs is on the way – hopefully in time for the 8-core AMD Bulldozer architecture desktop CPUs…
There are also a nice set of desktop software additions, some of which OpenIndiana and OpenSolaris before it has been needing for ages, for example a capable suite of multimedia playback applications. OpenIndiana now has dedicated SFE repositories from which VLC and Mplayer can be installed, as well as bonus goodies such as Scribus and more.
OpenIndiana download links, release notes, and SFE repository details:
http://openindiana.org/
http://wiki.openindiana.org/oi/oi_151a+Release+Notes
http://wiki.openindiana.org/oi/Spec+Files+Extra+Repository
After running 151a for a few days (the upgrade from release 148 was completely seamless by the way), I was presented with something I hadn’t seen for a long time, not since OpenSolaris development was closed off a couple years back…
Sipdroid interoperability with Ekiga 3.2.7
I’ve recently been playing around with various mobile SIP clients, testing how well they work making calls to Ekiga 3.2.7 clients running on the desktop. Following are some notes I’ve collected using Sipdroid 2.0.1 Beta, running on a Motorola Milestone with Android 2.1.
In all tests, I am using the Milestone on the Vodafone New Zealand 3G network, while my desktop clients are all connected to either corporate LANs with public IP addresses, or running NATed on home networks.
Generally, for voice calls, Sipdroid plays quite well with Ekiga using this network arrangement, but there are some niggles regarding the various audio codecs either SIP application supports. A summary of this follows.
Speex
First, it appears that the speex (11kbit) codec in Sipdroid’s implementation is just plain incompatible with either the Speex 8khz or Speex 16khz codecs featured in Ekiga.
Enabling only the speex (11kbit) codec in Sipdroid, and Speex 8Khz in Ekiga, I could make calls to Ekiga from the Milestone fine, but calling from Ekiga to the Milestone results in an incompatible codec error at the phone end, and the call then immediately terminates.
Enabling only speex (11kbit) in Sipdroid, and Speex 16Khz in Ekiga, calls cannot be made in either direction. Calling from the Milestone to the PC, Ekiga gets an incoming call notification but on accepting the call, the connection is lost at the PC end, with a notification that the call was missed. On the Milestone, it simply continuously reads “Dialling”. Connecting to the Milestone from the PC, one gets the same codec error as above before the call terminates.
PCMA
Calls made from the Milestone to Ekiga worked great, and vice versa.
PCMU
Calls made from the Milestone to Ekiga using PCMU also worked great, and vice versa.
An interesting observation at this point is that if the PCMA, PCMU and Speex codecs are all enabled in both Ekiga and Sipdroid, and in Ekiga Speex is sorted in the audio codecs window to be at the top, then calls made from Ekiga to the Milestone will fail with the codec incompatibility error. Calls made from the Milestone to Ekiga however are fine, but will fall back to a PCMU/PCMA codec.
G722
Calls made from the Milestone to Ekiga using the G722 audio codec also worked great, and vice versa.
GSM
Calls made from the Milestone to Ekiga using the GSM audio codec also worked great, and vice versa.
Ubuntu 10.10 x86 and older nVidia graphics cards
A couple months back, I upgraded a friend’s computer via software update to Ubuntu 10.10. She had been happily running Ubuntu 10.04 on an old Pentium 4 box, with an equally vintage nVidia Quadro4 380 XGL installed in it. Accelerated 2D and 3D was no problem courtesy of nVidia’s legacy drivers.
Well, all that changed after the update, and post-update-reboot we had no window manager. It took close to an hour of fiddling around before I eventually read the small type in the release notes and realised that the nVidia legacy drivers for the Quadro4 380 were not compatible with the updated Xorg server in the Ubuntu 10.10 release.
You can read the whole saga here, but in short, the good news was we were saved at the time by two things; nVidia’s completely awesome effort in the updating of the driver for a vintage graphics card to work with the new Xorg, and the generosity of a community developer who packaged it into a PPA. It’s just a shame that Canonical didn’t place far more emphasis on warning users with older hardware that an OS update might make their system unusable!
Since then, the nVidia driver update has made it into the Ubuntu maverick-proposed repository, as I found out recently when installing Ubuntu 10.10 on another machine of similar vintage (this time with an nVidia Quadro4 550 XGL installed in it). So, only a simple tick-box needs to be checked for the driver to be downloaded and installed automatically:
After doing this, run a software update, and install both the “nvidia-96″ legacy driver, plus a couple of additional updates, such that it is handled by the GNOME hardware driver installation utility:
After updating, run the GNOME “Hardware Drivers” utility (“System -> Administration -> Hardware Drivers”), and install the driver visible there:
After a restart, accelerated graphics are back in Ubuntu 10.10. A note of thanks to nVidia – it’s stuff like this that makes me want to buy your products! :)
Outgoing SIP call problem in Ekiga 3.2.7 on OpenIndiana
Quick problem with a quick resolution: on my desktop OpenIndiana oi_147 machine, I found I was unable to make SIP voice calls to any of my contacts, nor even a test call to the the test service at sip:500@ekiga.net.
After a quick posting to the Ekiga mailing list with an accompanying debug file, I received a helpful response from another user (Eugen Dedu), who pointed out that packet sizes were too big as a result of too many audio codecs being selected in the application preferences.
After enabling a basic set of audio codecs in Ekiga, I could then place calls fine:
Ekiga could do with some fine tuning vis a vis somewhat more helpful error reporting, but all the same I am glad to have this working. For VoIP calls at least there is an impressive amount of interoperabilty on offer here amongst Windows, Linux, and OpenIndiana platforms. With a bit more testing and documentation (eventually branching out to H323, video, and interoperability with commercial hardware-based SIP/H323 solutions) I’m looking forward to recommending Ekiga as a one-stop solution for cross-platform open source desktop A/V conferencing.
Some quick Gnome/OpenSolaris tips…
1) How do I alter the default window size of the Gnome Desktop terminal when launched?
Add the geometry option to the gnome-terminal command. For example, I have a Gnome Terminal Panel item configured to launch with:
gnome-terminal --geometry=130x40
2) In an Gnome-based Virtualbox Unix/Unix-like guest, why can’t I use the numeric keypad as expected?
Chances are the “Pointer can be controlled using the keypad” setting is enabled in the Gnome keyboard preferences. Go to System -> Preferences -> Keyboard, and disable this setting under the “Mouse Keys” tab:
3) Why doesn’t the OpenSolaris Gnome Volume Applet remember the volume settings between reboots?
Yeah, this is small but incredibly annoying – and a right pain in the arse to have to twiddle the volume setting every morning. Hasn’t been fixed in about forever.
There is a workaround mentioned here:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6606096
However, there are two problems with it. First, /etc/X11/gdm does not exist on my snv_134 x64 system (the correct location is /etc/gdm) and second; the mixerctl command has been replaced by audioctl in build 130 onwards.
Therefore on my snv_134 x64 system I made the following changes to apply a revised workaround:
Edit /etc/gdm/PostSession/Default so it contains the following line:
audioctl save-controls -f $HOME/.ossaudiosettings
Edit /etc/gdm/PreSession/Default so it contains the following line:
audioctl load-controls $HOME/.ossaudiosettings
Audio settings should then be remembered on reboot.
4) How do I shorten the GRUB menu wait time on OpenSolaris?
On an snv_134 x64 system, edit the timeout value in /rpool/boot/grub/menu.lst
For example:
timeout 5
Results in a wait time of 5 seconds.
