The Tmux Ranger

So the tmux + ranger duo. It's something I have coveted for quite some time, though to be honest I almost never use it anyways (but it's just that awesome). Tmux is a terminal multiplexer and that means that it can split up your terminal into multiple terminals in a single window. Ranger on the other hand is a badass cli file manager that you can add pretty much any shortcut in and do tons of other nifty things with. The problem that was present before was that combining the two generally resulted in the w3m image displaying capabilities to die, meaning those wonderful true color images couldn't be seen in ranger while using tmux. To someone like myself, that SUCKS...ASCII is great and all, but I WANT my true color images. Apparently the issue was that the standard way of getting the terminal size normally wasn't possible in tmux due to how it can be resized and stuff (and thus instead of reporting decent information, it reported pretty much zero).

Eventually a guy was like "w3m works in tmux...let's check what they do" and lo and behold, there was a option along the lines of "-test" that was used by w3m to check the size. Next thing you know, there is a small patch, some little fixes, another fix to deal with the derpiness that urxvt had, and bam a workable patch to deal with tmux and the image viewing problem that ranger had. At the current time, the main Arch repos have an older version of ranger, but that is why there is the all-mighty AUR which had the "pull shit down from git and build it for maximum bleed" versions (ranger-git is apparently tagged outdated for something...as to what I have no idea since it still builds and all...worst case, just use the python2 version I guess...). Thus the AUR has a working version of ranger that can display true color images in tmux.

The next issue deals with compositing, because apparently there is also an issue where ranger can't show images when the terminal has compositing on. This means it's either semi-transparent terminal without images or an opaque terminal with images. As far as I can tell, there is no "real" solution for the issue so getting that true transparency terminal AND images in ranger just isn't going to happen.

A "solution" provided by a fellow Arch user consisted of (added to .bashrc):

alias ranger='nohup urxvt -depth 16 -e ranger && urxvt & exit'

It pretty much just says to change ranger to open up a urxvt terminal with true transparency off entirely so that when ranger is called, you get a solid terminal and those wonderful true color images while closing the previous terminal and then re-opening urxvt after ranger closes out.

In other words, it makes things ugly just to get a ranger terminal out. Not only that, but it also prevents ranger from opening in a tty as well. Of course, I have the best solution because otherwise I wouldn't need to make this post. Granted it is not much better than the command above, but it will give you the next best thing.

alias ranger='if [[ $DISPLAY == :0 ]]; then urxvt -depth 24 -transparent -shading 25 -e ranger &disown; elif [[ -n "SSH_CLIENT" ]]; then ranger --cmd="set preview_images false"; else ranger; fi' 

It just adds a quick check if $DISPLAY was set and to spawn urxvt+ranger if it is, or if the tty session is through a ssh connection and just use ascii images, otherwise just running ranger if it isn't. Of course, the spawned terminal also has fake transparency because if I can't have true transparency, I'll settle for some fake.

Pretty much, it seems that in an ssh connection without X, the $DISPLAY isn't set, a ssh with X does get set (though since I just ssh'd into the same computer...it might be set to something than what I saw, but it was "localhost:10.0") but it doesn't really matter since the second if statement catches all ssh connections. It's somewhat important to differentiate between ssh and normal because you can't pass the framebuffer over ssh without using ssh -X (and since I never do ssh with X, I have no idea how it works). The final bit catches the rest of the ranger calls, which would maybe be tty1-9 etc. on the local computer and spawn ranger normally without the extra urxvt.

KDE Down the Drain

So after around two weeks of KDE, a sizable amount of customizing and other randomness, I decided to toss all of it out the window and go back to my usual openbox+tint2 setup. Some install somewhere borked the Kwin compositing and I decided that there would be too much effort in trying to solve everything I wanted out of the environment.

Since I did stay in KDE for more than a couple of hours, I thought I would write some of my thoughts about the KDE environment so before I ever think to go and try it again, I read this post and decide otherwise. KDE is great...for the most part. You get some nice widgets, eyecandy, extra settings, etc. and has some awesome integration with kde-look/etc. One thing to note, most of the extra widgets...some of them are kind of useful, but most of them aren't particularly needed and the default ones also weren't exactly the greatest of widgets. There was an alternative analog clock instead of the digital one, but I usually keep my taskbar at like 20px and it is apparently determined to keep most of the little ticks shown, making reading it kind of a chore. Thus I did the compromise of using the digital clock which I didn't want to use because of the great issue where when you lock the widgets, the edge of the clock seems to move in perspective of the size of the taskbar...meaning I couldn't see the AM/PM without making the taskbar bigger (which I once again made the compromise to see my AM/PM). My clock ended up being a digital clock and caused my taskbar to be bigger than I would like...all for the sake of that am/pm and not on the edge of the screen look. Extra desktop effects were also fairly limited...and none of them looked particularly interesting either...the top rated one was called literally like "Cool effect" ._.

If there was any "Get the latest stuff" button that I liked, it was the ones that dealt with the themes and styles of the desktop. Those were integrated with kde-look spectacularly and was literally the only ones that I cared for. The widgets themselves were kind of annoying since I couldn't resize any of the ones on the taskbar, meaning I couldn't fix any of the issues I had with the widgets on the taskbar, aka the only place I wanted to have widgets. I tossed the virtual desktop switcher because apparently it's either large, or extra large and really I was fine with just using the desktop screen to flick through my virtual desktops.

Tilda also didn't want to play nicely with the compositor so I had to go with yakuake, which is decent in it's own right...but I needed to use a theme to deal with that annoying bar at the bottom and even then, I couldn't have it extend from the side or the bottom or anything. So much for customization...tilda has got a leg up on it. Although with that said, having most of the options magically get integrated with the systemsettings was really neat.

The final conclusion ends up being "sure KDE is extensible, not that any of the extended stuff are mega amazing or life changing..." Most of the stuff available in KDE just didn't suit my tastes and the only real incentive was how the theme of the desktop could be changed relatively easily, but otherwise there is nothing there for me (my splashscreen TT^TT).

KSplash and Liquid Alchemy

It's a new week, and after an entire weekend of just not doing much at all. With the amount of random testing of the KSplashX engine last week, I found some small tidbits here and there without much to offer in terms of making some really fancy looking splash screens. Sure you could add animations here and there using animated images which in and of itself is a LOT of work simply because each frame has to be made and then organized into a single image. I also found out that trying to put a fullscreen animated image isn't something that works, and so I gave up on that front :D.

