Home Home > Desktop
Sign up | Login

Deprecation notice: openSUSE Lizards user blog platform is deprecated, and will remain read only for the time being. Learn more...

Archive for the ‘Desktop’ Category

Locking down GNOME in SUSE 11 based distributions

January 20th, 2010 by

Locking down the desktop may be an important functionality for you or it may be a major annoyance. This depends on your point of view and on which side of the administration fence you are. There are certainly many use cases where the restriction of desktop functionality is very important. One such use case may be the configuration of machines in a teaching environment.

For GNOME, Sabayon is a GUI tool that allows you to set up the desktop to your liking and store the configuration as a profile. Profiles can be deployed to any system allowing the machine to display the desired desktop based on who logs into the machine. Further you may also use Pessulus to lock down the GNOME desktop. Additional information may also be found in the GNOME Admin Guide.

In addition to the options mentioned above there is a command line tool (gconftool-2) you may use to create customizations from the command line. The gconftool-2 tool creates entries in the configuration tree for gconfd, the GNOME configuration daemon. The GNOME configuration is stored in XML files named %gconf.xml in a directory structure where directory names indicate the part of the desktop or GNOME application to which the features set in the XML file apply. For example options set in apps/nautilus/desktop/%gconf.xml determine the behavior of Nautilus when the desktop is drawn.

For users the configuration tree is stored in $HOME/.gconf allowing users to configure the desktop appearance and application behavior to their liking. For system wide configuration, configuration trees exist in /etc/gconf. Within the /etc/gconf directory structure the gconf.xml.mandatory directory tree represents the configuration tree that is used to lock down the system. Options specified in the /etc/gconf/gconf.xml.mandatory configuration tree cannot be altered by the user.

For example if we want to disable icons for mounted volumes to be displayed on the desktop and we would not want users to be able to enable this feature the following command will do the trick:

gconftool-2 --direct --config-source \
 xml:readwrite:/etc/gconf/gconf.xml.mandatory \
 --type boolean --set /apps/nautilus/desktop/volumes_visible "false"

The path of the parameter to be set can be determined by using the gconf-editor tool. The gconf-editor is an editor/browser for the GNOME configuration tree and is very helpful when trying to find features to be manipulated within the GNOME configuration directory. Detailed information about the gconf-editor can be found here. Knowing the path for the option to be set and the location of the configuration tree that contains the locked down configuration (/etc/gconf/gconf.xml.mandatory) it is easy enough to create a script that can be executed when a machine is set up to configure the desktop appearance as desired.

If you are using KIWI to create system images the gconftool-2 commands can easily be added to the config.sh script to configure the desktop behavior in the image. Creating a self installing CD/DVD or USB stick with KIWI allows you to deploy your pre-configured desktop image when ever a new system needs to be commissioned.

As a final option to locking down GNOME there is the well trusted route of editing the configuration files. Important when creating a GNOME configuration tree manually is that a %gconf.xml file needs to exist at every level. Considering our previous example one will need to create a %gconf.xml file as shown in the directory tree layout below:

apps
   |__ %gconf.xml
   |
   |__ nautilus
              |__ %gconf.xml
              |
              |__ desktop
                       |__ %gconf.xml

The XML files at the apps and nautilus directory levels are empty but must exist. The %gconf.xml file at the desktop level contains the following entry:

<?xml version="1.0"?>
<gconf>
    <entry name="volumes_visible" mtime="1260052996" type="bool" value="false"/>
</gconf>

The XML is simple enough and self explanatory. Further as you explore the configuration in the gconf-editor tool the types to be entered in the XML are fairly obvious. One caveate applies for entries of type string. Rather than having the value of a string configuration option be an attribute of the entry element like other types the string is special. For a string you will need to use the <stringvalue> child element of the <entry> element. For example if you wanted to disable the panel completely you would have the following entry

<?xml version="1.0"?>
<gconf>
    <entry name="panel" mtime="1263563592" type="string">
        <stringvalue></stringvalue>
    </entry>
</gconf>

in /etc/gconf/gconf.xml.mandatory/desktop/gnome/session/required_components/%gconf.xml

The gconftool-2 command creates the tree in the location specified with the –config-source command line option. Thus you can switch between manual edits and using a tool very easily. Once you have your tree you can package it up as an RPM and also add it to your auto YaST deployment if you are using this methodology.

