Xfce

Subdomains
 

News from Xfce !

  • July 25, 2014
  • Skunnyk

Update 19/11/2014 : A new post is available !

Some news from Xfce, my favourite Desktop Environment, that I use since something like 2006.

The development is relatively slow (the last stable version, 4.10 was released in April 2012). There is not so many developers, 1 or 2 "core" devs, and less than 10 contributors (who are generally distributions maintainers, from debian, xubuntu, gentoo, arch, thanks to them !).

There was a roadmap for 4.12, where it was planned to release 4.12 mid-2013. But, hey, it's open source, it will be out when "it will be ready" :-).

Some weeks ago, it was decided to establish a list of "critical bugs" to be eradicated in order to release xfce 4.12.
You can find the list here : https://wiki.xfce.org/releng/4.12/roadmap/critical-bugs.
Xfce 4.12 will still use gtk2, with some support of gtk3 for better integration.
Port to gtk3 will maybe be done for the next version.

What will be new in xfce 4.12 ?

All major components are already available in development version (4.11), here are a small list of what to expect :

xfwm4 :

xfwm4-tabwin-4.12

xfce4-settings :

xfdesktop :

xfce4-panel :

And lot of works on other components, like xfce4-power-manager (systemd support), xfburn, xfce4-mixer etc There is still some works/tests to be done on upower or systemd support for example.

Update : You can see lot of screenshots of new features on the Xfce forum, by ToZ : https://forum.xfce.org/viewtopic.php?id=8945

Buildbot

A new buildbot based on jenkins is available since few days on http://buildbot.xfce.org

Bountysource

It's easier to copy the mail from Simon Steinbeiß to explain this part :

To get to the point: we see bountysource[2] as an easy way to offer
the community with a way to financially support Xfce. There are two
avenues a backer can choose from.
1) Set a bounty on a specific bug (we've pulled in all the reports for
many components already, so you can easily find them on
bountysource.com)
2) Back the Xfce team

Update: More explanations about bountysource: https://mail.xfce.org/pipermail/xfce4-dev/2014-July/030807.html

So if you are interested yo help Xfce, go to the contribute wiki page !

The bright future of Foresight Linux

  • April 1, 2014
  • Mark Trompell

Refining Foresight

Why

Foresight is what I use for almost a decade now (and that means almost the whole time since it was created by Ken Vandine).
It was originally based on rPath Linux and Foresight 2.0 still is.
So rpath doesn't exist anymore (it was aquired by SAS a while ago) and our existing base is getting outdated to a point where maintenance is getting a burden.

How

There were several options to solve this issue.
1) build foresight 3 from scratch
2) rebuild an existing distribution from source and use it as a base
3) base on an existing (vital) distribution

Which one

Actually we discussed all these, but given our manpower we chose to base our new shiny Foresight on Fedora as is, so that we can focus again on providing a stable modern rolling binary distribution.

The Plan and Progress

So what we're doing is importing all! of Fedora20 into our own repositories using a tool called mirrorball
It will create Sourcepackages for conary containing the matching rpms and srpms and build conary packages from them.
I'm not going into the details here. You can look some up on our foresight-devel mailinglist
The initial import and built is already done and we're now in the process of creating conary groups from the information of the comps.xml
when that is done it should be possible already to adopt a fresh install of fedora20 for use with conary packagemanager.
Next step will be doing regular updates and imports of the fedora20 repository.
Then we will build foresight on top of this.
Creating groups like we want them, adding artwork and extras. Import rpmfusion repositories until we have a foresight that matches our needs.
And of course finding a way to easily install foresight and convert existing fedora installations.

Why not...

...just use fedora?
Well first we all got to love foresight as a distribution and a community.
And we love conary. Conary is pretty strict when it comes to dependency resolution. We already found packaging issues of fedora20 just by importing and rebuilding it with conary. foresight is a rolling distribution and we hope that with the adopting of fedora we can make it possible to just roll from fedora20 to fedora21 painlessly. Conary has rollbacks since it's beginning and it's a great packagemanager that helped us maintaining a rolling binary distribution for almost 10 years now.


