Much ado about scripting, Linux & Eclipse: card subject to change

Showing posts with label kde. Show all posts
Showing posts with label kde. Show all posts

2011-11-09

HOWTO: Make KDE remember dual-monitor randr settings

Every time I boot up, KDE appears to forget that I want my monitors to be positioned left-to-right and instead defaults to mirrored config. But, after a lot of cursing and a little googling, I found an answer so it'll no so much keep your settings, but reset its broken config to your settings.

1. Hit ALT-F2, then enter "display" to run the Display Settings app.

2. Configure your settings as you'd like. Note that if the Apply button isn't active after your changes, you can change/revert something like a Position: button to make it active.

3. On restart, KDE may forget your dual-monitor settings. So, to prevent this, go look in your ~/.kde/share/config/krandrrc file:

[Display]
ApplyOnStartup=true
StartupCommands=xrandr --output "DVI-I-1" --pos 1920x0 --mode 1920x1200 --refresh 59.9502\nxrandr --output "HDMI-1" --pos 0x130 --mode 1920x1080 --refresh 60\nxrandr --noprimary

4. Copy the configuration into a new file, and replace \n with newlines. I like to put scripts like this in /etc/X11 because they relate to screen res and positioning.

# from ~/.kde/share/config/krandrrc
xrandr --output "DVI-I-1" --pos 1920x0 --mode 1920x1200 --refresh 59.9502 
xrandr --output "HDMI-1" --pos 0x130 --mode 1920x1080 --refresh 60 
xrandr --noprimary

5. Ensure the script is readable/executable for all users:

chmod 755 /etc/X11/1920x2.sh

6. Hit ALT-F2, then enter "autostart" to run the Autostart config tool.

7. Click Add script... and browse for the script you created above.

8. Reboot and watch the magic unfold.

2011-09-01

HOWTO: Move around between desktops & windows with keyboard or mouse

Recently installed Fedora 15 KDE spin, partly because the XFCE spins wouldn't boot from CD but also because I've heard less-than-favourable things about Gnome3 and because I'm addicted to Konqueror as a graphical sftp/scp/ssh viewer, so figured might as well use kdm instead of xfwm4 or gdm.

Still having some problems getting my 1600x1200 (or 1920x1200) monitor to do anything more than 1024x768 on the VGA port of the video card (works fine on the DisplayPort connector, either directly or via a DP-to-DVI cable, but not on the VGA connector, even with xorg.conf hackery). That said the options for display/monitor management under KDE are much better than under XFCE, and this is the first time I've been able to get two monitors working without HOURS of hacking away at xorg.conf scripts. So... big props for this release *almost* Just Working.

Workaround I'm trying next is to install a second video card. Will update when/if that solves the problem once it arrives.

But video resolution aside, I did recently figure out how to set keyboard bindings for moving windows between desktops (thanks to David Fisco). From the K-menu, select System Settings > Shortcuts and Gestures > Global Keyboard Shortcuts > KDE Component: KWin > "Window One Desktop To The Left/Right":

... and for switching between desktops ("Switch To Next/Previous Desktop")

Also recently discovered some fun options for switching between windows (on all desktops). From the K-menu, select System Settings > Desktop Effects > Enable desktop effects > Effect for window switching: Present Windows (or any of the other options).

There's also System Settings > Window Behavior > Task Switcher > Effect: Present Windows:

You might want to set an animation for switching between desktops, though I find with multiple monitors this can be a bit dizzying. From the K-menu, select System Settings > Workspace Behavior > Virtual Desktops > Switching > Animation: Desktop Cube Animation. For something more subtle, try "Fade Desktop".

Finally, you may want to set screen edge behaviours, such as making Present Windows appear when you cursor to the top-center of your screen. System Settings > Workspace Behavior > Screen Edges > right-click a target zone:

2009-01-25

Capturing Screenshots Made Easy: Scripting With xfce4-screenshooter

Since moving to Fedora 10 and casting off my old ties to Kubuntu, I've been rather frustrated with the available options for capturing screenshots under Gnome.

I've tried the gnome-screenshot tool, docked as a panel applet, but it only allows me to capture the desktop or selected window. No click-and-drag region select?

When I've needed to capture only a part of my screen or overlapping windows (eg., Eclipse dialogs) I've been forced to capture the whole screen then crop it down w/ GIMP. Or, launch GIMP first and let it do the region capture - but GIMP never remembers my settings from last time, so to capture a region after a 2-second delay, it's 8 clicks every time I start GIMP. Lame.

In both cases, it's cumbersome, and I always have to select the directory where I want to save, and then name the file.

This weekend, I discovered xfce4-screenshooter, which is significantly better in that I can capture an area of the screen and auto-save to a file without needing to specify a filename each time.

It can even redirect the capture to an application or the clipboard rather than a file, and provides all the dialog options as commandline flags so it can be scripted, too.

