I'll buy a fucking new laptop

I just noticed some weird hissing sounds from my graphics card when switching windows and entering the graphical mode via CTRL+ALT+F7. This isn't normal. I defintely need a new one. But why does this happen now? I found the an editor called medit that is so far the fastest if it comes to rendering and scrolling through files. Except page scrolling. It's even slower than in gedit. However, it has all necessary options I could possibly need, including a better tool integration. And, that's the draw back, some settings don't work, the dialog is screwed and doesn't save/aply options very often... It's still a 0.9.2 version, so I hope they get rid of this stuff so I can use it eventually. I'd like to use it! It has everything I need - almost like an exact copy of CodeBlocks editor settings/features I always used to no end. Good stuff! Keep going devs!

And I need to get a new laptop... One completely Linux-compatible, modern, affordable and of course comfortable to use/type. *sigh* I'll try to get a thinkpad-like joystick/knob in the middle of the keyboard, if IBM still produces laptops with them. I adore this tiny nub!

Plan 9

There's an interesting article about Plan 9 one Wikipedia, an attempt some kind of a Unix successor, it's worth reading it.

Synaptic replacement

Very, very often I was angry about Synaptic taking AGES to find packages or just loading up while freezing everything else currently running in a graphical interface mode. As I often clearly pointed out, modern GUIs are just eyecandy with less efficiency. I like eye candy for everything that's not just a functional computer interface (like in video games). But everything else is often suboptimal and not really entertaining. I always there was no alternative to Synaptic as APT manager, but I was so wrong. Wikipedia did help me. I must be a fool to assume that there is no alternative to such an essential tool like apt. What I found was aptitude, a terminal app for managing apt packages of great performance compared to the slowly sulphurating Synaptic manager. I'm pleased that it uses ncurses, this way you can always have a very simple graphical interface that works efficient on the terminal. Of course, aptitude also takes it's time - but siginificantly less than any operation in Synaptic. I'm kinda suspicious towards Gtk apps recently. A lot of them have horrible performance on older machines. And since my T30 isn't the most efficient processor, I'm sure that this combined with my not-so-performant graphics card is the reason for many slowdown with modern software. I should also take a look at ncurses eventually.

So there you go, Synaptic. You're not worth my time.

Big fat rant

This fucking Gtk+ theme stuff I'm currently trying is just rididulous. In theory, it's the most simplistic thing ever, but in fact it behaves weird, doesn't generate any error output when applying themes and is documented like if it's able to cope with every piece of error that could encounter in a config file. I don't say Gtk theming is poorly documented, no. But why the hell does fg[PRELIGHT] or bg[PRELIGHT] only work work when put in a single style for a button, but not in a general style for all widgets? It's so weird, it makes no sense. I'm close to using only console apps and skinnable non-Gtk GUIs. It's pissing me off, totally. It makes no sense to edit themes if there is no way to get them work as documented. Some day, if I created enough custom terminal and SDL apps to replace everything that's annoying me in the world of computing, I'll compile my own set of Linux software completely from source with only the few things I actually want on my laptop. No stupid toolkit stuff, no overly blown libraries, just pure and effective, totally customized workspace. I should totally take a look at some from source compiled distributions like Gentoo or so. Even if I can choose only the stuff I want, there are still tiny but significant problem I'm having with the stuff I like. For example, some terminals have a lot of problems with updating the title bar with the current programs, fuck up the german ä, ö, ü, etc. I'm not quite satisfied, with almost everything. And again, I see how important it is to finally do some bit of work. Of hard work.

Also, hard work: I think I should integrate an xml parser and html/css ASCII renderer in my engine. Everyone knows it, including me, and it offers a simple variety of interesting visuals/object ordering. It won't be the most complete rendern, especially cause I technically can't add interactions and so on. I rather thought about using css for styling and html for arranging buttons and objects. I don't want to invent the wheel again and HTML is imho a nice way to go (limiting HTML to it's very early beeing of course, with no weird script and interaction shit).

no so code browser

I could have seen this coming. ECB is -of course- for Emacs, CScope sucks, SourceNavigator isn't avaible via repositories, CodeBrowser can't be compiled due to never-mentioned development libraries dependencies but doxygen works like always. You know what? I think doxygen is enough. I can use lynx for quick rendering of the hmtl output. Thought I'm not sure if lynx visually and logically supports all the stuff doxygen puts into html files... We'll see. At first, I need to find some more doxyfile documentation.


I had a phenominally weird idea recently about a double-barreled Lego gun you can muzzle-load but also shoot with multiple bullets in one barrel. It would a type of ammunition where projectiles of bullets behind the first one can also fire directly through the already emptied cartridges. This ammunition would also require some kind of special trigger pin that is accessible from the side to not hinder the barrel/multi-chamber for perfect bullet guidance. Bullets would be triggers from the side, this way, and have some kind of hammering/releasing system that works with just one trigger. It would have a fixed number of bullets, a hammer for each bullet and decreasing range/power for each bullet, cause bullets behind the other would need a longer way to reach the muzzle.

I'm proud of this weird concept- It is too complicated, has too many flaws and will probably never really work well enough to be worth making. It is also interesting cause it takes advantage from the fact that my ammunition usually is a barrel itself - only shortened and powered with a rubber band.

I like the idea and will keep it in my heart to convinve myself from time to time what weird stuff is possible. And I somehow don't want to make a hammer/trigger group for mysingle-shot straight-pull bolt-action gun (I love this long description). I mean it looks and works great, but I have other things I want to do at the moment. I'll just put it on the end of the list, still beeing able to make it in my holidays.


Code browser list

I'm assembling a list of C++ code browsing utilities. My goal is to a find a tool suitable for replacing most build-in class browser of modern IDEs to complement command line editors like nano or JoE. Though they are seperated from the editor, I'd like to have some kind of "intelligent" tool, that automatically scans for changed source files and thus updating it's database. If there something like that, I'll surely find it out. So let's start with a simple list of code browsers:
  • ECB - Emacs Code Browser, a bit over the top?
  • CScope - Looks interesting, seems to be build into Vim.
  • doxygen - Well, I'm already used to doxygen and after reading some forum posts I'm convinced that it's definitely a good browser for all the code I already wrote. No real need for realtime this way.
  • Source-Navigator - Seems useful, but wayyyy out-of-date (last update was from 2008).
  • Code Browser - As simple as it is, interface-wise, it looks appealing and reminds me of a, to me, very familiar tool for windows . Functionally, it's of course different. I'm exited to test it out!
Unfortunately, this list is rather short. I found some commercial alternatives, but I'm not happy with giving money for something every programmer could need but is freely available on the web. Since I totally switched to Linux for development, I appreciate every kind of free software, especially if it's well-designed in form and function. So next day I'll sit infront of my laptop, I'll test out every browser in this list and check if it's worthwhile. Atleast doxygen could as a bare minimum. You know, it takes some time to compile it everytime. Fortunately, we can speed it up by unchecking the charmingly well-rendered function graphics and some other cosmetic changes.

I'm so excited to test Code Browser! And I don't even know why...

