Between Linux and Anime

Kind of like Schrodinger's Cat

Category: KDE (Page 2 of 4)

“The host key for this server was not found, but another type of key exists.” When using sftp with dolphin/KIO

I’m halfway through my Cosfest X.1 event post, but I bumped into yet another funny issue while working today, so I’m gonna do another quick solve-it post here. If you ever had the following error message shown to you when attempting to access an sftp location via dolphin or KIO in general:

“The host key for this server was not found, but another type of key exists. An attacker might change the default server key to confuse your client into thinking the key does not exist. Please contact your system administrator.”

This might be for you. In particular if you have successfully ssh-ed into the target host before. Following the discussion here, it appears that the problem, in summary, is KIO not being able to recognize a particular (new?) format of specifying a host in the ssh known_hosts list (a bug which has been filed here). Fortunately there is a workaround – since KIO is unable to recognize the known_hosts entry that ssh produces, we simply need to get KIO to be the one to produce the entry.

Back up your ~/.ssh/known_hosts file, then open it with your favorite text editor. Find and remove the entries associated with the host you’re trying to sftp into. If you cannot find it you can just delete everything in the file – with the side effect that you will be prompted again to add the keys back the next time you ssh into a previously known location. When you’re done, open dolphin and attempt to sftp into your desired target location. It should prompt you to add the host’s key – just tell it yes and you should be able to log in successfully.

That’s it! From then on you should be able to direct ssh or sftp-via-KIO into the location whenever you want.

1117
Rate this post
Thanks!
An error occurred!

Custom Textures for the Kwin Snow Plugin – the Hacky way

Now I am and have always been a fan of the compiz snow plugin. I remember spending some of the earliest days of my Linux life haphazardly getting bombastic desktop effects running and joyfully ignoring how many of the plugins were in the “Bad” list. Those were the days. I sit on KDE’s elegant Plasma nowadays and although Kwin also sports a (not so “Bad”) snow plugin, it has never quite lived up to the compiz version that I knew and loved. Over the years it has matured and stabilized quite a bit, but the key feature that’s still missing for me is being able to swap snow out for autumn leaves and sakura petals – custom textures.

Not entirely sure why, but the other day it just suddenly hit me that hey, it shouldn’t be that hard. There’s a texture stored somewhere that Kwin uses – I just need to find and replace it right? Turns out that was precisely right. The snowflake texture used by the plugin is

/usr/share/kde4/apps/kwin/snowflake.png

So how do we use a custom one? Find a png image to use as custom texture, and simply rename it “snowflake.png” and copy it into /usr/share/kde4/apps/kwin/! Do backup the old one first though just in case. After you’ve done that, disable the plugin, click apply, reenable it, click apply, and when you toggle the snow it should descend with your custom texture.

Here’s a screenshot where I use this leaf to create lazily descending autumn foliage:

Photobucket

Next step would be to find time and see if I could write a patch to make a non-hacky way to do this :)

1109
Rate this post
Thanks!
An error occurred!

K4DirStat – KDirStat has a platform 4 port!

Interestingly enough, in the wake of the recent spark of talk on “missing” KDE 3 apps that never made it to platform 4, I’ve discovered that an app I had always assumed was “missing” (or at least late-to-the-party-and-we’re-still-waiting) is in fact, not. Well, not really.

KDirStat is this really great disk usage analyser that I’ve used all the way since I was on Gnome in my early Linux days. An extremely handy utility for figuring out what is using how much of your disk during hard disk spring cleaning operations, and one that is so good at its job that I haven’t been able to find a replacement. And it’s a KDE 3 app. One of those awesome KDE 3 apps (actually, by now, the only one remaining) that I use and still use even though I have never run KDE 3 (and even though KDE 3 apps look even worse than gtk apps on the Plasma Desktop these days). So imagine my surprise when I discovered that KDirStat, in spite of its “in progress” status in the KDE 3 Application Porting Status page, actually has a KDE platform 4 port called K4DirStat:

And indeed not one that is buried in the danger-fraught lands of developer previews, but one that has apparently been packaged and released by Fedora since Fedora 13, which likely means it does not in fact eat babies and is deemed suitable for general consumption.

The catch, of course, is that it is only currently packaged for Fedora, to the best of my knowledge.

A shame really! It’d be great to get this reviewed and eventually integrated into upstream KDE, since it doesn’t look like the original developers or anyone else is presently working on a port (are they?). This doesn’t look like it’s gonna happen anytime soon though, considering it hasn’t happened in the whole year since the port became available, and considering how the last post on the author’s blog is dated early August last year. I wonder how much of the KDE community is even aware that this port exists. That last at least should hopefully be fixed now :P

Well, some voices and hands will probably be needed to make things happen. Of course, those voices and hands could be mine, but I’m a little tied down at the moment. We’ll see =/

Oh, in the meantime interested users on non-Fedora platforms can just build it on your own. Quoting instructions from the author’s blog:

The source is being tracked with git. You can get an up-to-date copy with the command