Instead I decided to take a look at the QML engine and of course that mean bumbling my way through any of the QML that I could get to at least look how I wanted (whether or not it is the most blasphemous piece of code, I don't know). So I played around with the animation and made myself a mandatory Miku related splash theme (it's my go-to topic when I can't think of one). Since I wanted to play with QML particles, I originally was thinking of a starry theme...but due to laziness, I made the stars in gimp using the fuzzy circle paintbrush...meaning my stars looked more like floating balls of fluff. After finding out that I actually can't even play with rotating and multi-sized particles that seem to be in QtQuick 2.0 (old tech WHY), I decided to ditch the star theme for a snow one because that totally made sense ._.

With that, I slapped together a QML made background (a.k.a. rectangle with a gradient) along with a couple different sizes of my snow particle image to make some different sized snow fall all around. Of course, I added the quintessential Miku render (taken from some guy who probably didn't ask for permission to render it anyways ._.) on top of the smaller particles of snow and kept the larger ones able to float over the render, because nobody likes eyecandy that skimps on layers....and BAM, rudimentary splash screen complete...without any care for the loading stage of the desktop, making it literally just a picture with Miku and falling snow. Being the kind of guy that needs just a little more than that, I originally wanted to copy a design from a wallpaper...and then decided to say forget it because apparently I can't make arcs with QML (I was hoping to animated a circle being made using QML, but that didn't happen). Not only that, I couldn't figure out how to actually toggle animations without putting the animations inside the thing I wanted to have animated and using the "behavior on blah" element. So suffice to say, some of the shit of QML just doesn't make sense to me at the moment, probably because I am looking at it wrong. 

In the end, I settled for just copying the bars over and simplifying the idea to something that wouldn't require me to make an animation because effort just isn't in my vocabulary apparently. With some minor tweaks and hopefully some stuff that would make the splash screen look close to the same regardless of screen resolution, I stamped it with done and posted it on KDE-Look. Since the animation itself would be kind of a hassle to make (no screen recording programs at the moment) and I'm actually not COMPLETELY done with the splash just yet, I'll just post a screenshot of how it is supposed to look when everything has loaded.

Of course, in terms of what I'm going to do to finish this splashscreen, it doesn't have anything to do with the QML or even the animation, but rather adding a splash sound to go along with the animation during loading because apparently you can do that. All it takes is a simple script in the ~/.kde4/env that plays an audio file (aplay or mpg123, etc) and of course an audio file somewhere. Hopefully I'll find an audio clip that matches the atmosphere I want, otherwise it isn't that bad of a splash screen even alone right? RIGHT ME? 

Anyways, that ends my rant on KSplash along with the main chunk of my adventures about it. I'm hoping to add a lot more anime related KSplashes to KDE-Look and stuff for anime lovers that obviously couldn't care less about me anyways :/...*cough cough*#FansubStatus*cough cough*...and not those shitty kinds of splash screens where it's like "o hay I moved around the icons and replaced the background" or something like that because when I say eyecandy, I MEAN EYECANDY.

Maybe one day I'll even make an otaku-related respin of Arch or something because OBVIOUSLY those work...said no one ever. Even then, it would be nice to have myself a respin so I don't have to use so much effort reinstalling stuff and trying to remember what themes/etc. I used before...So I guess it would be more of a personal respin rather than a public one, BUT HEY I could always force my opinion onto others. The only real issue is making a coherent theme/style/w.e for GTK2/3, KDE, Openbox, Fluxbox, etc. so I probably won't end up doing that due to laziness. 

KSplash and the Search for Liquid Generation

For the past couple of days, I've been living in a KDE desktop. Some would say this is insane, others would say that I made the right choice and to be honest, I haven't checked out much of the actual environment to make a judgement call. In terms of what I installed, I went for a minimal kde setup to give me the settings and desktop to play around with.
For most of my times in linux I always seem to try to aim for a sweetspot between lightweight minimalism and eyecandy. I originally thought that I might try the standalone compiz again, but the dying momentum behind the project did make me wary and of course I'm one of those people who like to see progress. Thus, I turned towards the supposed equally good kwin to provide the eyecandy I'm looking for while hoping to also hit the minimalistic theme that I want. This also will me a good chance to try out some of the QT apps in all of their glory rather than in a GTK environment.

Of course with everything that I do, I get side tracked on the strangest of uselessness and ended up wanted to make my own ksplash screen in hopes of at least loving my splash screen if I can't remove it. Upon a couple of quick searches, I ended up finding KSplasherX and KSplashQML with the former being an actual application to make simple themes for ksplash and the latter being the second engine of ksplash that utilizes QML to define how things are displayed. Without knowing QML and not wanting to put in the effort to learn it (though in actuality, it doesn't look very hard at all to learn), I tried out KSplasherX only to find it rather limiting in what it could do. In the end, I sifted through the few files of a couple of themes that used the KSplashX engine and slowly pieced together what most of the needed parts. Surprisingly enough, I couldn't find any real detailed information about how to make a KSplash screen from scratch, but it isn't like I tried hard.

So on to the main reason for posting: giving the stuff in the KSplash theme some layman's terms to describe all of it for my own memory.
The local themes are installed into ~/.kde/share/apps/ksplash/Themes and are separated into their own folders. Each theme has the variety of resolutions the theme is available in, a single preview image that seems to fall between 300~500 x 200~300px, and a theme.rc. The theme.rc is just a simple text file defining some of the metadata-like stuff (author, homepage, version, name, description) and the engine that the theme will use (KSplashX or KSplashQML as far as I know for KDE4). A QML theme will also have a main.qml that is the actual theme-ing part of the QML theme, but for KSplashX themes, those are inside of the resolution folders.
The contents inside each resolution folder is pretty basic. It consists of a singular description.txt (which could be considered the equivalent of main.qml) and the images that are used in the theme. Animated images need to be placed inside of a single image and aligned in a grid going from left to right, top to bottom, with each row having a maximum of 10 frames of the animation. Because fuck it, here is an example image.

As for the file names of these images, they can literally be almost anything you want, but you are going to need to type those into the description.txt so shorter is nicer...probably. Which brings up the next section of this post: the description.txt.

The meat of your KSplashX theme, this file tells what pictures to show, in what order, where to show them, etc. So, tossing formatting to the wind, I'll just list this stuff out.
- SCALE : It seems to have the option of "ON" or "OFF". For better or worse, I'm leaving it on since it seems to be what everyone else does.
- SCALEX : I can only assume it has something to do with scaling in the X axis (option of "ON" and probably "OFF").
- SCALEY : Likewise for the Y axis.
- BACKGROUND_IMAGE : Two numbers proceeding the image name, though what those two numbers actually do, I have no idea.
- WAIT_STATE : There seems to be around 7 states (that I found so far) during the KDE splashscreen that you can use as checkpoints...though whether the first one can really be considered is if you think the starting line is a checkpoint (initial, kded, kcminit, ksmserver, wm, desktop, ready).
- ANIM_REL : Defines which animation it is, where to place it, what image, how many frames, how many times to loop, and the delay between each frame. A little bit of expanding later on for this one, so hold on to your butts.
- IMAGE_REL : Similar to the ANIM_REL, but this is for static images rather than animated ones.
- STOP_ANIM : As one could expect, it stops the image defined.

So a quick semi-deeper look at ANIM_REL and IMAGE_REL, which place an animated and static image respectively in the order described in the description.txt.
Examples:
ANIM_REL 1 CC -320 200 CC 50 animation.png 30 20
IMAGE_REL CC -50 100 CC image.png

In the ANIM_REL, the first number represents what animation it is defined as so that, if needed, you can stop the animation later on using STOP_ANIM #. Next is "CC" which just seems to be about the equivalent of a separator...though I would like to think there is some secret function to them that I just don't know yet. Afterwards it's the offset of the image from the center of the screen X and Y respectively (negative towards the left and top, positive towards the right and bottom) followed by a second separator. This next number is the total number of frames in your animation (which in the example animation above, is 41) and then the actual image, followed up by the delay between each frame in...milliseconds for all I know. Finally, the 20 is the number of times to loop through the animation and can be omitted to have the animation loop until stopped or the splashscreen finishes. IMAGE_REL is set up exactly the same way, but removes the way to call back on the image (the 1 in ANIM_REL) as well as the number of frames and delay between each frame, since obviously a static image doesn't need them.

Some quirks to note about using transparency in the splash screen.
- Animated pngs WILL crop each other when overlapped, cutting the previous image with the newer one, regardless if the newer one has that section transparent or not.
- Placing a static image before starting an animation or another transparent image will result in the expected result of having the static image included in the transparency of the newer image.
- Images after animated pngs overlapped, but before stopping the animation will result in the animated image having a higher priority than the static image and cut into the static image.
Images overlapping after animated pngs are stopped will crop into the now stopped animated png instead of incorporating the now static animation into the transparency.
- You can start or place multiple images/animations almost anywhere inbetween each loading state and have them appear at roughly the same time.

I've also noticed that on my computer, if I stop the animations before a certain point, the stopped animations seem to vanish completely for some unknown reason. As an extra tidbit though, a DoctorWho themed KSplash that even included a sound file to go along with it. Usage apparently consisted of just putting a bash script (don't forget the .sh at the end...maybe?) in the ~/.kde/env folder that used aplay/mpg123 to play a sound file somewhere on the filesystem.

And with that ends my current adventures with KSplash. As a show of the testing product I ended up with while playing around (not what I plan to eventually have as my splash screen, but a decent placeholder).