Mastering nano

I decided to get comfortable with nano and learn how to write more efficient with it. That means I'll naturally reduce the amount of overly long lines, customize all keyboard shortcuts so that they work better for me and convert necessary in-line-copying to per-line-copying (nano's copy abilities support copying line-wise very convenient, but lacks a simple excerpt copying within single lines or blocks beginning or ending in the middle of the line). The problems I had with no nice clipboard support with xterm can be solved by editing multiple files inside nano, using multiple xterm instances, etc.. It's nothing nobody can cope with. Compromises are always different. I accept too few of them to complain about tiny things like that. The point, I should support minimalism in personal coding since it's what my personal rules embody. Nano is small, supported on all (yes, most, but still) linux systems and does even on the slowest machine available. That brings me an idea: is nano availabe on the Pandora? And if so, also the latest version? According the this wiki article, it is atleast available in some version. However, if it's no the current version, I'll just try to port it. The source code is free, so there shouldn't be a problem to just port it by choosing another compiler. I haven't yet seen the code of nano, but compiled it have the latest version. Also, Pandora seems to have gcc installed, so there shouldn't anything different, right?

It seems quite simple to install stuff from source on Linux: ./confige, make, make install. I know this doesn't work if the build system is different, but most setups should just do similar steps without caring about installing a custom build system. I use cmake, though, so maybe there's some kind of "installer maker" for cmake, which I'd appreciate. It was the first time I compiled a foreign Linux program (used packages before), so hooray for such simplicity.

There are still things that I also thought were necessary, but in the end I only use it to lookup while I'm bored or need to access some informations. Such things are line numbers, a class browser, mouse scrolling and no graphical scroll pos visualizer. Line numbers aren't as useful, especially if there also a goto feature. It you just need to find the next error, it works totally fine and the current position inside the file (current line/total, current byte/total). A not-existing class browser can be replaced with a standalone one. I also discovered the ECB (Emacs class browser) but I'm not sure how comfortable it can be used. It exists, and so do alternatives. The last points, scrolling and missing scroll visualization is something I usually use very often. I'm used to just browsing through files like a wild man - maybe it was never necessary? Sitting down and thinking about the problem often results in more useful solutions than browsing files instead. This way, nano could maybe help me to get rid of that. The more I think (and test from time to time for sure) the better it gets, I never experienced something different. A fruit only ripes with enough care and regard.

Everything else doesn't come to my mind currently. I must say, I didn't motivate me enough to actually to something Linux-related the last day. I got some kind of horrible skin-related, so called "super infection" on my head (I think my physician does dramafy it a tad too much). This infection brought a permanent headache and extraordinarily annoying movement restrictions. So I wasn't just in the mood for actual programming activities and so on. Instead, I enjoyed my pretty good maths book (I don't even have to think while reading, it's a pretty good one) and played Fallout 3. And I'll probably you with cause it's easier to manage my day this way. Don't think I'm a all-day-sitting-here-and-drinking-coffe programmer, no. I tend to walk around all day an theorize all kinds of possible code movements until I found the best solution I could come with at time. I'm rather mobile if it comes to that, even while coding I like to balance the lack of movement while typing by having something moving around me - like beeing in a train, watching a speedrun or commentless walkthroughs/let's plays of moderately paced games. Yeah, I think it's the fall-off of body in movement which I try to compensate by visually distracting his -now- familiarization to permanent movement. Yeah, let's say I'm some kind of Scrooge McDuck-like person who's walking back and forth in his special dedicated to longtime-thinking.


terminator + nano

So I finally found a way to use a text editor with terminator. nano! nano seems to use a scrolling functionationality that is different from joe, cause joe gives exactly the same weird scrolling problem I encountered with terminator. So it must be some kind of interface bottleneck terminator isn't doing well. That is good to now! So I can shorten the list of possible reason to an interface problem. Terminator is more convenient than xterm, especially because it allows me to paste and copy text from the terminal. Though nano has no integration with the normal GUI clipboard. So this way I can keep nano as terminal editor (it has all basic features you need for lofi coding except line numbers). Joe has too weird keyboard shortcuts for beeing a real replacement. I don't why but terminal editor developers just don't seem to understand the usefullness for a full clipboard integration, clipboards work awesome within mouse-supported GUI editors. You can do so many versatile things with it, but they don't just don't integrate it. A shame. That's why it's still no real solution. Why can't gedit be faster?

Edit: Woowoo, wait. Instability, instability whenever it likes. FUCK. Still xterm, damnit. Can't Linux be more mature today? However, I can still use nano. Only thing I have to do now is to find some alternative keyboard shortcuts. The default ones don't really work all the time.


I'm currently reading an interesting article about nano, one the few editors I know from my previous Linux journeys. I like nano, thought it is really just a basic editor. As it seems, it can also highlight C code, which is kinda the same to C++ except some keywords (which isn't so important I think). I hope it can do more! I'd love to replace gedit with it (yeah, I'm still hopping like a madman with varying motivation).

I also want to get a full-featured desktop environment again. And since ATI still sucks on Linux, I guess I have to hop between them or just get a previous Ubuntu version or so. If nano works better as a terminal replacement than joe, I can code anywhere with gcc, make, cmake and nano. And since there are soooo many different distributions, window managers, unsupported hardware etc, I think it's really better to start a complete change in development environments (which didn't really work before).



I didn't work on the hammer/trigger part, but I finalized the bolt grip. It's rather big but quite comftable to operate. My sister called it offensive-looking and not easy to use, I really don't no why. It's just like a big grip you can pull with three fingers. It is more important to be able to push and pull powerful than slipping in fast. We aren't in some kind of zombie survival sandbox, and I don't think she does quite understand how I differentiate Lego constructions and what most people see in these constructions. It is not just a one-person problem, it is something I can see in general that many people just don't think behind their shell and always categorize gun-resembling models as weapons. A weapon is a device harm, threaten or kill people/destroy things or both or anything else doing bad things. And now listen, world: I don't build fucking weapons, I build brick accelerators using guns as a technical base, that's it. The terms gun and weapons should be differentiated officially and socially so that these morons understand when a weapon becomes a weapon and why. Stupid folks.


different sizes

Ok, I did some more concepts for the trigger/hammer group in my current gun model and it seems that I need to make a 5 holes wide grip (or atleast where the hammer is). The problem is just that I can't get every piece I need to form the hammer shape (a quite complex shape not archievable with standard technic pieces) in a 3 holes wide grip. And 4 holes is just annoying for a 5 holes wide gun. They don't work together without special parts - I already did this, it's not worth making again. There are several ways to continue:
  • Make grip completely 5s hole wide and stick with such a bulky design
  • 3x3 for grip, 5x5 hammer, choose one size for trigger
  • make trigger long enough to put hammer behind the hand (kinda ugly)
Guess I'd stick with either way one or two, probably way one. I'm not sure. Step three requires something rather unusual I'm not sure about. And it would probably interfere with the bolt.