The bright future of Foresight Linux

  • April 1, 2014
  • Mark Trompell

Refining Foresight

Why

Foresight is what I use for almost a decade now (and that means almost the whole time since it was created by Ken Vandine).
It was originally based on rPath Linux and Foresight 2.0 still is.
So rpath doesn't exist anymore (it was aquired by SAS a while ago) and our existing base is getting outdated to a point where maintenance is getting a burden.

How

There were several options to solve this issue.
1) build foresight 3 from scratch
2) rebuild an existing distribution from source and use it as a base
3) base on an existing (vital) distribution

Which one

Actually we discussed all these, but given our manpower we chose to base our new shiny Foresight on Fedora as is, so that we can focus again on providing a stable modern rolling binary distribution.

The Plan and Progress

So what we're doing is importing all! of Fedora20 into our own repositories using a tool called mirrorball
It will create Sourcepackages for conary containing the matching rpms and srpms and build conary packages from them.
I'm not going into the details here. You can look some up on our foresight-devel mailinglist
The initial import and built is already done and we're now in the process of creating conary groups from the information of the comps.xml
when that is done it should be possible already to adopt a fresh install of fedora20 for use with conary packagemanager.
Next step will be doing regular updates and imports of the fedora20 repository.
Then we will build foresight on top of this.
Creating groups like we want them, adding artwork and extras. Import rpmfusion repositories until we have a foresight that matches our needs.
And of course finding a way to easily install foresight and convert existing fedora installations.

Why not...

...just use fedora?
Well first we all got to love foresight as a distribution and a community.
And we love conary. Conary is pretty strict when it comes to dependency resolution. We already found packaging issues of fedora20 just by importing and rebuilding it with conary. foresight is a rolling distribution and we hope that with the adopting of fedora we can make it possible to just roll from fedora20 to fedora21 painlessly. Conary has rollbacks since it's beginning and it's a great packagemanager that helped us maintaining a rolling binary distribution for almost 10 years now.


The bright future of Foresight Linux

  • April 1, 2014
  • Mark Trompell

Refining Foresight

Why

Foresight is what I use for almost a decade now (and that means almost the whole time since it was created by Ken Vandine).
It was originally based on rPath Linux and Foresight 2.0 still is.
So rpath doesn't exist anymore (it was aquired by SAS a while ago) and our existing base is getting outdated to a point where maintenance is getting a burden.

How

There were several options to solve this issue.
1) build foresight 3 from scratch
2) rebuild an existing distribution from source and use it as a base
3) base on an existing (vital) distribution

Which one

Actually we discussed all these, but given our manpower we chose to base our new shiny Foresight on Fedora as is, so that we can focus again on providing a stable modern rolling binary distribution.

The Plan and Progress

So what we're doing is importing all! of Fedora20 into our own repositories using a tool called mirrorball
It will create Sourcepackages for conary containing the matching rpms and srpms and build conary packages from them.
I'm not going into the details here. You can look some up on our foresight-devel mailinglist
The initial import and built is already done and we're now in the process of creating conary groups from the information of the comps.xml
when that is done it should be possible already to adopt a fresh install of fedora20 for use with conary packagemanager.
Next step will be doing regular updates and imports of the fedora20 repository.
Then we will build foresight on top of this.
Creating groups like we want them, adding artwork and extras. Import rpmfusion repositories until we have a foresight that matches our needs.
And of course finding a way to easily install foresight and convert existing fedora installations.

Why not...

...just use fedora?
Well first we all got to love foresight as a distribution and a community.
And we love conary. Conary is pretty strict when it comes to dependency resolution. We already found packaging issues of fedora20 just by importing and rebuilding it with conary. foresight is a rolling distribution and we hope that with the adopting of fedora we can make it possible to just roll from fedora20 to fedora21 painlessly. Conary has rollbacks since it's beginning and it's a great packagemanager that helped us maintaining a rolling binary distribution for almost 10 years now.


Remote notifications

  • January 5, 2014
  • Mike Massonnet
This post explains how to get notifications (libnotify) from a remote system. Typically this is useful with an IRC client accessible through SSH.

Prerequisites:
  • A notification daemon! (dunst, xfce4-notifyd, etc.)
  • socat
  • notify-send
apt-get install socat libnotify-bin

On the client, modify the SSH configuration to introduce two elements:
  • forward a TCP port,
  • execute a local command.

Example entry for ~/.ssh/config:
Host remote-host
Hostname remote-host.gandi.net
RemoteForward 12000 localhost:12000
PermitLocalCommand yes
LocalCommand socat -u tcp4-listen:12000,reuseaddr,fork,bind=127.0.0.1 exec:$HOME/.local/bin/notify-remote.sh 2>/dev/null &
The fowarded TCP port will be used to netcat notification messages to the local system.

socat is used to bind a port on the local system, it will take the notifcation messages, and write them to the executed shell script notify-remote.sh.

The shell script will then simply call notify-send to display a notification with the default notification daemon.

notify-remote.sh:
#!/bin/sh
delay="5000"

read line
summary="$line"
read line
msg="$line"
read line

if [ "$line" = "" ] && [ "$summary" != "" ]; then
[ -x "$(which notify-send)" ] && notify-send -u critical -t "$delay" -- "$summary" "$msg"
fi

Now it is possible to connect to the remote host and "write" notifications:
local$ ssh remote-host
remote-host$ echo -e 'SummarynBodynn' | nc 127.0.0.1 12000

Integrate into irssi


Copy the irssi script available bellow to get notifications from hilights, and private messages.

Once the script is copied, execute /script load rnotify.pl inside irssi.

~/.irssi/scripts/autorun/rnotify.pl:

# shamelessly copied from http://git.esaurito.net/?p=godog/bin.git;a=blob;f=rnotify.pl
use strict;
use Irssi;
use HTML::Entities;
use vars qw($VERSION %IRSSI);

$VERSION = "0.01";

%IRSSI = (
authors => 'Luke Macken, Paul W. Frields',
contact => 'lewk@csh.rit.edu, stickster@gmail.com',
name => 'rnotify',
description => 'Use libnotify to alert user to hilighted messages',
license => 'GNU General Public License',
url => 'http://lewk.org/log/code/irssi-notify',
);

Irssi::settings_add_str('misc', $IRSSI{'name'} . '_port', '12000');
Irssi::settings_add_bool('misc', $IRSSI{'name'} . '_if_away', 0);

sub is_port_owner {
my ($port, $uid) = @_;
my $wanted = sprintf("0100007F:%04X", $port);

# XXX linux-specific
open HANDLE, "< /proc/net/tcp" || return 0;
while(<HANDLE>){
# sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode
my @splitted = split /s+/;
my $local = $splitted[2];
my $remote = $splitted[3];
my $uid = $splitted[8];

return 1 if $local eq $wanted and $uid == $<;
}
close HANDLE;
return 0;
}

sub notify {
my ($server, $summary, $message) = @_;

$message = HTML::Entities::encode($message);
$summary = HTML::Entities::encode($summary);

# echo escaping
$message =~ s/\/\\/g;
$summary =~ s/\/\\/g;

my $port = Irssi::settings_get_str($IRSSI{'name'} . '_port');

return if ! is_port_owner($port, $<);

# check for being away in every server?
return if $server->{usermode_away} &&
(Irssi::settings_get_bool($IRSSI{'name'} . '_if_away') == 0);

# XXX test for other means of doing TCP
#print("echo '$summaryn$messagenn' | /bin/nc 127.0.0.1 $port");
system("echo '$summaryn$messagenn' | /bin/nc 127.0.0.1 $port &");

#my $pid = open(FH, "|-");
#if( $pid ){
# print FH "$summaryn$messagenn";
# close(FH) || warn "exited $?";
#}else{
# exec("/bin/nc 127.0.0.1 $port") || warn "can't exec $!";
#}
}

sub print_text_notify {
my ($dest, $text, $stripped) = @_;
my $server = $dest->{server};

return if (!$server || !($dest->{level} & MSGLEVEL_HILIGHT));
my $sender = $stripped;
$sender =~ s/^<.([^>]+)>.+/1/ ;
$stripped =~ s/^<.[^>]+>.// ;
my $summary = "Message on $dest->{target}";
notify($server, $summary, $stripped);
}

sub message_private_notify {
my ($server, $msg, $nick, $address) = @_;

return if (!$server);
notify($server, "Private message from ".$nick, $msg);
}

sub dcc_request_notify {
my ($dcc, $sendaddr) = @_;
my $server = $dcc->{server};

return if (!$dcc);
notify($server, "DCC ".$dcc->{type}." request", $dcc->{nick});
}

Irssi::signal_add('print text', 'print_text_notify');
Irssi::signal_add('message private', 'message_private_notify');
Irssi::signal_add('dcc request', 'dcc_request_notify');

# vim: et

Remote notifications

  • January 5, 2014
  • Mike Massonnet
This post explains how to get notifications (libnotify) from a remote system. Typically this is useful with an IRC client accessible through SSH.

Prerequisites:
  • A notification daemon! (dunst, xfce4-notifyd, etc.)
  • socat
  • notify-send
apt-get install socat libnotify-bin

On the client, modify the SSH configuration to introduce two elements:
  • forward a TCP port,
  • execute a local command.

Example entry for ~/.ssh/config:
Host remote-host
Hostname remote-host.gandi.net
RemoteForward 12000 localhost:12000
PermitLocalCommand yes
LocalCommand socat -u tcp4-listen:12000,reuseaddr,fork,bind=127.0.0.1 exec:$HOME/.local/bin/notify-remote.sh 2>/dev/null &
The fowarded TCP port will be used to netcat notification messages to the local system.

socat is used to bind a port on the local system, it will take the notifcation messages, and write them to the executed shell script notify-remote.sh.

The shell script will then simply call notify-send to display a notification with the default notification daemon.

notify-remote.sh:
#!/bin/sh
delay="5000"

read line
summary="$line"
read line
msg="$line"
read line

if [ "$line" = "" ] && [ "$summary" != "" ]; then
[ -x "$(which notify-send)" ] && notify-send -u critical -t "$delay" -- "$summary" "$msg"
fi

Now it is possible to connect to the remote host and "write" notifications:
local$ ssh remote-host
remote-host$ echo -e 'Summary\nBody\n\n' | nc 127.0.0.1 12000

Integrate into irssi


Copy the irssi script available bellow to get notifications from hilights, and private messages.

Once the script is copied, execute /script load rnotify.pl inside irssi.

~/.irssi/scripts/autorun/rnotify.pl:

# shamelessly copied from http://git.esaurito.net/?p=godog/bin.git;a=blob;f=rnotify.pl
use strict;
use Irssi;
use HTML::Entities;
use vars qw($VERSION %IRSSI);

$VERSION = "0.01";

%IRSSI = (
authors => 'Luke Macken, Paul W. Frields',
contact => 'lewk@csh.rit.edu, stickster@gmail.com',
name => 'rnotify',
description => 'Use libnotify to alert user to hilighted messages',
license => 'GNU General Public License',
url => 'http://lewk.org/log/code/irssi-notify',
);

Irssi::settings_add_str('misc', $IRSSI{'name'} . '_port', '12000');
Irssi::settings_add_bool('misc', $IRSSI{'name'} . '_if_away', 0);

sub is_port_owner {
my ($port, $uid) = @_;
my $wanted = sprintf("0100007F:%04X", $port);

# XXX linux-specific
open HANDLE, "< /proc/net/tcp" || return 0;
while(<HANDLE>){
# sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode
my @splitted = split /\s+/;
my $local = $splitted[2];
my $remote = $splitted[3];
my $uid = $splitted[8];

return 1 if $local eq $wanted and $uid == $<;
}
close HANDLE;
return 0;
}

