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).

An Accumulation of PSX

So the PSX was a cool console system from ages ago with actually decent games. While thinking to myself "dam, I would like to play some of those old games", I thought I would check up on the emulator sort of things that I almost never pay attention to.

Apparently there are quite a few emulators for the playstation now, though really I could care less about most of them besides PCSX-R because who doesn't love stuff that is constantly being updated. That said, I'm a lazy guy so in my case, I just stick with retroarch anyways. Unfortunately the point of this post isn't really for recommending anything (though if I had to recommend, retroarch is it) and instead I'm going to be talking about psx iso compression because "first world problems" the isos are fucking big.

There are multiple ways to reduce the size of the iso and some can be compounded to reduce the iso further...but for the most part, the methods consist of either:
a) Remove shit from the game
b) Use algorithms to compress

Option (a) obviously has issues because well shit, you are removing parts from the game, that is a stupid idea and lame. Of course the stuff that would be removed would be things like the animated cutscenes, music, sound effects, voice acting, and whatever else you can squeeze out without breaking the game, but you are just cutting yourself short of the gaming experience. Another variation that the internet has apparently come up with is to take out the XA tracks and convert them...which kind of works I guess...but that is extra work I don't want to do.

Option (b) is pretty much the way everyone goes about their business, and with reasonable simplicity. Aside from the various kinds of formats that you might find the PSX rom in (.bin/.cue, .img/.ccd/.sub, .iso, etc), there are the compressed formats like .bz/.bz.index, .z/.z.index, .cbin/.cbn, .cso, .ecm, etc. Out of those, I find that .bz is probably the most convenient in terms of storage and usage. Compressed bin is a little less compressed that .bz and .z of course shows similar results, though luckily all can be run directly (though you might need to use mooby's cdr plugin). I'm not sure if any emulator supports .cso...and ecm can't be run either. In terms of straight compression, 7z wins, but can't be played from any emulator without extracting, which pretty much just leaves bz to be the best option. bz seems to have the highest compression ratio while still being playable in emulators without having to extract...And then we come to the strange part.

So after coming to the conclusion that bz is obviously the best choice out of the above, there are a number of issues with that choice, mainly being that it is rather off the beaten path. To utilize the .bz format, you must use mooby's plugin, otherwise it's completely useless. Using those sorts of plugins with retroarch is less than readily apparent (and by that I mean I don't have a fucking clue how to use plugins with retroarch). Thus, we look towards a different format (funnily enough, one of the formats I didn't list above) which is .pbp, commonly seen in the psp scene. As it turns out, the PCSX-ReARMed core surprisingly supports .pbp format which works as you would expect. Not only that, but the size is actually smaller than the bz format, which makes everything better...and of course, you can play it without decompressing manually. The only real flaw comes in when you DON'T use retroarch or PCSX-R because aside from an actual PSP, there isn't really any other emulator out there that can use the format (not that I actually tried hard searching).

In the end, the verdict of best format goes to .pbp format (props Sony, at least something was done decently) and my recommended emulator goes to PCSX-R for Windows and Retroarch for everything else because the Windows package of Retroarch doesn't come with PCSX-R...I'm sure there are tons of people who would die supporting mednafen or epsxe or no$psx or whatever, but really mednafen is a picky derp of a program, epsxe isn't exactly the most open of programs, and who really uses no$psx (I've never tried it, but hell the dev is a genius, so for all I know it's performance could be god tier).

On a completely separate note, syncing my .srm file sounds like a spectacular idea so I can play the game on my computer and then play it on my phone or my laptop without too much of a hassle of worrying about my latest save...only problem is that I'd have to sync all of them unless I decide to symlink all of the separate .srm files to a single .srm file and then sync that file instead...and then do the same to my other devices :/. To be honest I would rather all of my saves be in one file (yeah yeah single point of failure, but it's not like the PSX wasn't like that).

A Candy Known as rPi

After leaving everything for around a month to do absolutely nothing, I magically ended up with a raspberry pi that I actually didn't magically end up with. In other words, I bought a raspberry pi for myself and turned it into my very own server. Dubbing it RoriCandy, I made a nice little cardboard box case for it based off of a tutorial on the interwebs somewhere...mostly because I was too cheap to buy some nicer looking supplies.

After putting everything in a nice casing, buying an unneeded hdmi to dvi converter, I connected to my rPi via ssh and played around with it for a little. Unfortunately the raspberry pi isn't exactly the strongest of powerhouses, so there is a rather low limit in terms of what can be done.

With that said, my raspberry pi was set up with archlinux to do the basic sort of things that I could want. It serves my files over nfs to both my laptop and desktop, streams music via mpd, downloads torrents to my external hard drive, and eventually I'll add finding the actually .torrent files as well (flexget/sickbeard/etc). Streaming files from the rPi works well enough that playing anime and music from the rPi is a bearable experience, though most of the actual work is being done on my desktop/laptop rather than the rPi.

The only issues that I have yet to resolve consist of getting flexget to work (thanks to Arch with always up-to-date packages that end up breaking flexget due to being "too new") and coming up with things that could be better done on the raspberry pi rather than a regular computer. It's a convenient way to share files between my laptop and desktop...but if I didn't have one or the other, it's worth would be no different from placing everything on my computer.

In conclusion, my raspberry pi pretty much ended up being a toy I can just leave on forever and for the most part, I know it is working in a relatively static way. I planned on using it as a server, and it happens to work rather well as a server. Maybe I should post a generic post about setting it up...since it can be found everywhere on the internet and most consist of "write image to sd and boot" which is completely helpful in setting up everything I could ever want...no it isn't, I don't understand what idiot would think that is a tutorial to setting up a rPi, but anyways...I should probably be thinking of better things to post.

Revisiting Video Players

So a little over a month ago, I made a wonderful post about video players and the like. Funnily enough, after shuffling around the internet I happened to end up finding a video player that is perfect for windows. By perfect, I mean it's just a build of mpv for windows. From what I can tell, the build works about the same as it does on linux, but of course instead of just direct build of mpv, there is a front-end that you could use instead...

It's called Baka-MPlayer and although the interface is somewhat lacking, it's not like I usually watch my anime without it being in fullscreen anyways. All of the dead basic stuff are included, so sub tracks, chapters, hi10, etc. all supposedly work. Resource-wise, it's less hungry than my installation of MPC-HC (usually 15% of my cpu and ~300MB of memory), though for all I know, it could be due to the filters and stuff I have. The mpv player takes around 130MB of memory and 4~8% of my cpu with the baka mplayer front-end taking another 50MB, adding up to a little over half of the resources used by MPC-HC. It also has some strange other features that I have never seen in a video player before...like having microsoft Sam/Samantha say the ID3 tag title, and voice recognition of all things.

So pretty much, you could say "Baka Pause" while doing other stuff, or any of the other voice commands without actually needing to do anything to the player. It's hilarious for all of a couple minutes that you can further extend for another minute since you can actually customize the call name for the program ("Baka") to anything you want...*cough* "imouto" *cough*. Also, since it's a build of mpv, the idea is that your viewing experience would be just as badass as it would be on linux.

Anyways, it mega-simple to get running and doesn't require any sort of mucking around with filters and codecs, thus instead of MPC-HC, this video player now gets the top position in my book as the go-to video player for my anime needs.
The website and github for the project are below:
http://bakamplayer.u8sand.net/index.php
https://github.com/godly-devotion/Baka-MPlayer