It's tricky. But the more I think about it, the close I get to a final result. I prefer this step-by-step decision reduction because it's often successfull compared to other methods. It may be slow, but it's definitely very effective and teachning, too. Doubt every solution unless it's already the essence.


my constness

non-const const is evil.

A word about typecasting

There are always fundamental things in C++ you never get immediately. Some get revealed when reading about it, some via testing and more often by encountering specified problems involving such fundamental techniques/concepts. Typecasting is what everybody should know about, in every programming language with type casting support. But when creating your own arithmetically operatable, you'll face some details that can easily confuse you, like Typecasting from one user-defined class to another. I didn't really understand why C++ had it's own typecasts. I just used them as a different way to structure brackets. Then I read about some general rules how operators need to be designed to work like build-in datatypes (you know, all kinds of operator combinations) and saw a really interesting thing used: an anonymous instance of the class placed on the stack. It look like a typecast and at first I thought it would be some kind of... trick. I realised that it doesn't create just a new object via "new" or so and further reading revealed that there are strict rules when which class will be allocated on the heap or the stack. But today, when it came to using my classes I hadso much trouble with to implement, I realised how actually dead-simple it is. Of course do I just need to make operations between instances of a class (not two different classes). If you created constructors with other classes as parameters, you can simply cast from these classes! t feels like beeing struck by ligtning. It makes handling with different operator-based classes sooo simple... And I didn't see it... Of course. How could I know of it? I feel so stupid for not seeing this before. It took me soooo much time and even more nerves to come to this point where I currently am, and what now? I realized how useful all this was. No, it wasn't useful. It was just a long and painful way of realization. It's ok. Atleast I know now how it is usually done. And I can definitely use this for every other C++-like OOP language I'll ever program in. Good to know. I just don't like figuring out a problem and then suddenly realising how language-specific this was.

to where I belong

It's actually not so bad using only half of the screen for gedit (which is surprisingly fast when working with smaller windows) and the rest for compiler output. A browser or CHM viewer for references beside and everything is well. I immediately felt satisfaction as soon as SDL's familiar HTML reference popped up. What a wonderful library. Pure love for everyone!

firefox ad

While browsing the webs randomsly, I encountered this awesome firefox ad. I really had to laugh, a rare laugh I don't often encounter! Although I'm not quite satisfied with it's performance on my low-endrig, it's still better than any graphical browser I encountered. And let's face it - there aren't so many actually comparable browsers. I haven't yet tested Opera I have to say. Mostly due to the fact that I don't want to add some kind of weird repository.

Which reminds me of the fact that I definitely not want to make my codebase open source.




the ultimate, completely feature-controlled ASCII window manager

Yeah, you read it. I don't have the knowledge nor interest to actually pervert pixel-based user interfaces, but wouldn't it be an interesting idea? Like if the computing world decided to stick with screen text only bitmaps rasterized to multidimensional character arrays. I love the idea and created a concept of an efficient, minimal window manager design that is equally mighty with both mouse and keyboard, has support for extremely complex control structures and features a fixed stylization/font. I got a lot of ideas which I can definitely integrate in a graphical user interface somewhere - especially in one my text game would also use. Yay, I like the idea. Although I'd still prefer a pixel-based environment for everyday use.

A new laptop, maybe

Well, I resigned. I'll probably need a better laptop with better graphics card, faster memory, newer hardware, etc. Stuff's getting slow. I miss CodeBlocks so much. Otherwise, it's worth using other tools just because you learn more. As long as I don't have a new one, I'll jump between gedit for comfort/lazyness and joe for general coding. My problem with CodeBlocks is that I'm sure how well it supports external makefiles and CMake. I can stick with editor + command line (even gedit has a symbol browser plugin) but I definitely don't want to go back to IDE-specific build systems. I believe there is a tool for viewing symbol in C/C++ files as standalone applications. I found it somewhere but didn't try it. That could be really useful when editing using joe.

Damnit, I can't find it. I'm doomed.
Now that I customized even more stuff in CrunchBang, I forced myself to a) solve the font/graphics stuff problem or b) to get another editor. OpenBox together with tint2 is really a breeze to edit. I completely revamped the whole menu and made customization even more comfortable via some additional menu entries for killing and restarting all kinds of customizable services. Ok boy, go on and find some better editor.

early MacOS

Did I ever mentioned how much beaty lies within the simplicity of early MacOS interfaces? So simple and clean. Though I still don't like singleton menus.


Half through the model

Yay, now most of the model is done except the ergonomic part (hammer and trigger, I think I mentioned that before?). I also added a second rubber to the bullets to enable really powerful chambering (it still happened pretty often that some bullets were before beeing triggered). Most of the time I was lazy, watching Darkwing Duck and playing the first Stalker (Wonderful game I have to say! Still quicker and funnier to play than the later parts of the series!). But I designed a trigger that should work well in theory. I'm not sure how to get the parts I need, but I'm sure I'll find a way to put them together. I will have to redesign the whole rear part and combine it with a grip case. I should always plan carefully where to put the trigger and the barrel together. Fortunately, I can simply lengthen it as much as I want, so I won't run into problems of mixing old parts with new ones that don't fit together. Grip will be 3 studs width (as far as it is possible). But maybe I'll have to choose a wider format (the idea is... "fat", like having too much grip in your hand). I also decided to design a pistol grip at first add a foldable stock later. Not sure which style! Since the bolt needs still to be pulled for operating, I can't just stick a stock there. I'd also not want a broomstick at the grip. Really no idea. I can wait, though. Simple grip is more important.


Fine, fine

Yay, the best idea ever to operate my bolt-action models. Only thing I need to do now is a hammer, a trigger, a grip and so on. But not for now - it's always better to stop for a while after each milestone. I'm really glad I finally did the first half of an actually working bolt-action model! And it works gorgeous, not to say perfect. Finally something with a cartridge that is small and doesn't suffer from annoying problems. Hey, I'm gonna choose a nice stock for it! I've also chosen a general color concept for this model:
  • Grey for barrel and bolt
  • Dark Grey for lock
  • Black for chamber and surrounding metal
  • Red for all grip elements