git clone http://grumpypenguin.org/~josh/kdirstat.git

To install, simply run:

cd kdirstat
mkdir build
cd build
cmake ..
sudo make install

OpenSUSE users can also add this repo to install it via Yast.

1084
Rate this post
Thanks!
An error occurred!

Update on the ‘otaku’ tag, and stuff

You may (or may not) have noticed that my ‘otaku’ tag has been looking somewhat forlorn and abandoned for awhile now. And this isn’t even the first time. Unfortunately when things start getting hectic, recreational activities that require a positive input of effort and concentration, like anime blogging and KDE hacking, tend to be the first things shoved into the backseat.

I’ve recently settled into a job as a Research Assistant at my university where I’m continuing some of the work I’ve been doing during my final year project while contemplating on whether or not I’d like to do grad school. The work influx on assuming duty has been quite torrential, thus the recent general lack of blog posts. However, I think I’m starting to settle into the rhythm now, somewhat, and I’m currently in the process of working my recreational activities back into my life. I’ve rebuilt KDE from the new git repositories and have started doing some little bit of bug fixing (just pushed a patch for bug 209962 couple of days ago), and I’m now looking into once again penning posts to my lonely otaku tag.

Along those lines, I’ve decided to make some changes to my anime-blogging routine. I’ve decided that I’ll forget about making an effort to spotlight the current broadcasting season, since my attempts at this in the past has been mediocre at best and.. well really just all round abysmal. I’ve decided instead to be time-agnostic with the anime I decide to write about, so this lets me worry less about thinking up things to say about the shows that everyone else is already talking about anyways and actually select blogging material in a more meritocratic way. Hopefully then I’ll actually, finally, start to thin down the list of really-great shows on my to-blog that I’ve been perma-procrastinating on.

Of course, this doesn’t mean I’ll never say anything about the current season. But I’ll only say something if I really have something I want to say. So I’ll in short be attempting to move towards a more editorial blogging style. In all likelihood, a side-effect of this would be that I post less frequently than I used to, but with hopefully more substance in each post.

Regarding the current anime season, I’m not actually following very closely, and I’m not actually liking too much of the available repertoire. So I probably won’t be saying much about it. I plan instead to get started on blogging this 7-part animated film series that I’ve wanted to write about for some while now. It’s called “Kara no Kyoukai – the Garden of Sinners”. So there’s a heads-up for you in case you haven’t watched it. Watch it. This stuff is A+ material :)

1062
Rate this post
Thanks!
An error occurred!

Connecting to Hidden Wireless Networks using KDE’s Networkmanager

It is not without some surprise and.. disappointment.. that I discovered that KDE’s networkmanager frontend appears to be still having trouble with hidden wireless networks. It used to be so when we used KNetworkManager, and now that we’ve moved on to the shiny new plasmoid, the problem… stayed. Oh well, the common advice that hidden SSID’s are not useful and that one should be setting up WPA encryption for true security is likely sound, but for folks like me who happen live under already-configured hidden networks, we’ll need to use a workaround for now.

To allow the networkmanagement plasmoid to detect and connect to a hidden wireless network called, say, “hiddennetwork”, open a terminal and type the following command:

sudo iwlist wlan0 scanning essid hiddennetwork

Note that you need to replace wlan0 with your wireless interface. This is usually either wlan0 or eth1. You can use the iwconfig command to find out what your wireless interface is called. Of course, also replace “hiddennetwork” with your desired hidden network.

If all goes well, your hidden network should now appear in the networkmanagement plasmoid, and you should now be able to connect to it like any other network.

1036
Rate this post
Thanks!
An error occurred!

The Rise of Plasma Activities and What it can do for You

So having been kept away from KDE-land for some while, I innocently but excitedly pushed the upgrade button when I saw that 4.6 was out, and ran immediately smack into the huge forward leap that plasma activities has made this release. I have always been a big fan of activities and this is really exciting stuff for me, so I made a quick visit down to Chani’s blog for a quick-tour of what’s new and what’s good, but while I personally found her screencasts illuminating, a quick skim through the blog comments quickly revealed that many people remain more perplexed about activities than ever.

I’m gonna spend some hours on the keyboard here and see if I can fix some of that :)

Read More

1009
Rate this post
Thanks!
An error occurred!

Hiding Kate Session Applet Items

I put my Kate Session Applets at the corners of my programming-related activities, and they are usually little. So it always annoyed me that the three default items that I cared little about were at the top and had to stay at the top, forcing me to scroll to load the kate sessions I’m actually regularly interested in.

Well, I recently scratched that itch:

All items in the applet, including the default three, can now be hidden by unchecking it in the new configuration interface. And what’s more, different applet instances can hide and show different items too.

926
Rate this post
Thanks!
An error occurred!

GSoC wrapup for Plasma Mobile System Tray

I know the pencils down was a week (plus?) ago, but I did a fresh upgrade of my system (to OpenSUSE 11.3, then to KDE SC 4.5.0) and then realized to my horror that there was obviously no way I could make a screencast or even take screenshots for this post until I’ve rebuilt trunk and plasma-mobile. So I frantically spent the past week doing exactly that, and now without further ado, the screencast:


OGG here

My trunk kdebase is still a little screwy at the moment, in case you noticed the extreme ugliness of that context menu there. Also, somehow the sizing and position of the icons have gone a little off between the end of GSoC and now (Damn).

Anyway as you can see, nothing much has changed in the high-level ideas of the system tray I described in my previous post. Most of the work I put in since the mid-term had been in the way of improving the implementation strategy – cutting most of the harder ties between the system tray and the mobile shell, and getting the system tray to update its behavior based on loose events like resizing instead of specific events like Qt signals. All this of course to fit into the Plasma philosophy of creating loosely coupled independent parts – so that for instance we could put in a replacement tray without needing to change the shell code – since the shell only knows it is given a containment that it needs to resize – and we could also easily put my systray elsewhere as long as it knows to resize the tray the right way.

There is also of course noticeable change in the look and feel. The tray containment paints its own background now, and the icons now resize along with the containment instead of disappearing and reappearing at the ends of the animation – so that we don’t need extra signals to indicate when those ends occur. I’ve also thrown a couple of “fake” plasmoids in – a fake battery indicator and a fake service signal indicator – since both of these things apparently require hardware-specific treatment. Unlike the desktop system tray, the mobile version only supports the plasmoid and dbus system tray protocols – xembed isn’t supported. Iirc those aren’t resizable anyway :)

It’s been fun. I have always loved Plasma for the sheer sensibility and elegance of its software architecture, and its really nice to be given a chance to gain a deeper understanding of it and experience it for myself. It was also great to be forced to crunch through a bunch of documentation for all kinds of QGraphicsObject derivatives – and have a brief tantalizing tango with QML while I was at it. It was a great GSoC, and I’d like to thank my mentor Alexis and the ever helpful (some say omnipotent) Marco for making this possible for me.

Oh, and I plan to be hanging around of course. I forsee my school final year project crashing down on me tsunami-style very soon, but I still hope to get a couple of things done before 4.6 gets out. Will blog about those when the time comes ;)

892
Rate this post
Thanks!
An error occurred!

GSoC Mobile Systemtray Update

Had been holding off posting on this until I have something reasonably pretty to show for it, but damn, said pretty thing sure took its time. Anyway, GSoC mid-term evaluations just ended, and I finally managed to hack up something that looks somewhat presentable. Here’s a short screencast of it.


EDIT: Oops forgot the ogg here

Some key ideas of the current implementation:

  • The tray lives in it’s own containment separate from the main activities/launchers.
  • There is a passive “shrunken” form and an active “enlarged” form.
  • The passive form is not interactive and click/tapping it simply switches it to the active form (with a simple QML animation thrown in). It shows a number of defined “always-show” applets and a limited number of the other applets, prioritized by recent activity.
  • The active form shows all available applets in large, finger-friendly sizes, and is scrollable in case it doesn’t fit the screen (hello Plasma::ScrollWidget!). It behaves more or less like one would expect a systray to behave.

Not a lot to show for one month plus worth of development I admit :( This is actually my third implementation attempt. In the first attempt there were two “trays” – one small and one large, and taking hints from the comic plasmoid, I put the large one on a full-screen transparent QGraphicsView which covers the small one when activated – but this isn’t nice since it, in notmart’s words, relies on compositing being available to not look like crap. So the second implementation gets rid of the QGraphicsView and instead positions the large tray relative to the parent containment, but then there was another problem: we can only have one set of plasmoid applets running to save memory, and there was no way to display one set of applets in two trays. So I gutted the thing again and did this third attempt where there is only one tray which shrinks and expands accordingly… and that’s what you see in the screencast :)

This is far from finished of course – if nothing else that “cancel” button probably doesn’t quite belong there :P Iirc I should also be thinking about doing notifications for my GSoC, so there’s plenty more to do for the rest of the GSoC period. Fun stuff. Alright, think it’s time I wrapped this post up and go clean up my code and commit it – and pray I don’t get torn to bits by darktears and notmart for some terrible mistake or design flaw I made :)

871
Rate this post
Thanks!
An error occurred!

Setting the “Primary” Screen where your Panels go on Linux Multi-Monitor Setups

If you have a multi-monitor set-up and are wondering if it’s possible to control which screen is “primary” – where all your panels will end up in – yes, it is. That is, assuming your desktop environment asks X to decide which screen is “primary”. KDE Plasma does, and Gnome probably does too. As long as X is involved in the decision, it’s possible to use Xrandr to tell X which screen you want to be “primary”, by using the “–primary” option. For example, if I want my laptop LVDS screen to be my primary screen and get all my desktop panels, I’d run:

xrandr --output LVDS --primary

That was easy :) On a related note, some changes are forthcoming in KDE SC 4.5 in the way multi-monitor setups work. Take a look here for some details.

858
Rate this post
Thanks!
An error occurred!

Page 2 of 4

Powered by WordPress & Theme by Anders Norén