So, now, I simply wrap that application with a bash script that runs the screenshooter then opens my snapshot folder with Thunar, so I can preview the result with Ristretto or edit it with GIMP if necessary. One click to start the process, one click-and-drag to create the image. And no unnecessary dialog configuration, file system browsing, or clicking!

Here's the scriptlet, which I've set up as a Gnome panel shortcut to run /home/nboldt/bin/snap.sh:

#!/bin/bash
/usr/bin/xfce4-screenshooter -s /home/nboldt/Screenshots/ -h -r && \
  thunar /home/nboldt/Screenshots/ &

And here's my desktop, captured with only 2 clicks:

One might argue that it's too bad that these three tools can't just be merged into one. I'd argue that it's great that if you don't like one tool, you can find two others, each incrementally better than the next. Screenshot integration in GIMP is very handy, as is automatic capture to file (with incremental file naming). And, unlike in the Windows and Mac worlds, if the best tool for the job isn't available for one window system, I can simply cherry pick from another.

Still, nothing beats the feature set and usability of HyperSnap, but that's sadly a closed-source Windows application, and far from free. Proving that in this world, ultimately, you get what you pay for -- but there are some excellent free & open source alternatives.

2008-10-16

Password management with ccrypt

Intro
Server
Client(s)
About ccrypt

For the past few years, the list of passwords I use for all the various websites, servers, and applications has been growing ever longer. Some people limit themselves to 3-4 passwords, or a handful of formulas for password generation. I used to do that, but it's insecure, and when you control the fate of numerous servers, it's irresponsible. These day, I generally create new passwords at random, and replace them every 3-4 months.

Every flavour of linux has its own system for managing passwords; for example, KDE has KWallet; Gnome has Keyring. Tuesday I started playing with Fedora for the first time in years, and discovered yet another way: System > Preferences > System > Authorizations (polkit-gnome-authorization). And, of course, even Mozilla (Firefox, Thunderbird) handles password management like this... but each application has its own repository, and each one will get out of sync in time.

So, for a password management system that doesn't care about window manager, application, or even OS (this works with under cygwin on Windows, too), I've designed my own method.

How do you remember 100s of passwords which have nothing in common? Store them in a database, encrypted by a passphrase/password, then use a simple query engine to retrieve them.

Here's how it works, and how you can set up something similar.

Home Server / CVS Server

First, define these 3 scripts.

  1. /home/user/passwds/PWget.sh
  2. #!/bin/bash
    dir=/home/user/passwds;
    mkdir -p $dir;
    echo -n "Retrieve latest? [y/N] "; read yn;
    if [[ $yn == "y" ]]; then
     scp user@home-server:$dir/passwds.cpt $dir
    fi
  3. /home/user/passwds/PWsearch.sh
  4. #!/bin/bash
    file="/home/user/passwds/passwds.cpt";
    ccrypt -c $file | grep -i "$1";
  5. /home/user/passwds/PWedit.sh
  6. #!/bin/bash
    file="/home/user/passwds/passwds";
    ccrypt -d $file.cpt; vi $file; ccrypt -e $file

Next, define 2 aliases -- one for password lookup, and one to modify the encrypted password file. I use ~/.alias, which I load as part of my ~/.bashrc file.

  1. /home/user/.alias
  2. alias PW='/home/user/passwds/PWsearch.sh $1'
    alias PWE='~/PWDs/PWedit.sh'

Now, on the home server, I can run `PW eclipse` to decrypt the file, look up any lines in the password file with "eclipse" in them, and return those entries to me. Or, I can run `PW | more` by itself to display the entire file (paged with `more`). To modify the file, I use `PWE` to decrypt, edit, and re-encrypt the file. I also periodically save this file into my CVS repository (cvs add -kb passwds.cpt; cvs ci -m "" passwds.cpt) so I can track changes.

Remote Client(s) / Other Servers

Well, you think, that's great for a single system, but I need my passwords on 3 or 4 different systems. Plus, my home server may or may not always be accessible (eg., only when I'm on my home network).

So, once again, we start with the same three bash scripts.

Next, define a different version of the `PW` alias:

  1. /home/user/.alias
  2. alias PW='/home/user/passwds/PWget.sh;/home/user/passwds/PWsearch.sh $1'

Now, on any other server which can reach the home server over ssh, `PW eclipse` can be used to (optionally) retrieve the latest version of the password file, then search it as in the example above. Can't reach the home server? That's fine, we keep a local cache of the encrypted password file -- good enough until the next synch.

Voila! Centralized encrypted password management for Windows & Linux clients!

About ccrypt

So, what handles the encryption, and how secure is it?

ccrypt is based on the Rijndael block cipher, which was also chosen by the U.S. government as the Advanced Encryption Standard (AES, see http://www.nist.gov/aes/). This cipher is believed to provide very strong cryptographic security.

 

If your linux or cygwin distro doesn't include ccrypt in its repositories, here are a couple places you can find it: