Tag Archive : desktop

/ desktop

In modern operating system, user interfaces tends goes to graphical system. We see window, we see button, we see cursor, etc. In UNIX, the graphical component is managed by independent subsystem. Here we hear two concepts: Desktop Environment and Window Manager. However, still some people confuse about which is which and which is best to use. The former question is fairly simple to answer. However the latter question is a bit more complex due to specific user want.

The Layering System

UNIX use layering system for its graphical desktop. Mostly the system comprised of following (from the base to the top):

  • The Foundation – A system that allows graphic element to be drawn on the display. This system builds the primitive framework that allows system to paint something to various screen (display), interacts with keyboard and mouse, etc. This is required for any graphical desktop. On most UNIX system, X Windows is used. There is also an alternative for X Windows, Wayland, which is still in active development.
  • Window Manager – The Window Manager is the piece of the puzzle that controls the placement and appearance of windows. Window Managers include: Enlightenment, Afterstep, FVWM, Fluxbox, IceWM, etc. This layer needs the foundation (X Windows) but not Desktop Environment.
  • Desktop Environment – This is where it begins to get a little fuzzy for some. A Desktop Environment includes a Window Manager but builds upon it. The Desktop Environment typically is a far more fully integrated system than a Window Manager. Requires both X Windows (Foundation) and a Window Manager. Examples: GNOME, KDE

So, a Desktop Environment generally includes a suite of application that are tightly integrated so that all applications are aware of one another. It is basically rides on top of a Window Manager and adds many features, including panels, status bars, drag-and-drop capabilities, and a suite of integrated applications and tools. Most user opinions on operating systems are typically based on Desktop Environment.

As implied by the name, Window Manager manages windows. Window Manager allows the windows to be opened, closed, resized, and moved. t is also capable of presenting menus and options to the user. It controls the look and feel of the user’s GUI.

The Type of Window Managers

Window managers are often divided into three or more classes, which describe how windows are drawn and updated.

Compositing Window Managers

Compositing window managers let all windows be created and drawn separately and then put together and displayed in various 2D and 3D environments. The most advanced compositing window managers allow for a great deal of variety in interface look and feel, and for the presence of advanced 2D and 3D visual effects.Example:

  1. Compiz
  2. KWin
  3. Xfwm
  4. Enlightenment (E17)
  5. Mutter.

Stacking Window Managers

All window managers that have overlapping windows and are not compositing window managers are stacking window managers, although it is possible that not all use the same methods. Stacking window managers allow windows to overlap by drawing background windows first, which is referred to as painter’s algorithm. Changes sometimes require that all windows be re-stacked or repainted, which usually involves redrawing every window. However, to bring a background window to the front usually only requires that one window be redrawn, since background windows may have bits of other windows painted over them, effectively erasing the areas that are covered.

Examples:

  1. AfterStep
  2. Blackbox
  3. Fluxbox
  4. FLWM
  5. sawfish
  6. Window Maker
  7. WindowLab

Tiling Window Manager

Tiling window managers paint all windows on-screen by placing them side by side or above and below each other, so that no window ever covers another.

Examples:

  1. wmii
  2. xmonad

Dynamic Window Manager

Dynamic window managers can dynamically switch between tiling or floating window layout. It is a tiling window manager where windows are tiled based on preset layouts between which the user can switch. Layouts typically have a master area and a slave area. The master area usually shows one window, but one can also change the amount of windows in this area. The point of it is to reserve more space for the more important window(s). The slave area shows the other windows.

Examples:

  1. fvwm
  2. xmonad

So Which One Suit Me?

Again, it is a tough question. Your choice might be affected by many factors: your need, your taste, your mood, etc. Unless you want to explore deep, you might consider default Desktop Environment and default Window Manager provided.

There are some ways for accessing Raspberry Pi: access Pi directly or indirectly. You might at least try one of thus method for connecting your Pi to your PC.

The direct access involving access without any medium. You connect screen (LCD screen, for example), keyboards, mice, etc to your Pi. This way, your Raspberry Pi act as normal computer. You operate it like you operate your PC. This method has a drawback, whenever you want to use Pi you must provide appropriate input and output device (keyboard, mouse, screen).

Another way to access Pi is using indirect access. This method involving other medium to access Pi, technically a network. In this term, your Pi is connect to a network and you can access the Pi over the network. SSH and VNC are the good example of this. This method demand us to provide good network connection if you want a good connection.

Accessing Pi over network is good, you don’t need other peripheral / device such as keyboard, mouse, or LCD screen. If you want to do thing graphically you can use VNC (Virtual Network Computing). However, using VNC is somehow slow because the application and desktop environment are rendered both on your Pi and your desktop. VNC also require better network as it sends picture / screen image over time.

There is a better solution for this problem. Instead of rendering the graphic on Pi, why don’t we render it on our local computer? This way, Pi only send us minimal packet. Using this method, we can also use keyboard and mouse on our local computer, just like indirect access do.

In this article we will discuss about other way to remote accessing your desktop without VNC. If in other article we use X.org server on Linux & Unix, on this article we still use X but in cygwin environment. For this article I use:

  1. Windows 8 on PC
  2. cygwin64
  3. Raspbian Wheezy on Raspberry Pi

Alternatively, you can use cygwin for 32-bit. However as my Windows 8 is 64-bit I will stick to it.

X Window System – Server & Client Architecture

X Window is originated at the Massachussetts Institute of Technology (MIT) In 1984. X11 is the system-level software infrastructure for the windowing GUI on Linux, *BSD, and other UNIX-like Operating System. It is designed to handle both local display, as well as across the network displays. X Window is a computer software system and network protocol that provides a basis for graphical user interfaces (GUIs) and rich input device capability for networked computers. It creates a hardware abstraction layer where software is written to use a generalized set of commands, allowing for device independence and reuse of programs on any computer that implements X.

X was designed from the beginning to be network-centric. It adopts a “client-server” model.

In the X model, the “X server” runs on the computer that has the keyboard, monitor, and mouse attached. The server’s responsibility includes tasks such as managing the display, handling input from the keyboard and mouse, and other input or output devices (i.e., a “tablet” can be used as an input device, and a video projector may be an alternative output device). Each X application (such as XTerm or Firefox) is a “client”. A client sends messages to the server such as “Please draw a window at these coordinates”, and the server sends back messages such as “The user just clicked on the OK button”.

In a home or small office environment, the X server and the X clients commonly run on the same computer. However, it is perfectly possible to run the X server on a less powerful desktop computer, and run X applications (the clients) on, say, the powerful and expensive machine that serves the office. In this scenario the communication between the X client and server takes place over the network.

This confuses some people, because the X terminology is exactly backward to what they expect. They expect the “X server” to be the big powerful machine down the hall, and the “X client” to be the machine on their desk.

It is important to remember that the X server is the machine with the monitor and keyboard, and the X clients are the programs that display the windows.

Preparations

As stated before, the X window is using client/server model. Our communication would be on top of secure connection. Specifically, SSH (Secure SHell) connection are chosen to transport data (as a tunneling). Therefore, we should configure SSH server properly.

Now on your Raspberry Pi, configure SSH server. Obviously, you MUST install your SSH server program. Edit following file /etc/ssh/ssh_config, make sure these lines are not commented.

ForwardAgent yes
ForwardX11 yes
ForwardX11Trusted yes

Now open /etc/ssh/sshd_config and edit the file so it has following line:

X11Forwarding yes

Restart the SSH Server.

On our host, make sure X11 is installed on cygwin. We won’t cover how we installed cygwin or X11.

Remote Display

Open up cygwin terminal. We need an X server. At default, cygwin will not running X at startup.

We want to create a server on our local machine. This X server will manage our local screen output as well as other X client (Raspberry Pi in this case). To initiate a server, do following (assuming we use default display :0):

export DISPLAY=:0
xinit -- $DISPLAY

A new window should appear with a black blank screen. You would see a new terminal there.

Now connect to Raspberry Pi using SSH.

ssh -X [email protected]_ip_address

user is the username we will use and the raspberry_ip_address is the Pi’s IP address. Make sure you can access and you can login to Pi.

Once you are logged in, execute this to start the X.

lxsession &
lxpanel &

Now, your window should be drawn to your Raspbian’s LXDE.

Because X on cygwin implementation is a window, you can view both your desktop and remote desktop at same time.

Remote Access Raspberry Pi Using Only X Client

December 9, 2015 | Article | No Comments

There are some ways for accessing Raspberry Pi: access Pi directly or indirectly. You might at least try one of thus method for connecting your Pi to your PC.

The direct access involving access without any medium. You connect screen (LCD screen, for example), keyboards, mice, etc to your Pi. This way, your Raspberry Pi act as normal computer. You operate it like you operate your PC. This method has a drawback, whenever you want to use Pi you must provide appropriate input and output device (keyboard, mouse, screen).

Another way to access Pi is using indirect access. This method involving other medium to access Pi, technically a network. In this term, your Pi is connect to a network and you can access the Pi over the network. SSH and VNC are the good example of this. This method demand us to provide good network connection if you want a good connection.

Accessing Pi over network is good, you don’t need other peripheral / device such as keyboard, mouse, or LCD screen. If you want to do thing graphically you can use VNC (Virtual Network Computing). However, using VNC is somehow slow because the application and desktop environment are rendered both on your Pi and your desktop. VNC also require better network as it sends picture / screen image over time.