With the available tools and/or by editing the configuration files directly locking down the GNOME desktop is relatively straight forward. The tricky part often is to find the correct file or the correct button to push for the desired behavior. This is where gconf-editor is the very valuable browser you are looking for.

Happy Hacking.

OpenOffice_org 3.2 rc2 available for openSUSE

January 18th, 2010 by

I’m happy to announce OpenOffice.org 3.2 rc2 packages for openSUSE. They are available in the Build Service OpenOffice:org:UNSTABLE project and include many upstream and Go-oo fixes. See also overview of integrated features and enhancements. Please, look for more details about the openSUSE OOo build on the wiki page.

The packages are release candidates. Though, they have not passed the full QA test and might still include even serious bugs. Therefore they are not intended for data-critical usage. A good practice is to archive any important data before an use, …

As usual, we kindly ask any interested beta testers to try the package and report bugs. See also the list of known bugs.

Other information and plans:

There are already known blocker bugs, so we are going to produce rc3 . It should be available within one week. I hope that it will be the final one but …

LXDE: Mission (almost) Accomplished

January 15th, 2010 by

Sorry if i missed to inform you since September but i passed a very bad period, (including a breakage of my hand and with my ex-girlfriend), but now i’m definetly better, so here i am to inform you about some wonderful progress.

first of all:

LXDM has been released

exactly, LXDE Desktop Manager has been released and looks to be fully working 🙂

2nd) Upgrades, upgrades and more upgrades

several new package version has been released, including lxappereance, lxmusic, lxpanel and so on.

3rd)  We are going to fix a small not-portable issue due to X-KDE-SubstituteUID

check bugzilla #540627 for more informations, what you want to know any way, is that we fixed .desktop files to allow to run applications as root even outside GNOME or KDE

4th) Factory, factory, factory

LXDE is into openSUSE_Factory now! yes, that means lxde will be installable on 11.3 from OSS repo, and probably from DVD.  I actually submitted lxde pattern request and yast2 pattern icons are already into yast svn. So people.. PLEASE TEST AND REPORT!!

5th) OPENSUSE-LXDE MAILING LIST

yes people, we have a new opensuse-lxde mailing list now! Please subscribe to opensuse-lxde@opensuse.org for help, support and development… i’m waiting for you!!

6th) Not official support on openSUSE <= 11.1

That’s not my choice but it’s due to gtk changes, because of that X11:lxde will no more take care of failures on suse <= 11.1. new lxde packages requires gtk2 >= 2.16.0 and backport is impossible (see lxappereance for example).

I think that’s all, if not i’ll write a new blog post, but now i must go to my work or i’ll be fired!!

Regards

Andrea (your favourite openSUSE-LXDE admin!)

Tip: Using KWallet or GNOME Keyring with Subversion

January 15th, 2010 by

Subversion stores all its configuration and passwords under the ~/.subversion/ directory. Wouldn’t it be cool to have your passwords in KWallet or GNOME Keyring? Recently I found out, it is pretty simple.

(more…)

What a Cool App: screenie

January 14th, 2010 by

Sometimes you stumble over an application that is really cool and makes your day. Of course when you tell your colleagues everyone knows it – except you, well…

Today I had this nice experience with a little tool called screenie. It helps to arrange screenshots or images in general nicely such as this example where I made boring Hermes screenshots look nice: Hermes Screenshot Composition

It does it with a perfect simple interface on which you drop three images out of a file manager. A handful of options allow you to adjust the image to your needs and there you are – your little screenshot composition simply looks amazing, after a few moments of work. Great software.

Btw, iit’s only around 500 lines of code and a couple of resource files. Amazing, must be based on a quite powerful toolkit utilized by a real smart guy…

If you also want to look nice, no idea how, but for screenshots and stuff quickly install screenie from the KDE::Community repository.

Ah yes, I know, you know it already, of course 😉

Kraft Project Status

January 12th, 2010 by

I thought it might be nice after the holidays to tell about the status of the Kraft project, the KDE software for people operating a small business. Some nice things happened around it.
Kraft Logo

The best thing is that an additional developer works on Kraft: After my last status post Thomas Richard (account trichard) contacted me that he is interested, next days I had the first patch in my mailbox and from that point of time on he constantly contributed high quality changes into the Kraft repository.

His high energy, dedication and fresh ideas gave me a new motivation push after having worked on Kraft basically alone for more than four years. That’s great!