sub notify {
my ($server, $summary, $message) = @_;

$message = HTML::Entities::encode($message);
$summary = HTML::Entities::encode($summary);

# echo \ escaping
$message =~ s/\\/\\\\/g;
$summary =~ s/\\/\\\\/g;

my $port = Irssi::settings_get_str($IRSSI{'name'} . '_port');

return if ! is_port_owner($port, $<);

# check for being away in every server?
return if $server->{usermode_away} &&
(Irssi::settings_get_bool($IRSSI{'name'} . '_if_away') == 0);

# XXX test for other means of doing TCP
#print("echo '$summary\n$message\n\n' | /bin/nc 127.0.0.1 $port");
system("echo '$summary\n$message\n\n' | /bin/nc 127.0.0.1 $port &");

#my $pid = open(FH, "|-");
#if( $pid ){
# print FH "$summary\n$message\n\n";
# close(FH) || warn "exited $?";
#}else{
# exec("/bin/nc 127.0.0.1 $port") || warn "can't exec $!";
#}
}

sub print_text_notify {
my ($dest, $text, $stripped) = @_;
my $server = $dest->{server};

return if (!$server || !($dest->{level} & MSGLEVEL_HILIGHT));
my $sender = $stripped;
$sender =~ s/^\<.([^\>]+)\>.+/\1/ ;
$stripped =~ s/^\<.[^\>]+\>.// ;
my $summary = "Message on $dest->{target}";
notify($server, $summary, $stripped);
}

sub message_private_notify {
my ($server, $msg, $nick, $address) = @_;

return if (!$server);
notify($server, "Private message from ".$nick, $msg);
}

sub dcc_request_notify {
my ($dcc, $sendaddr) = @_;
my $server = $dcc->{server};

return if (!$dcc);
notify($server, "DCC ".$dcc->{type}." request", $dcc->{nick});
}

Irssi::signal_add('print text', 'print_text_notify');
Irssi::signal_add('message private', 'message_private_notify');
Irssi::signal_add('dcc request', 'dcc_request_notify');

# vim: et

Relaunch

  • December 25, 2013
  • Brian Tarricone

I finally decided to redo my website, and ditch WordPress in favor of a static site generator (I decided to use Jekyll). I also took the opportunity to simplify the design.

There’s a bit more to do, and likely some broken links here and there (not to mention some broken WP-to-markdown conversion), but it’s time I finally got this done.

In theory, I’ll start blogging again as well, but… we’ll see.

Relaunch

  • December 25, 2013
  • Brian Tarricone

I finally decided to redo my website, and ditch WordPress in favor of a static site generator (I decided to use Jekyll). I also took the opportunity to simplify the design.

There's a bit more to do, and likely some broken links here and there (not to mention some broken WP-to-markdown conversion), but it's time I finally got this done.

In theory, I'll start blogging again as well, but... we'll see.

Xfce – Xfwm4 zoom mode in 4.12

  • December 10, 2013
  • Skunnyk

Xfce is my main desktop environment since more than 6 years, and I really like it. I try to make some patch from time to time, and if you search a project to contribute, it’s here ;-)

The core team is really small (2 or 3 people), so development evolves rather slowly, and the 4.12 will be released when it is ready.

One of the latest feature is the implementation of a compositor zoom, like the compiz ezoom plugin, from an external developper ( see this thread).

Here a little video with latest git version ( from http://git.xfce.org/xfce/xfwm4/ ). You just need to press ALT and scroll up/down to zoom in/out.

(yeah, it’s an excuse to test the html5 <video> balise with ogv file ;)).

I will try to make some blog posts about new features in xfce world for the upcoming 4.12 (in 2014 I hope!), stay tuned !

Xfce – Xfwm4 zoom mode in 4.12

  • December 10, 2013
  • Skunnyk

Xfce is my main desktop environment since more than 6 years, and I really like it. I try to make some patch from time to time, and if you search a project to contribute, it’s here ;-)

The core team is really small (2 or 3 people), so development evolves rather slowly, and the 4.12 will be released when it is ready.

One of the latest feature is the implementation of a compositor zoom, like the compiz ezoom plugin, from an external developper ( see this thread).

Here a little video with latest git version ( from http://git.xfce.org/xfce/xfwm4/ ). You just need to press ALT and scroll up/down to zoom in/out.

(yeah, it’s an excuse to test the html5 <video> balise with ogv file ;)).

I will try to make some blog posts about new features in xfce world for the upcoming 4.12 (in 2014 I hope!), stay tuned !