I thought I would make a post, or rather a log of setting up my raspberry pi in the event that I have to start over from scratch. Of course, this will mainly be covering the finer details of setting up the raspberry pi, since it's pretty easy to install via NOOBS. While NOOBS is probably easiest, the option is available to install just a certain distribution such as Pidora, Raspbian, etc. if you really aren't planning on using anything extra. In any case, I'm using the NOOBS lite version since I'm planning on having a cable anyways to update the install. With that said, the rest of this post is under the assumption that you have just installed Arch on your raspberry pi and are on the very first boot of your new installation.
The arch install itself took my raspberry pi around 4-5 minutes and the default login is root/root and probably the first thing to do is to update the system with a simple "pacman -Syu". After updating everything, rebooting is a good idea to make sure everything is reloaded and nothing strange happens.
Then we set the root password with "passwd" and change the hostname as well to something we could use to differentiate or just for laughs with "nano /etc/hostname". Just remember to add that hostname to the /etc/hosts file ("127.0.0.1 localhost.localdomain localhost <hostname>).
Continuing on, we remove /etc/localtime via "rm /etc/localtime" and link to a new one with "ln -s /usr/share/zoneinfo/America/Los_Angeles /etc/localtime". Of course, change the America and Los_Angeles bit to match your local time (to list out all of the options, just "ls /usr/share/zoneinfo/...").
We could literally call it quits here and just use the root account for everything, but as anyone who knows what they are doing, you NEVER just casually use root for anything. So, we need to create a new user and give him almighty powers that he can use whenever he wants. This can be done with "useradd -m -G wheel -s /bin/bash <username>" and to break the flags down, -m is to make a /home/username directory to go with the new user, -G is the group or groups the user is in, and -s is what shell they will use. Now we need to give the user a password, thus "passwd <username>" to change that to something memorable.
To give root access to users, we are going to need to grab "sudo" from the repo, so "pacman -S sudo" will install that in a snap. Then we open the permission settings for sudo, we are going to use "EDITOR=nano visudo", though if you like using vi as a text editor, that is fine too. Scroll down to "# %wheel ALL=(ALL) NOPASSWD: ALL" and uncomment it by removing the "# " in front of it. Feel free to read the descriptions for the options in the event that you don't want to have the users in wheel to just have unrestricted root access (ie. they need to use their password, etc.)
For the sake of clarity, you don't need to use the wheel group, you can also use the sudo group or a totally different group if you want. Just remember to have the user in that group and that the sudo permissions also reflect that.
Next is to set up the time to sync with the internet time, thus we need to enable ntp with "timedatectl set-ntp true" and things should supposedly automagically work.
Now we can log out of root and log into our new user account. At this point, we have a fully prepared Archlinux install that is ready to become the testbench of the flood of programs we are going to install to create our media server/aggregator. Since this is a lengthy post as it is, and I would rather re-read this stuff on separate posts, I'm going to do just that.
7/11/14
Anime and Raspberries
On the great quest for watching anime nicely, the raspberry pi could be a major part, but just don't watch anime on it. It's actually quite the simple story as to how this opinion came about. At the very beginning, omxplayer couldn't handle internal subs, otherwise known and pretty much universally used in the anime community as softsubs inside of the mkv container format. Much time has passed since then, and for the most part, softsubs now work with omxplayer as well as custom fonts that might be included. Thus currently, you could watch anime with some semblance of decency on the raspberry pi and if you normally stream and decided to swap to viewing anime locally, then there is probably even going to be an improvement in the quality.
The real issue with the raspberry pi isn't that it can't play the videos, but it just seems to be lacking the power needed to deal with the anime encodes of the modern....era... While perfectly watchable, there is some occasional blocking artifacts that seem to appear (in the same locations in the video for me). With the handful of videos that I tried, there weren't any major issues or artifacts on a large portion of the screen, but since we are watching stuff locally, why settle for watchable when you can watch it on another device that isn't so resource limited.
Unfortunately there really isn't a solution since omxplayer is pretty much the only video player available and optimized for the raspberry pi. XBMC also uses omxplayer on the raspberry pi and of course it works just about as well as it should, but apparently it's just not enough for that perfect anime viewing experience.
So in the end, it's probably better to stick to XBMC for movies, maybe older anime (dvix days?), and "normal" stuff, or the better option of using it as a media aggregator/server rather than a media player. This is where I laugh because I have never gotten to the actual bit about a media aggregator/server thus I'm just saying that you could do it that way with zero backup. Eventually I will get there I guess...
The real issue with the raspberry pi isn't that it can't play the videos, but it just seems to be lacking the power needed to deal with the anime encodes of the modern....era... While perfectly watchable, there is some occasional blocking artifacts that seem to appear (in the same locations in the video for me). With the handful of videos that I tried, there weren't any major issues or artifacts on a large portion of the screen, but since we are watching stuff locally, why settle for watchable when you can watch it on another device that isn't so resource limited.
Unfortunately there really isn't a solution since omxplayer is pretty much the only video player available and optimized for the raspberry pi. XBMC also uses omxplayer on the raspberry pi and of course it works just about as well as it should, but apparently it's just not enough for that perfect anime viewing experience.
So in the end, it's probably better to stick to XBMC for movies, maybe older anime (dvix days?), and "normal" stuff, or the better option of using it as a media aggregator/server rather than a media player. This is where I laugh because I have never gotten to the actual bit about a media aggregator/server thus I'm just saying that you could do it that way with zero backup. Eventually I will get there I guess...
7/3/14
Archive Managers and Uselessness
So it has been quite a few months since I made my last post, mostly because every time I thought about it, I couldn't think of what to write. Rather than talk about a specific topic, this post will just kind of be an accumulation of stuffs that happened.
First off was the Steam sale, which in my opinion was meh. The only real reason I have Steam was because of the free games that I happened to amass during my random raffle entries. During the entire sale, I only got a couple of games that I really felt like I would play, primarily looking for local co-op games so my brother and I could play if he visits or if I visit. From this standpoint, Steam is kind of convenient because I don't need to really bring anything except maybe a controller if I really want one. To list off the games, Castle Crashers, Dungeon Defenders, Dust: An Elysian Tail, Forced, Megabyte Punch, Sanctum 2, They Bleed Pixels, and the Trine series. I've only really tried Dust, Megabyte Punch, and They Bleed Pixels so far, but I'm really enjoying them, thus the sale wasn't a complete flop for me. Only down side is that maybe half or so aren't on linux which kind of sucks...a lot.
In completely other news, the Krita project had a kickstarter which eventually made it's goal of 15k pounds which nets 12 features in 6 months. I would like to see the first stretch goal met (30k), but with only 7 days left when the first 15k took roughly the first 23 days, I'm not really expecting it to break the first stretch goal. Either way, I'm still hoping because I really do think the Krita project is filling a need for linux that isn't really covered by any other program. Sure there is MyPaint, or Inkscape, etc. but really those still pretty different from what krita is doing. MyPaint comes off as a simpler drawing program, not quite as featureful, but it's because of that simplicity that I like it. In my opinion, Krita sits somewhere inbetween GIMP and MyPaint, and from what I have heard from some dA artists, they regularly toss a drawing between them to cover everything they want.
On to archiving of texts and comics. Now I have a fair number of manga that I keep (just the stuff I really think I would reread) and a small amount of light novels. Granted, these don't take up the largest of spaces, but for a hoarder such as myself who doesn't buy new hard drives often, space is in relatively short supply. To make a long story short, I decided upon using epub for my light novels and djvu for my comics. Unfortunately, the results were not exactly always reliably smaller, but for the most part it seemed to be reducing sizes via compression and some quality loss (the loss was noticeable, but honestly I spend maybe around 5 minutes per chapter, so I only look at each page for a couple seconds at best). The problem with both of these formats is the lack of adoption, thus there aren't as many programs that can deal with them as CBR/CBZ or PDF. All in all, probably not the most effective kind of archiving, but worst case I could just find all of my stuff again and search for another format when I get sick of being locked to the few programs available.
Still on the topic of archiving, but this time it's about archiving managers like file-roller, xarchiver, peazip, etc. Some people would swear by cli commands and maybe just use tar, zip, unzip, or w/e, but fortunately I am the kind of person who wastes space to have a gui as well as cli program. So with that, I took a look at a couple of different archive managers (FreeArc, XArchiver, File-Roller, PeaZip, p7zip, B1 Free Archiver, and Squeeze). Starting with the bottom, Squeeze was kind of out because of how there doesn't seem to be any development at all, along with p7zip because it's just clunky and pretty much broken. Less standard are FreeArc, B1 Free Archiver, and PeaZip since those are made by other people and don't seem to be in any linux distro. FreeArc's current release is rather stale, having been a release back in 2010, but apparently there is an alpha branch that seems to be updated fairly regularly (latest was Mar 2014). Since the alpha wasn't in the AUR, only the release from 2010, I decided to skip it too. B1 Free Archiver is one I have pretty much never heard of at all. As far as I can tell, it's supposedly a QT application with half the gui conforming to the native desktop and the other half sticking to a hard coded theme I guess. Makes it look really weird with some themes, but it does seem to have some nifty features (a preview panel that can preview files inside archives). It also doesn't seem to have any dependencies on other stuff so possibly it doesn't need unzip, 7zip, rar, unrar, etc. packages to work, not that I'm going to try it. Then there is PeaZip which I have heard of a couple of times, but it has dependencies on lib32 packages for whatever reason and so I decided to also skip that one. It's a rather biased reason to skip a program, but honestly if it requires more packages, especially lib32 ones that probably won't be used for any other program, and does the same function as standard archive managers that integrate with the normal stuff, there isn't really a need to get peazip at all, with the only exception being that you just NEED peazip in your workflow...which I don't. That leaves us with two of the regular stock archive managers in linux distros: XArchiver and File-Roller.
XArchiver and File-Roller pretty much do as expected, though I find that I like using file-roller more despite the fact that it looks completely non-native thanks to the gnome stylized interface. So in the end, I only really found three archive managers that I deemed worth looking at and really there doesn't seem to be much of a problem with any of them aside from picking the one that suits your tastes (although, the B1 Free Archiver does have it's own format...that no one else uses).
And so, out of the random time spent derping around, nothing really much was found interesting that I could really consider productive, but meh it's a new post.
First off was the Steam sale, which in my opinion was meh. The only real reason I have Steam was because of the free games that I happened to amass during my random raffle entries. During the entire sale, I only got a couple of games that I really felt like I would play, primarily looking for local co-op games so my brother and I could play if he visits or if I visit. From this standpoint, Steam is kind of convenient because I don't need to really bring anything except maybe a controller if I really want one. To list off the games, Castle Crashers, Dungeon Defenders, Dust: An Elysian Tail, Forced, Megabyte Punch, Sanctum 2, They Bleed Pixels, and the Trine series. I've only really tried Dust, Megabyte Punch, and They Bleed Pixels so far, but I'm really enjoying them, thus the sale wasn't a complete flop for me. Only down side is that maybe half or so aren't on linux which kind of sucks...a lot.
In completely other news, the Krita project had a kickstarter which eventually made it's goal of 15k pounds which nets 12 features in 6 months. I would like to see the first stretch goal met (30k), but with only 7 days left when the first 15k took roughly the first 23 days, I'm not really expecting it to break the first stretch goal. Either way, I'm still hoping because I really do think the Krita project is filling a need for linux that isn't really covered by any other program. Sure there is MyPaint, or Inkscape, etc. but really those still pretty different from what krita is doing. MyPaint comes off as a simpler drawing program, not quite as featureful, but it's because of that simplicity that I like it. In my opinion, Krita sits somewhere inbetween GIMP and MyPaint, and from what I have heard from some dA artists, they regularly toss a drawing between them to cover everything they want.
On to archiving of texts and comics. Now I have a fair number of manga that I keep (just the stuff I really think I would reread) and a small amount of light novels. Granted, these don't take up the largest of spaces, but for a hoarder such as myself who doesn't buy new hard drives often, space is in relatively short supply. To make a long story short, I decided upon using epub for my light novels and djvu for my comics. Unfortunately, the results were not exactly always reliably smaller, but for the most part it seemed to be reducing sizes via compression and some quality loss (the loss was noticeable, but honestly I spend maybe around 5 minutes per chapter, so I only look at each page for a couple seconds at best). The problem with both of these formats is the lack of adoption, thus there aren't as many programs that can deal with them as CBR/CBZ or PDF. All in all, probably not the most effective kind of archiving, but worst case I could just find all of my stuff again and search for another format when I get sick of being locked to the few programs available.
Still on the topic of archiving, but this time it's about archiving managers like file-roller, xarchiver, peazip, etc. Some people would swear by cli commands and maybe just use tar, zip, unzip, or w/e, but fortunately I am the kind of person who wastes space to have a gui as well as cli program. So with that, I took a look at a couple of different archive managers (FreeArc, XArchiver, File-Roller, PeaZip, p7zip, B1 Free Archiver, and Squeeze). Starting with the bottom, Squeeze was kind of out because of how there doesn't seem to be any development at all, along with p7zip because it's just clunky and pretty much broken. Less standard are FreeArc, B1 Free Archiver, and PeaZip since those are made by other people and don't seem to be in any linux distro. FreeArc's current release is rather stale, having been a release back in 2010, but apparently there is an alpha branch that seems to be updated fairly regularly (latest was Mar 2014). Since the alpha wasn't in the AUR, only the release from 2010, I decided to skip it too. B1 Free Archiver is one I have pretty much never heard of at all. As far as I can tell, it's supposedly a QT application with half the gui conforming to the native desktop and the other half sticking to a hard coded theme I guess. Makes it look really weird with some themes, but it does seem to have some nifty features (a preview panel that can preview files inside archives). It also doesn't seem to have any dependencies on other stuff so possibly it doesn't need unzip, 7zip, rar, unrar, etc. packages to work, not that I'm going to try it. Then there is PeaZip which I have heard of a couple of times, but it has dependencies on lib32 packages for whatever reason and so I decided to also skip that one. It's a rather biased reason to skip a program, but honestly if it requires more packages, especially lib32 ones that probably won't be used for any other program, and does the same function as standard archive managers that integrate with the normal stuff, there isn't really a need to get peazip at all, with the only exception being that you just NEED peazip in your workflow...which I don't. That leaves us with two of the regular stock archive managers in linux distros: XArchiver and File-Roller.
XArchiver and File-Roller pretty much do as expected, though I find that I like using file-roller more despite the fact that it looks completely non-native thanks to the gnome stylized interface. So in the end, I only really found three archive managers that I deemed worth looking at and really there doesn't seem to be much of a problem with any of them aside from picking the one that suits your tastes (although, the B1 Free Archiver does have it's own format...that no one else uses).
And so, out of the random time spent derping around, nothing really much was found interesting that I could really consider productive, but meh it's a new post.
4/11/14
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):
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.
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.
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):
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.alias ranger='nohup urxvt -depth 16 -e ranger && urxvt & exit'
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.
4/10/14
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).
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).
4/7/14
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.
4/4/14
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).
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.
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).
Subscribe to:
Posts (Atom)