I hope I can color everything like above. If so, this one should stay as a motivational example in my display case. Or atleast at some place where I'm afraid of taking it apart... So yeah, grip and trigger design. Hm, where to look for something like that? I have several rounded, plate-like parts I can use for stock and barrel grip. I'm not sure: a pistol grip with stock or just a big stock with? Trigger combined with stock/grip or as a single part? I don't know. Time to explore the internet! Dude I love looking for new stuff I don't know or just looking for interesting component combinations. The good thing about guns is that you can almost everytime see which component it uses. It's cool and at the moment much more interesting and revealing than development/programming research. What I'll definitely need is some king of long stock to rest the gun on my shoulders while reloading. It's a pain to operate without. Heyheyhey, I also had he idea of a foldable stock once. A foldable stock is useful for decreasing overall size and for aiming more freely/comfortable. I don't know. I'm sure a foldable stock that doesn't block the gun from beeing usable is kinda difficult if I actually want to use red parts for the stock. Not because of the color, but the plate-like pieces I want to use. They feel more comfortable than beams, even if they lack grip (which I don't really need without recoil!).


damn it, this fucking is driving me nuts all the time! Everything works perfect so far - found a great and small way to lock the chamber, inserting bullets does also work good now (use a rubber in a special position), there's an awesome little, flexible barrel... All could be so shiny if there weren't the problem that I somehow need to pull and push the bolt itself. The bolt grip does this usually, but there's just no toom anymore for a bolt that makes powerful extraction possible (and exactly this is what i need..). I don't know how to solve it! I abused all pin holes on the guiding rail for the lock and bolt pushback. AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHH.

Ok, I feel better now. There are several alternatives: top-mounted grip with hole for iron sight (somehow interesting idea), higher bolt for pistol-like rechambering (could interfere with firing pin when pushing the chamber from behind -> accidental shot), a grip at the end of the bolt (like a big big you can operate with a few fingers. I don't like the top-mounting and the pistol-like chambering isn't comfortable enough. So I'll instead stick with a big ring at the end and will probably have to tinker with a groove for the hammer to slide inside the grip piece while it's directly at the position where I previously thought the hammer to take place. On the plus side, this would enable pistol-style sliding, too! Well, atleast in theory.

Now it's getting difficult. Firing mechanic, locks, chambering etc is rather easy. But building a comfortable usage around it? That's far more difficult. I see that it's putting me in rage when I, all of the sudden, forgot to think about the ergonomics. Another problem is that the extractor extracts cases towards the shooter if he doesn't rotate the gun in another direction. So I do of course need a proper grip to extract and chamber! It's wicked to know off a shooter with his own bullet case. I go so many ideas for tubular magazines while thinking about how to design the extractor yesterday. I want to make a real pumpgun! I found an interesting model, the Winchester Model 1897, which is also called "trench gun", since americans used it trenches during war due of it's short-ranged effectivity. I like the design and how inner parts extend when extracting a bullet. Of course, my design would be rather short on magazine capacity, but almost every part of this gun is like the concepts I had in my mind while thinking about how I could properly chamber bullets in a single-shot straight-pull bolt-action (what an ugly combination of combined words).


Solved the problem by using a rubber band attached to the site, preventing the bolt from sliding to far beyond the extractor's fixed part. Now you can simply hook the cartridge into the extractor and chamber the round comfortably. There is still of grip to operate from the side. Next challenge is the lock itself. Everything works fine so far, it is quite decent to operate at the moment. It pays off to measure every part and not how it should look in your expectations. The lock it REALLY difficult to design. At first I tried the external lock I had on my break-open cartridge rifle. It was ok for an already bulky 4x4 caliber gun, but since the extractor consumes quite a lot of space and I can't quite get it inside (there is just no room without blowing it up) it is an awkward way to attach it. Maybe I should flip horizontally and/or vertical to get more place to support the stability a lock requires. That would solve the problems I had so far, I guess. Using longer lock hook to place them somewhere else where are possibility to attach it isn't satisfying. This way the lock doesn't even survive one chambering. It requires a strong, single-piece L beam to serve here.
Ok, so far so good. I have a working extractor, was careful with measuring the length of each part (bolt, extractor, cartridge, guiding rail for bolt etc) and it works quite well and is easy to operate. There is only problem: reloading. The problem is that the extactor I'm using is contructed in a way that it doesn't hook into the grooves while chambering. I had to make the extractor more or less fixed so that extraction itself works but inserting a new bullet requites hooking into the extractor hooks. Such an extractor requires something that works as a corner that's not moving while the extractor pulls to bullet case (this way to bullets gets thrown out of the gun). And exactly this fixed parts is what's bothering me. I has to be BEHIND the place where you put in your bullet, so pulling the bolt forces the bullet to get ejected. Sadly, if you extracted the bullet, you also pulled the bolt too far in the same time! In reallife they solve this problem simply by using a special extractor that can hook into the bullet grooves while chambering, or they reload bullets from the ground with fixed extractor (via magazine), or use a rotating bolt that also rotates the extractor hook. The last point is a bit useless for what me cause I can't create a rotating bolt.

One ossible solution is to make an insertion from below via a little tubular magazine that holds only one bullet and pushes this bullet immediately into the chamber. I don't like this idea because it is bulky and complicated. I don't trust this idea. I'm sure it will not work properly.

Another is a pair of springs to move the bolt back to a position perfect for insertion after extraction. I can add springs to the side inside the bolt's leading rail, with some engineering effort of course. I don't both ideas. A solution with rotating bolt is the best idea, but unfortunately the most impossible.



I came to the conclusion that it's the best to switch to a so called "straight-pull bolt-action". Since LEGO guns do not need closed chambers and just need something to lock the bullet, I had this idea of just having a non-rotatable bolt. And I'm surprised that there are actually a reallife models using a straight-pull way. What I'll do is more like a semi-automatic pistol with exposed hammer (except the semi-automatic, of course). I'm sure how I'll design the bolt itself, but it'd be definitely possible to cock it manually it the hammer fails releasing a shot. The bolt will be too large for operating it comfortably every time when ejecting. And it's also better to a have grip when ejecting bullet cases, especially because LEGO bullet cases tend to be bigger than their reallife counterparts. And I found a way to lock the chamber/bolt properly! I'll just reuse the lock I used for my break-open cartridge rifle. I'm safe for two-way locking and should work pretty well. So I solved all two problems. Well, I'm still asking myself how to attach the flexible barrel properly.Maybe like the bolt.

Improved 3x3/starting new model

Oh, that was worth trying it. One of the few things that always bugged me were the front parts of all bullets I used in my prototype. I used big L-shaped beams as stabilizers which works quite well for what it is. But shooting is actually more difficult depending on it's angle. That's due to borders, less free space around to bullet when beeing accelerated etc. I've choosen a concept I already used in a previous variant but actually never trusted it. This time I took several elements of previous 3x3 ideas and combined them into a robust and powerful case. It shoots far enough and it rather short compared to all previous versions. Somehow, stretching the rubber does really not work better than just using a stringer one. I don't know. I tried so many things, it's just better to think about it so often.

However, here's a detailed list of goals I've set for the next model:
  • single shot, no magazine
  • chambering with bolt-operation
  • external hammer pushed back by bolt instead of internal one
  • flexible barrel for soft chambering
  • reliable, fixing lock mechanic for bolt
  • half-cased bolt with guiding grooves in the case
  • bolt circa a half longer than the bullet
  • more stable bolt
  • reliable ejector based on common
General simplification and seperating single groups.

Will take some shots of the bullet I think I'll use. I'm not sure about the ejector. No idea how to make it this time. I'm also not sure about the bolt locking. Two things I can work on.



I got myself interested in actually reading about the D programming language on Wikipedia and the offical site about it. D is interesting because it takes stuff away that made C++ weird und unuseful at some points and added a lot of concepts and system I never heard of nor used it. I'm still a young programmer and don't know much about concepts other than the ones I used or designed. I know I'm rather a purist and like to control every bit of code I'm writing or using. I'm using a library it's OK to only on what the library does since I use it cause of that. But reading about D beeing able to use concepts like garbage collecting or metaprogramming (which I both don't seem to like, the garbage collector is for sure not my philosophy), I'm not sure if I actually want to read further about it. Not that I will stop thinking about using this language, but it makes me wonder - especially in the context of D beeing designed as a language made of practically used elements - if some features are really useful. As the site states, the development of D is determined by the community. It's not that a D project uses all of D's features. In fact, there are many programming/development styles that are usually executed alone, like OOP vs. imperative programming. But well - like C++ it's very mixed compared to C and one can only benefit from that. At the moment I prefer some selected OOP features and completely custom memory management without classes/libs created by others except for GUI/multimedia/hardware acceleration. I know why I dislike garbage collection and other thing etc. Mainly because I often see bugs caused because of that. It could also be that I'm biased by how useless such concepts are graphics programming. All of these concepts work well within high level programming code for final arrangements, but as low as levels can go, it get's more and more useless. I'm also a bit... suspicious of code by people whose abilities and preferences I don't know. He/she can be a professor, a lead programmer for a company or whatever else - if it's somebody using concepts misliked by me without thinking about the fact that these concepts aren't really useful for everything in world, I surely dislike this programmer. A programmer should always know why he's using what he's using. Speaking of this, D is a very... varied language as it seems. I'm sure most stuff they are classifying is already used or disliked by me. As I'm a purist, I'm also not a friend of classifying every bit of possible way to develop programs. Of course, it helps when working with other people, but can't this also work by clearly pointing out what one should work with? I don't know. I'm just confused by how many uselessly detailed concepts are there. I'm sure only a few of them are actually used or in productivity.

I'm a bit weird if it comes to programming. I do have my own world for that. It's hard to get other people ethusiastic about it. Most of my ideas and concepts are about generalizing most of the tasks I'm doing, about memory-leak-less programming and choosing the most systematic and versatile solution. I'm not a friend of specialized one-liners or huge classes that work for only on task (except if it's a part you can reuse for something else). But it's also bnot just generic programming what I'm doing. I'm combining it with OOP polymorphism and thus it's rather a concept of versatile minimalism.

Maybe I'm just confusing programming with general development. I'm totally confused by this stuff. I could invent a million of names and descriptions and I'd still fail. I'm not someone who uses a defined concept of tries to force everything into a special hierarchy.

Naa, to hell with that. Fuck paradigms.



Since my program does now work, I want to do something else before I burn out. LEGO is a good thing to start with. I decided to stick with the 3x3 bullet design because it is much more stable than the 4x4 design. Yes, 4x4 in the current is more prone to impact, is bigger and it's range is physically limited due to it's big bullets. That's it, I don't to make big things again. Another problem with 4x4 is that is really, really long and hard to eject. It doesn't have a groove, it can't be varied with increasing length and at the same time decreasing range. No, nothing for me anymore. Smaller bullets make life easier and more stable.

I decided it not only because of the facts mentioned above. It is also important to say that I weightened the pros and cons of going back to integrated bullet accelerators (no cartridge, just one rubber inside). I really thought about the to the too bulky 4x4 design. As I created my bolt-action rifle, I didn't like the idea of 3x3. And as I noticed how instable it was, I didn't want to see it anymore. However, it was still a good LEGO work. I thought about submitting it to deviantART, but it isn't right. It's not a so good model. It's a prototype. I archieved some advanced concepts like an ejector, a magazine and a single-action feeding mechanic. Isn't it worth reusing them? I think so.

Let's start with what to do now:
  • a finalized 3x3 design with grooves and comfortable loading
  • study this page again and look for construction manuals
  • learn from prototype mistakes and fix them
The first two are easy. The last one is more analysation and thinking. The most significant problem was that bullets got accidently fired when operating the bolt with too much power. My idea is to use a flexible barrel that works as buffer if too much power was used when chambering. For this, the barrel must be short enough to move smoothly with several rubbers attached. I think this will work as accidental fire protection. With a flexible barrel that is flexible enough for not triggering a bullet on impact and unflexible enough to still work as a relatively fixed barrel, I should work fine for all guns with bolts closing the chamber via a single operation. And since EVERY gun using chambering applies to that, I think it's a major improvement in design.

Next problems were inaccuracy and to late/never occuring firing. I think this was because the chamber lock didn't work quite well and because I didn't use a hammer, but striking pin directly connected to the trigger. This way it wasn't reliable and you had to guess the moment it actually fires. Using a hammer solves the delay problem. To get rid of non-firing cartridge, the bolt needs to be locked and fixed properly using a bigger that doesn't require a full case for itself. Springs could be useful to replace the destabilizing firing pin construct I used in the prototype. Plus, the flexible barrel can be placed some millimeters closer to the chambered bullet and it presses against the bullet without firing it. I think that's a better solution than the loose connection I had before.

Ultimately, the magazin was a big problem, too. I didn't work flawless, cause there was no speration between chamber and magazine, ejection and chambering. It just had to rely on the magzine's rubber bang and gravity itself. It wasn't a good magazine. It lacked some kind of limiter for bullets inside the magazine to prevent bullets from disturbing the bullet ejection in the chamber above. Now, that I learned whats went wrong (I discovered this hunter education website later), I think I can try to create a new concept and adapt mechanics they use in lever- and bolt-action rifles.

At last I need to decide what to do again. Bolt-action could work with all the modification, but a lever-action is somehow more interesting. Thought I'm sure I'll be more successful when making a bolt-action one.

some more gun ressources

I found some pretty interesting videos from a user/shop/ called MidwayUSA on Youtube. It's a bit like a Do-it-yourself show, which I kinda enjoy because it shows many details about guns I haven't seen before. For example, how one can load a modern lever-action gun or how a break-action shotgun looks in details when disassembled and so on. It's a bit like the one Youtube channel I found where you can learn to speak like an American. I quite like it so far! Helps to fills some knowledge gaps I couldn't fill while reading about how these guns work.

I also got a really interesting idea about how to a hammer automatically several time by using a single rubbber band. I'm quite interested in it, because it could be a key to an automatic gun without a motor.


Programming can be so pleasing if there's a logical solution. I learned some more bits about operator overloading and why my classes never worked like they should. My lecturer's tipps and advices also flew into creating it, I can only say that he really tought me to make good and understandable code. I'm not sure if this is for other students in his course, but programming in Java in combination with his very clear and well-prepared lectures did a positive impact on me.


Um, I think I shouldn't just focus on a tracker. I found some old notes by me about the "perfect music program" I wanted to program for me. I came pretty close to a drum sequencer and pretty close to what the DS-10 already is. And while browsing wikipedia for different trackers, I found Hydrogen, which is an awesome program for how I translate music into structures. It is exactly what I used in trackers and FL Studio, a pattern editor with different channels for different samples, a pattern arranger like the DS-10 uses and a mixer. The mixer isn't just for setting volume and panning, it also possible to set up to 4 effects you can choose from a fairly large list. And all of it in a minimal, clutterless environment. Looks good as a tool composing enhanced DS-10 compositions.


I'm getting a tracker. Atleast I hope I can find one I like, that has low CPU requirements and is free. I'm not a fan of feature-heavy software (I think I also mentioned several times before), so I rather like a basic tracker that isn't to extreme, like, for example, Renoise or other commercial trackers (of which some became free as far as I know). Well, I liked Psycle but unfortunately it's for for Windows. It also had VST support and was some kind of... first step towards FL Studio. At the moment I'm really not that satsfied with FL Studio. It has so many useless features and I can't even get rid of them. And I'm developing a dislike against synthesizer plugins which don't resemble simple ideas and controls. I never used the KORG Legacy Collection that much. That's mainly due to the fact that I don't like to sit hours in front a plugin just to make one channel sound right. And feel bad for feeling so. In fact, you there isn't one song I finished using it. I think there's one track lying around where I used it heavily, but I'm not sure if this track does actually exist on my hardware. Could be that it crashed together with the harddrive I used to transfer dat from my old PC to the new one. I really don't know. However, I bought this collection and I don't have to give it back. I'm listening to some old tracks of mine and think I just forget about which tools I used to make them. FL Studio is so full of features that I never really know what to do. It would be great to have a customizable interface with only the stuff you really need. I miss the power of free-for-all open source software in it. Trackers are much simpler and should support the simplicity of the DS-10. As a sampler which vertical timeline. If there's one tracker that is modular and simple, I will try it.


I created a really beautiful, round and transparent taskbar for my workspace. It is good that CrunchBang has so simple but multifarious software. It feels lovely to look at.



Hey, Gedit does also look for a make file and redirects the output to it's bottom pane when compiling! EEYAY!

What I previously wanted to say is that is may be better to use minimal GUI programs for feed reading and mail management. I'm a Google Mail user for several years now and always used the browser window to look for new mails, cause this way I don't have the problem of moving or copying mails to the PC. Via Ubuntu's mail notification applet I found out that there's a way to just read what new mails are available and how it is possible to just read the list and get mails on demand (that's what I understood). If this is so, I want a program that only reads the mail headers and downloads the content on demand. I like this much more.


I could cry. Tried Gedit again and nothing seems slow. CodeBlocks is still killing display speed, though. It uses Scintilly as text area, so I also tested the epitome of scintilla software, SciTE. And as I guessed, it is a similar slideshow, so the problem with codeblocks is that it uses SciTE. However, after I deactivated conky on Openbox startup, everything worked fine in Gedit. I was wrong. So wrong. And I see where this is and was going. I feel so bad. You can never really determine which component does trouble in a computer system, except if it's so heavy that you can detect it in the task manager/monitor. I'm somehow happy about the fact to have mouse-controllable editor. I like my terminal setup, but for multiple opened files it's just too weird to work with joe. Especially copying from one file to another or just creating a new one in a specific place. There is no folder view and so. It makes development slower. I like joe, but joe is also blind. And I really don't want to rely on blind people in a world of truth-indicating LED lights. Blindness has it's advantages, too. I'll mix both and take their good part. GUI for editing and managing, command line/terminal for compiling. Keep it simple, keep it stupid. A GUI comes close to that. I'm sorry joe, but we can still be friends. I learned a lot of his keyboard shortcuts.
Firefox is pretty slow. I don't how about other browsers, but Midori for example is faster. There are actually performance tweaks for firefox available and stuff like Fasterfox does actually make it faster than before. I'm not sure about WHY Firefox is so slow if you install it. Atleast it is faster than before and will probably stabilize my system a bit. I can need every bit of performance that's available. And all of a sudden does compositing slowdown the system. Isn't that weird? I dont know. I lost every trust in determining the speed of software other people wrote.
Deactivated conky, customized the taskbar, etc... CrunchBang is getting nicer. And if I can't get it exactly as I want, I can only make it only better to control and feel better. Maybe it's just conky that is screwing up the whole thing. I don't know. Just shoot everything that seems CPU-consuming and suspicious to you. The idea is nice, but totally useless. I'm someone who's actually working with his screen size, there is no need for regularly updating CPU stats on my desk. I also enable compositing (transparency effects etc) and it didn't really the overall performance. So it's definitely a pure software problem. I'll do some further tests and look which GUI editors work smoothly to sort out atleast one the many problems I'm facing.
I'll just look for another distribution. At first for my desktop PC and then for my laptop. And before I resetup my laptop, I'll backup all settings I did to customize it. This way I can ensure that I can always go back a working distribution - more or less, since not everything works like it should.

I also think terminator would be slow on desktop.


What the fuck is happening with my computer? At first CodeBlocks became so slow that I had to use terminal for compilation. Then even editors like Gedit went slow, too (I can remember using Gedit with good performance on Ubuntu). After choosing a terminal editor I even had problems with terminal performance! And you know what? Wine is so slow that even Graphics Gale becomes a slideshow. WHAT THE FUCK IS GOING. Is my computer getting slower? Is his RAM in a bad mood or what? 2.0Ghz should be fast enough to run 10 terminals, CodeBlocks, Gedit and Diablo II simultanously. But in fact, I barely get CodeBlocks working and have to rely on old Xterm. Windows was faster. This must be my fucking computer going wrong.

Can't it just work one time? One time on my entire life? Nothing works. My desktop PC doesn't work with without hours of tweaking, my laptop is starting to get slower and slower and I just can't get anything pleasing.

Why are there computers in the world. Can't we just go back to the good old times of mechanics and electricity without electronics. I'd be an artist or an engineer.



After testing around 20 different terminals I think I found the real problem. Most terminals which are fast during scrolling seem to all base on xterm, which uses it's own kind of font rendering engine (you can also select possible xfonts by running xfontsel). Yo it's pretty lowend but thus almost with any necessary performance. All other terminals I tested used some kind of vte python library (a pretty suspicious thing) by the gnome project and caused the same problem I had with terminator. So it is in fact a problem with this library. I don't why it does such a weird problem but in fact the whole terminal slows down if the cursor comes close to 3/4 of the total screen height. For this time (and this laptop) I'll just stick Xterm, since it has the least weird interface of all and has, according the Joe's homepage, the best mouse integration for it. So yeah, Xterm. Here I come. I felt I'll need you, but I didn't knew I'll need you that hard. What I'll do now is do remove all the shit I installed and try to clean up my system as good as possible. After several hours of removing hundrets of unique compiler errors (I'm rewriting/reintegrating some of my classes for BIGJam) I know what I need - and that's a code editor and some minimal GUI text program like Leafpad. Leafpad is like Notepad except with line numbers. Gedit is just to slow for bug texts on my laptop. I don't know why, but windows has a font renderer with much better performance. I guess that's the difference between vector and bitmap fonts. I think Xterm does use bitmap fonts. Otherwise it wouldn't be so fast. I never thought that it would be so hard to get a smooth development environment working... I also understand why mayn Linux developers use terminal applications - they are just a faster and smarter way to do what they (we!) do. In the end it's just code. Code doesn't need exciting formatting or colorful images. Code is code and a beauty on it's own - so stick with the visual minimum and put offer every other bit of performance to the program you're writing.

Ok, let's stop that sentimental shit and continue with my last-minute setup. I want to remove of single bit I don't need for the BIGJam. I'm almost done and the last I want to find is a GUI editor that is faster than Gedit, has syntax highlighting and can do more than Leafpad... Well, I guess that's not so important at the moment. I should just stick with what's already there and get a smile into my silly face.

Eterm sucks

Fuck it, Eterm screws up a lot of extra chars like ä, ö, ü and ß. What is the benefit of UTF-8 if the terminal doesn't support it properly? Damnit. Ya know what? I'll download every possible terminal. Yes, EVERY terminal I can find my repository list check if it does what it does. I don't want gnome terminal or konsole, they require too much memory for just a few windows... If this FUCKING terminator would work properly, nothing would be a problem. Shitty fuckface java programmers.





This is what my final workspace looks. I decided to completely replace terminator with Eterm and so far it's been a pretty good deal. Eterm is customizable like hell, it seems that it uses the same like xterm, but unlike xterm it dies display white text grey and bold text get's white. Or atleast is this the difference between Joe on xterm and Joe on Eterm. Also, Eterm has transparency that doesn't really affect the actual performance or CPU time, so I can finally enjoy my wallpapers inside my "development environment", too! That's a pretty thing, cause I never had such features within other IDEs... Well, I also got used to Joe's search system and if I remember correctly, there's also some kind of regular expression filter/replacer in it which I rather prefer over an slightly stiff search functionality. mocp is also still awesome and perfect for background music. One day I'll create a system-wide sound visualization tool I can use as an xmplay replacement. I always loved xmplay's visualization for analysing sound waves, but a system-wide setup would be far more powerful. Maybe there's more possible, who knows!

Starcraft soundtrack

Since Starcraft II is out and everybody's is crying how awesome it is, I wondered how the music is. To bring the old music in my head, I installed the original Starcraft again and were kinda shocked how ridiculous the tutorial track (terram theme) was. Thus, I immediately uninstalled (not only cause of that, it's really no game I'm good at or do enjoy to play). So later I found some tracks from the beta on youtube and wondered how different the terran theme sounds without a silly synth. I was curious: how does the new music differ from the old? I downloaded the whole soundtrack and was -again- stunned. This time by how long and well-made the non-terran tracks were. Of course, the terran stuff is just a taste thing... Just listen to the Zerg tracks and you'll find yourself between great electronic experimentation and a really metroidish feeling - especially if you listened to Metroid Prime's soundtrack before. Great stuff is it. And pretty long. Unfortunately, strategy games have a few long tracks which many many parts inbetween and I hink it'd be better to have them as single themes but with extended play time.

In the end most part of the soundtrack is just great, but not suitable for a game. It's great music on it's own but just to short and the themes jump from here to there without a real flow. It's a shame. Really a shame. But well, that reminds me of Diablo, it's the same composer. If it weren't such a slow soundtrack with fewer changes, it would've been to fast and distracting to work as background music. Matt Uelmen does great music, but sometimes it's really no good video game music, just awesome music for itself. Thanks to the anonymous commenter! What a fool was I to just assume that the old Soundtrack was be by Uelmen. There were different composers, so it's a reason for why all three themes behave so differently. Yeah. I feel so bad for blaming Uelmen. I'm terribly sorry!


I'm such a fool

Joe does nothing wrong, CodeBlocks did the comments line-by-line, not blokwise. I'm such a fool. Ok, I'll stick with Joe and work all of CodeBlocks mistakes by hand. I need to do some JOE fanart.

No comment on joe

Well, to finally find the ultimate editor/terminal combination I'm looking for, I'll make a list of what is important to me:

- no weird mode editing
- auto indent, space to tab, smart indent deletion, etc... the whole program
- split view
- syntax highlighting
- text selection (mouse or keyboard)
- find/replace that also works with selected blocks
- line numbers
- customizable
- completely controllable with keyboard
- block indent
- no java/bytecode app

- font changable, atleast the size
- fast line-per-line scrolling
- good performance in general
- split view is a plus but not important anymore (for everything non-dev-related I can still use terminator)
- paste functionality
- black background (yes, that is important for me)
- no java/bytecode app

I finally tried Joe in xterm, but seriously, no block comment/uncomment in Joe? What? I'm so used to all these fine GUI editors, I really miss stuff like that on the terminal. And again, Joe is awesome, but some things are just necessary for me. In the end I could still use it, yes, but especially now when I'm coding vector classes with many similar blocks of operators I can turn on/off, I really depend on block commenting. Sometimes I comment half of the source code cause I know I'll need it some day. And uncommenting several hundrets lines of code is rather annoying I say you. Well, guess I need to go back to GUI editors. They have a lot of comfort if it comes to that and there's also a huge number of them... Gedit is just too slow. Made some intense testing and geez, it lagged like hell when selecting and scrolling. I'd really, really like to make everything on the terminal, but it's hard to find a good editor that is not fucked up like vi or emacs. Seriously, some please ban these monsters from editors lists so I can find something actually useful for me...


No Joe

Joe is awesome, but what is not awesome is that font rendering on Linux is pretty slow. I cannot open a fullscreen Joe without having too slow cursor movement cause terminator takes it's time to render everything on the screen. On windows it was pretty fast, and that has probably to do with the fact that most Linux fonts are vector-based, not bitmap-based like on Linux. I'm really not sure. I don't even know how the exact font rendering on Linux behaves, it it's a font-to-bitmap renderer or a direct rasterization on the screen. However, xterm is much faster I can display any text I want over the whole screen and there is no slowdown. Terminator can also resize fonts size on the fly, but that is equally slow, so it could be just a problem with how terminator handles big areas of text? No idea, really.


Heyheyhey, this stuff seems to work pretty well. I thought took an example file and it automatically generated all dependencies and so for my cpp file! Awesome! So know I'll see if I can make several CMake files with different projects inside and combine them just by specifying the project name. Though I think it's not necessary to do so, cause it always generates all depencies. Let's try some more experiments. I'm sure it's perfect for what I want to do.



Gedit is nice, but I'm just too addicted if it comes to terminal applications. It's strange fascination, where aesthetics and efficient design meets (atleast within my system). I discovered a really wonderful editor simply called Joe ("Joe's Own Editor") that is capable of syntax highlighting, has no silly mode editing like in Vi or Emacs and does a good job of delivering a functional typing environment like in every other proper editor (I seriously hate that silly mode stuff). It has many features you know from normal GUI editors like line numbers, tabs to space, indentation, etc... Almost like in CodeBlocks for me! It has interesting copy/paste system: You can select text using STRG + movement keys. Then you can move the cursor normally and copy text from this selected part elsewhere by using the associated keyboard shortcut. It's fascinating to browse it's help: It can, just like CrunchBang's default terminal editor, split the current opened editing window into multiple ones, so you can view multiple files at once, switch between one and all files, open a terminal window inside Joe, record macros (!) and many, many more cool things. You can even open a terminal inside the current editor window in which all terminal content will be stored inside the opened document (whithout overwriting the file of course). This way you can use the ouput of simpler terminal apps that don't require a new terminal instance (that exclude Lynx, irssi, Joe itself and such) and insert it into the current file. It's great idea, though it is sometimes hard to see where the terminal command line begins inside an opened document cause you can edit every text BEFORE the command line begin but not after (after it becomes a normal command line). It's a bit weird but it's just a small detail. It has -of course- also a search functionality whith regular expressions and Firefox-like result browsing inside the document. One thin I'm quite sure about is the compile&parse and jump-to-error functionality. It seems that it works like a really simple "insert build command with variable arguments" thing, but that wouldn't work if it also has a jump-to-error function. But well, I think I'll rather use a second terminal window for compiling I guess. This needs some more different command line options that just one fixed build command in a settings file.

It looks good so far with developing stuff on the terminal. Only thing I need to manage now is a comfortable way of make/compile a whole project. Someone at TIGSource mentioned that autoconf/automake is pretty common, but that is intended for from-source compiling projects on different platforms. I dont want/need this. My stuff is usually closed source and if I want to publish the source code, then only as it is with some instructions how to compiler. I'm not such an enthusiastic open source developer. So in the I guess I'll just use a makefile or write an own tool for it. The perfect program for me would be program that takes a bunch of files assuming there is only one main function, does scan all depencies, adds you custom compiler options for specific files and create and runs an executable if there were no errors. I'm sure this can be done in a shell script, but I rather prefer NOT to script that way. I don't like it, it's against my coding nature, like using Vi is against what I think is comfortable to type. And I definitely don't have the time to create such a script until BIGJam is here! I want to polish my code base and extend it with plain bitmap rendering and other useful stuff for rapid development. Yeah, totally, but not writing scripts for compilation. Also, I guess all BIGJam challenges will probably 3 hours long, which I rather want to use for actual coding/designing and not for writing make files for all the millions files I have from my toolkits. I need something that enables me to just necessary files to a makefile/project file without spending too much time on it, hm... Argh, I'm sure for THIS task there is no classy app available.

Fuck, I wish there'd some actual USEFUL command line for project management and automatic compiling/linking/debugging. I definitely need to find a better solution than always hacking in makefile lines and copying files like a weirdo.


Yay, I knew it had some plugins, but I never actually looked at what they can do. Geez! Terminal inside a text editor! External tools! Block indent and block comment! Integrated makefile/build function! It seems that I don't need to install codeblocks this way. Using an already built-in editor is always better than reinstalling bigger and bulkier IDEs. Of course they have their nice features, but using common and established methods isn't bad I think, atleast in this case. I just want an integration into the system and not just a single program that is solely responsible for my work. No, this flattens my knowledge about which programs work together and will also never really teach to how use the compilers and settings for libraries I want to use. I still don't kow how to compile C/C++ programs using SDL!

Terminal fetish

This sounds pretty weird, right? Well, I just call it like that. CrunchBang brought a totally new perspective of viewing terminal software - it has a wide range of really, really good, not say excellent software collection for pure terminal usage. It's almost like everything I was doing before (listening to music, visiting IRC chats, etc) can be done with simple but effective terminal software! For example, the app "irssi" is like the IRC client I always wanted. I'm fascinated by the world of modern terminal software. Moreover, there is an app called mocp ("music on console") that works as a server that is playing it's playlist and a command line tool (mocp app itself) that controls the server. So everything you need to do is to pass some commands and the server does change his playback/playlist behaviour. It's very effective and indepent from the underlying windowing system. You can logout or rstart the X server without stopping the playback. Just awesome! It's extremely cool what's existing on windows.
I really never want to use a different music player while developing! Their is not only the indepence from underlying graphical systems, but a psychological factor. I always hate to see the whole player window/app that does never change over time just to keep music playing. mocp is totally invisible. Just like the music is playing in my head - and that's what I want! An invisible music source from somewhere you can control by giving it direct commands. I just love it. It's great. Nothing can beat this simplicty. I like music visualization, but I think this can also be done in a different app which catches all system sound data and visualizes it independent from the program playing it. This also enables you to capture different sounds and it won't crash if the music player crashes. So yeah, this system has many, many advantage over a conventional GUI player and will surely work better cause it doesn't need all kinds of ressource-intensive graphics or event checks and such. Effective, nothing more, totally.

Both apps inspired me so look for a terminal browser. Firefox is still really slow in my T30, and for simple browsing and posting in forums it's just an annoyingly long time firefox takes to get along. Luckily there IS an actually excellent piece of software enables to browse HTML documents and websites within the terminal! It's clearly simple but does a great job of converting HTML contents to a suitable format with different colors, visible links and so on. I'm amazed of it's functionality. It even has booksmarks, cookies, SSL support, a history you can browse within loosing text in input fields you did in a somewhere opened document. It's like a miracle to me! Right now I'm typing this using Lynx! I don't know how up-to-date it is or how old the last update is, but it is totally functional and excellent in design. It took me some hours to completely understand how every works but it after all I'm pleased using it.

The simplicty of terminal applications is what we are having in modern applications, too. It's just hidden behind a bulky, image-heavy interface that does less of a good job in serving as an effective way to do things popular around everyone using computers and the internet. Thingk about it: What is a modern music player? A database, a visualizer, a shiny interface, a connection to an internet database, a way to collect anonymous information about personal music consumption... So, why do you listen to music? Cause you want to hear music or cause you wanna see some twinkling animations? In both cases really don't the other shit. Music is stored as files, sorting music collections according to ID3 tags takes a shitload of time depending on how many tracks you have. And trust me, no program can do this within just a moment. This takes it's time, so why bother with it? Why do you really need ID3 tags for every piece of music you have?
Wouldn't it be better to just listen to music like BEFORE there were these kinda superfluous "everybody needs visually heavy interfaces" apps?

Well, not everything is gold, of course. This last paragraph was written with Firefox cause Lynx did somehow screw up the character display after the huge amount of characters I typed. It's not perfect. I just looked up wikipedia while typing and saw that the newest version is from April 25, 2010! It's developing. Only thing I'm a bit afraid of is to switch from IDE programming to pure command line compiling. I'm already trained in using gedit+terminal successfully, but it seems that a simple F9 hit and automatic makefile creating is easier than alsways changing makefiles, ALT+TABing in another window and executing a script for compiling and running. I'm sure there's a terminal app for that, but I'm afraid it doesn't really support effective copy&paste, proper syntax highlightning, a class browser etc... It's everything and IDE and does and I'd rather miss it I guess! Ok, ok - I never really use class browsers. I'm old-fashioned if it comes to that and like to view HTML documents or header files with documentation comments. I don't even use code-completition! What I heavily use is tabs inside the editor. I should make a list of all things I need and try to get some software. Also, I'm really sure if I want to code shell scripts... Together with VI it's one the things I really don't like about Linux. Well, nobody needs to worry about that. Scripting is only one solution. I can still use my IDE or try to find some other program. I could cope with makefile and an editor.