The last months we worked on porting Kraft to the KDE4 platform which is in a quite good shape in SVN already: Kraft compiles without warnings and without Q3 and K3 support classes and works stable again.

We couldn’t resist to make use of the new capabilities of KDE4 here and there and as a result we have a few small feature updates as well. The most interesting might be that the first KDE4 Kraft version will additionally support a sqlite database backend which eases setup and configuration for users tremendously.

Following our friends from the KMyMoney project we will come up with a first Kraft-on-KDE4 beta soon. Please stay tuned.

OpenOffice_org 3.2 rc1 available for openSUSE

December 23rd, 2009 by

I’m happy to announce OpenOffice.org 3.2 rc1 packages for openSUSE. They are available in the Build Service OpenOffice:org:UNSTABLE project and include many upstream and Go-oo fixes. See also overview of integrated features and enhancements. Please, look for more details about the openSUSE OOo build on the wiki page.

The packages are release candidates. Though, they have not passed the full QA test and might still include even serious bugs. Therefore they are not intended for data-critical usage. A good practice is to archive any important data before an use, …

As usual, we kindly ask any interested beta testers to try the package and report bugs. See also the list of known bugs.

Other information and plans:

There are already known blocker bugs, so we will need to produce rc2 . I expect that it will be available the second week in January. The final release should be available one week after the last working release candidate. I hope that rc2 will be the final one but …

The rc1 build is still in progress for SLED11 x86_64. I hope that it will be available later today but I can’t guarantee it.

Quick tip: Novell Bugzilla and Klipper

December 22nd, 2009 by

Klipper from KDE has a set of predefined actions triggered by content of the clipboard. So when you have it enabled, it show up the popup menu with all available browsers when you copy the URL. In my job I open many bugs and the bug numbers have the well defined format bnc#number. So why don’t define automatic action triggered by this regular expression?

Because Klipper expects only oneliner as an action, I wrote the short bash script obug.sh which expects one argument with a bugzilla string.

#!/bin/bash

[ -z "${1}" ] && {
  echo "bug number required"
  exit 1
}

regex='^(bnc|bug)?#[0-9]+$'
[[ "${1}" =~ ${regex} ]] || {
  echo "${1} did not match ${regex}"
  exit 2
}

firefox https://bugzilla.novell.com/show_bug.cgi?id=${1#*#}

It’s obvious how it works – it checks if the argument exists and if matches the pattern and then opens a firefox (it’d be a xdg-open, but I use firefox for Novell Bugzilla). There should be only one strange expression – ${1#*#}. It is a Shell Parameter Expansion. This expression removes all characters from the beginning of the string including first #, so it convert bnc#1234 to 1234.

Then I defined a new action in Klipper triggered by ^(bnc|bug)?#[0-9]+$, which calls obug.sh %s, where %s is the content of clipboard.
Klipper config

And after that all I selected the bnc#1234 by mouse and then the following popup appeared.

One disadvantage of this method is that Klipper opens popup window only near its status icon in systemtray. It would be more useful to show it near current mouse position.

OpenOffice_org 3.2 beta4 available for openSUSE

December 14th, 2009 by

I’m happy to announce OpenOffice.org 3.2 beta4 packages for openSUSE. They are available in the Build Service OpenOffice:org:UNSTABLE project and include many upstream and Go-oo fixes. See also overview of integrated features and enhancements. Please, look for more details about the openSUSE OOo build on the wiki page.

The package is a beta version and might include even serious bugs. Therefore they are not intended for data-critical usage. A good practice is to archive any important data before an use, …

As usual, we kindly ask any interested beta testers to try the package and report bugs. See also the list of known bugs.

Other information and plans:

First, I am sorry for the late beta4. It has already been available since Thursday but I forgot to announce it.

The next build should be available within one week. Hopefully, it will be the first release candidate. Unfortunately, there is not enough time for testing before Christmas, so we will decide the first week in January whether rc1 is final or whether we would need another build.

How to activate Flash Plugin for Google Chrome on openSUSE 11.2

December 9th, 2009 by

A couple of days ago, Google release a Beta version of Google Chrome for Mac and Linux. After installing the RPM I has been notice that the flash player doesn’t work. For make it work do the following as root:

cd /opt/google/chrome

ln -s /usr/lib/browser-plugins/ plugins

Restart Chrome and you are ready to watch some videos on youtube 🙂