There is a better solution for this problem. Instead of rendering the graphic on Pi, why don’t we render it on our local computer? This way, Pi only send us minimal packet. Using this method, we can also use keyboard and mouse on our local computer, just like indirect access do.

In this article we will discuss about other way to remote accessing your desktop without VNC. We will use X.org which is used for Linux & Unix OS for GUI. For this article I use:

  1. Slackware64 14.0 on PC
  2. Raspbian Wheezy on Raspberry Pi

This article is written for Linux. If you use Windows, go here.

X Window System – Server & Client Architecture

X Window is originated at the Massachussetts Institute of Technology (MIT) In 1984. X11 is the system-level software infrastructure for the windowing GUI on Linux, *BSD, and other UNIX-like Operating System. It is designed to handle both local display, as well as across the network displays. X Window is a computer software system and network protocol that provides a basis for graphical user interfaces (GUIs) and rich input device capability for networked computers. It creates a hardware abstraction layer where software is written to use a generalized set of commands, allowing for device independence and reuse of programs on any computer that implements X.

X was designed from the beginning to be network-centric. It adopts a “client-server” model.

In the X model, the “X server” runs on the computer that has the keyboard, monitor, and mouse attached. The server’s responsibility includes tasks such as managing the display, handling input from the keyboard and mouse, and other input or output devices (i.e., a “tablet” can be used as an input device, and a video projector may be an alternative output device). Each X application (such as XTerm or Firefox) is a “client”. A client sends messages to the server such as “Please draw a window at these coordinates”, and the server sends back messages such as “The user just clicked on the OK button”.

In a home or small office environment, the X server and the X clients commonly run on the same computer. However, it is perfectly possible to run the X server on a less powerful desktop computer, and run X applications (the clients) on, say, the powerful and expensive machine that serves the office. In this scenario the communication between the X client and server takes place over the network.

This confuses some people, because the X terminology is exactly backward to what they expect. They expect the “X server” to be the big powerful machine down the hall, and the “X client” to be the machine on their desk.

It is important to remember that the X server is the machine with the monitor and keyboard, and the X clients are the programs that display the windows.

Preparations

As stated before, the X window is using client/server model. Our communication would be on top of secure connection. Specifically, SSH (Secure SHell) connection are chosen to transport data (as a tunneling). Therefore, we should configure SSH server properly.

Now on your Raspberry Pi, configure SSH server. Obviously, you MUST install your SSH server program. Edit following file /etc/ssh/ssh_config, make sure these lines are not commented.

ForwardAgent yes
ForwardX11 yes
ForwardX11Trusted yes

Now open /etc/ssh/sshd_config and edit the file so it has following line:

X11Forwarding yes

Restart the SSH Server.

Remote Display

Running X on your local machine, you should have more than 1 tty (teletype). Go to tty 1 (or any from 2 to 6) and you would see a black screen with login message there. Login with your account.

Next we need to make an X server. This server is another X server running on our local machine. This X server will manage our local screen output. We use this server to display anything from our X client, which is raspberry pi.

export DISPLAY=:1

Now, the easiest way is to do is running X on display :1.

X :1 &; xterm

You should be brought to new tty with a blank screen and a “window” there.

Now connect to Raspberry Pi using SSH.

ssh -X [email protected]_ip_address

user is the username we will use and the raspberry_ip_address is the Pi’s IP address. Make sure you can access and you can login to Pi.

Once you are logged in, execute this to start the X.

lxsession &
lxpanel &

Now, your tty should be drawn to your Raspbian’s LXDE.

When you want to back to your original desktop, press CTRL+ALT+F7. When you want to back to Pi’s desktop, press CTRL+ALT+F8.

Drawbacks

This method require more resource on local computer as your local computer run 2 X Server at same time.

You should also note that you can only do swap display to change between these two display. Using VNC, you can display the content of Pi display as a window.

KDE or K Desktop Environment has released their latest version, version 4.9.5, on 1 January 2013. This article will discuss about how to upgrade KDE to 4.95 on Slackware. In this article I use Slackware64 version 14.0. But you can also use Slackware 32 bit to do it.

First of all, copy this article to a text. To upgrade KDE make sure you don’t run X and KDE. You can exit GUI by switch to tty1 (press <CTRL> + <ALT> + <F1>), login with root and invoke this command:

telinit 3

Next we will downloads the required packages on official site. It is more recommended to download from mirror server you know. But at this point we will use the official site as our reference. Now issue this command:

rsync -av rsync://alien.slackbook.org/alien/ktown/14.0/4.9.5 .

The above command will download the whole 4.9.5 directory excluding sources directory into current directory. Beware, pay attention for last “.” (dot) as it is also part of command.

After finish synchronizing, make sure you have minimal three folders: deps, x86, x86_64 under 4.9.5. If you only want to download only 64 bit version, do this instead of last command:

rsync -av --exclude=x86 rsync://alien.slackbook.org/alien/ktown/14.0/4.9.5 .

If you want to download 32 version only, do this:

rsync -av --exclude=x86_64 rsync://alien.slackbook.org/alien/ktown/14.0/4.9.5 .

Now enter directory 4.9.5. Within that directory do these command:

upgradepkg --reinstall --install-new x86_64/deps/*.t?z
upgradepkg --reinstall --install-new x86_64/kde/*.t?z
removepkg kdemultimedia
removepkg ksecrets

If you install 32 bit version, do this instead:

upgradepkg --reinstall --install-new x86/deps/*.t?z
upgradepkg --reinstall --install-new x86/kde/*.t?z
removepkg kdemultimedia
removepkg ksecrets

At this point you are officially has upgrade your KDE to 4.9.5. But if you already have one or more non-english language packs installed, you have to install it to. For you who use 32-bit, you can also do this command:

upgradepkg x86_64/kdei/*.t?z

If you don’t have any but want to install it, you can do this command and substitute XX with language pack you want to install:

upgradepkg --install-new x86_64/kdei/kde-l10n-XX-*.t?z

If you want to know what language packs supported, you can browse the directory by:

ls x86_64/kdei/

Now reboot your system and check to make sure you have install 4.9.5. You can do it by:

kded4-config -v

Did you see 4.9.5 there? 😀

Installing Conky on Slackware64

December 5, 2015 | Article | No Comments

What is conky?

Conky is a light-weight system monitor for X that display any information to desktop. Maybe you who has familiar with Windows OS will find it similar to Conky.

In this article we will use following:

  1. Slackware64 14.0 (any 64 bit version is OK)
  2. scons
  3. lua
  4. imlib2
  5. tolua++
  6. conky

The packages (2) to (6) can be found on slackbuild website. In this article we assume you are know how to install package with slackbuild, otherwise you can search for it.

Now build the packages and install with following order:

And you now have conky installed on your machine 😀
But wait, the conky has started but it draws black background, what’s up? Calm down, there is an explanation for that. Remember that Slackware64 use KDE.

  1. Conky uses pseudo-transparency instead of ACTUAL transparency. It means Conky peeks at the root desktop and draws it as the background of the Conky window.
  2. KDE doesn’t draw wallpaper to the root window, only to the plasma desktop. Plasma desktop is the lowest window on top of the root window. Thus the root window is empty and now you know why Conky appear as black background.

There is an approach to overcome this: draw the background used by plasma desktop to root window. To do so, we need to install additional package: feh. Now go to slackbuild site again, download and install following packages in order:

  1. giblib
  2. feh

Assuming you use a script for autostart at booting, modify your script and gives a delay before conky start (using sleep). Fifteen seconds is a good one. After use sleep, we will draw a background before conky start so call feh before conky. Here is the script I use:

#! /bin/sh

function do_start() {
  if [ `pgrep conky | wc -l` -ge 2 ]; then
    echo "OctoEngine has been activated before. Quitting..."
    return;
  fi

  if [ `grep 'wallpaper=' ~/.kde/share/config/plasma-desktop-appletsrc | wc -l` -gt 1 ]; then
    WP=`grep 'wallpaper=' ~/.kde/share/config/plasma-desktop-appletsrc | sed -n 2p | tail --bytes=+11`
  else
    WP=`grep 'wallpaper=' ~/.kde/share/config/plasma-desktop-appletsrc | tail --bytes=+11`
  fi
  feh --bg-scale $WP
  sleep 15
  conky -d -c /opt/conky/config/left_panel
  conky -d -c /opt/conky/config/right_panel
  sleep 1 && transset-df .5 -n Conky
}

case $1 in
  "start")
    do_start
    ;;
  "restart")
    killall conky
    do_start
    ;;
  "stop")
    killall conky
    ;;
esac

if [ $# -ne 1 ]; then
  do_start
fi

 

On that script, I use two conky: left_panel and right_panel which located at /opt/conky/config. Everything I need to run conky is defined on do_start() function. I must make sure that only one of each must be run, no multiple instance, so I check whether conky has been running before (indicated by “`pgrep conky | wc -l` -ge 2” command)

In this scenario, we use wallpaper used by plasma desktop and draw it into root window. To accomplish that, we need to peek at ~/.kde/share/config/plasma-desktop-appletsrc, parse it to get the correct filename, and execute feh. Mostly I’m using multiple display screen and the plasma-desktop-appletsrc will return more than one line thus supply incorrect value for feh. Therefore I modify it so it can adapt to my situation.

Using this script is so simple, use it just like any autostart script. If you want to stop conky manually you can invoke script_name stop. Starting conky manually can be done with script_name start.

Social media & sharing icons powered by UltimatelySocial