Dump the GC

Ironically, what some say that the Java Garbage Collector is one of the best features of the language. For some people, yes, but as a C/C++ programmer, I’m more accustomed to managing my own memory. In fact, I think it’s almost insulting to have to rely on the virtual machine’s ability to guess when I’m done with an object. I’d personally really like to see the ability to switch the gc into manual mode, where there is no automatic collection of garbage, and you must specifically call a delete command.

And don’t give me any nonsense on nulling objects. Really. I currently am using a library that when I null the only pointer to it, it persists in memory. There’s nothing I can do about the 700 megs of memory it takes up while loaded. I can see that in an attempt to be smart, it’s stupid. Save me the clock cycles, and just let me do it myself. Please.

MY-LOVE-OF-DONUTS-IS-MY-HYPER-DOWNFALL!

shadow@vectec-net:~$ sudo nano
[sudo] password for shadow:

1:45 am PST, and whoa, I…AM…AWAKE. Not your typical Night Owl awake like I normally am, I mean VERY, VERY END OF WORK WEEK TOTALLY EXHAUSTED BUT TOTALLY AWAKE style awake. Once I’m off the sugar-high, I am going to crash hard, but until then, it’s nice seeing you all, and please do not wake the sleeping donut eater once it falls asleep, which will make it angry… And you wouldn’t like it when its angry… It turns another color and gains a cool matching pair of contact lenses to match

It was worth it, however, for a bear claw, some bars loaded with chocolately goodness… and also a double chocolate blended creme at Starbucks, come to think of it. Well, the effect is actually wearing thin, so… See you tomorrow!

Night, everyone.

(^X)
Save modified buffer (ANSWERING “No” WILL DESTROY CHANGES) ?
File Name to Write: /unknownlocation/somewhereonvectec/blog.txt
shadow@vectec-net:~$

Ease Of Access

A few modifications I’m making to the interface of qZDL should greatly improve the usability. I’m switching from mainly dialog based down to mainly tab based. Instead of going to ZDL -> Options, there is now a settings tab along the top, that is ALMOST identical to the options dialog of ZDLSharp. The only change I’m making is I’m moving out the update log to it’s own update tab.

People that previously found ZDLSharp too cramped will rejoyce in that now that everything is resizable. You can, in fact, have a full screen ZDL if you chose. Of course, I need add functionality to remember the size last used, although this is trivial. The actual sizing information will be stored globally, and not locally. I’ll use the local operating system’s built preferencing system (using Qt, of course).

I also plan on enhancing the update system, although not right away. It’s pretty stupid, and I’d like to see changelog viewing from inside the app itself. Also, ‘Remind me later’, and ‘ignore this release’, and both of those functions require me to rewrite the php update script (not a big deal).

That’s pretty much most of the planned changes in a nutshell. The new INI backend will IMHO, be one of the most welcome features.

High Quality Youtube

Youtube has recently started providing High(er) quality videos on their site. While not all videos are high quality (the old trick was to trick the encoder not to re-encode your videos). On the good videos, the quality is dramatic. Here’s an example:
All About Halifax (LQ)
All About Halifax (HQ)

I’ve also found a blog entry which outlines some of the more technical side. I’ve also noticed that the higher quality actually loads faster. I think my ISP does some kind of youtube throttling, but I’m not sure.

Here’s some screenies:

EDIT It’s good also to mention that they amped up the sound quality to higher levels, and went to stereo. It’s now at 128kbps and not 96kbps mono. Yay! Also, sorry for the odd artifacts on the photos, I used a tool that apparently draws crap to the window while I resize the box to take a screenshot. Bad KSnapshot, bad!

Missing Feature?

For as long as there’s been an update checker in ZDLSharp, I’ve included ZDLSharp in the User-Agent field of the HTTP requests. With this, I also send out the OS type and verson, so I can easily target specific operating systems better. Come to find out, Qt has no easy to way to get some of that information, such as windows major, minor, release, and build IDs. The QSysInfo class isn’t much help either, it just provides a variable that maps to some constant, which is NOT fun at all. Also, that works for Windows and Mac only, so I have no idea what else is going on. I’d have to check: Win32, WinNT, WinCE, Mac, and then deduce that it’s Linux. Not particularly the best way to do it. I may have to try and write my own cross platform versioning stuff, because this is just unreal, and a complete oversight in my books.

References:

http://lists.trolltech.com/qt-interest/2003-06/msg01237.html
http://lists.trolltech.com/qt-interest/2005-09/msg00741.html

ZDL, on a Mac?!

After 10 hours of compiling Qt, qZDL compiled cleanly inside Tiger. First I’d like to note that I previously hadn’t been targeting the Mac audience at all. Now that I’m using Qt, I can safely do so, and make some interface changes to better suit their needs. Right now it’s lifted directly from Win32/Linux, but there’s a lot of changes that need to be made first. Here’s a screenshot:

qZDL Status

I’m happy to report qZDL is coming along very nicely. The gui and backend bits are seperated, so that all of the ini stuff is used as calls from the GUI layer (like it should be). The gui layer stores some data inside itself, but when it gets a qt signal to write, it loads it current configuration into the ini layer. The opposite can happen, when a read signal is received, the gui layer grabs the current configuration and reads the new data and adds it to it’s current local config and updates the GUI accordingly.

Most of the information in the gui layer does not actually have it’s own local config, but for some things it just makes it easier (like the file list, it saves having to do some wacky re-ordering, and only does some of the error correction on the ini level on the write signal).

I’d also like to mention that the ini stuff is way better than the old ZDL ini stuff. I’ve completely rewritten it from scratch, and now it uses more of a database-like method. A call is made to a configuration to read in an ini, which parses it and stores it inside ZDL for querying. When we want to set a value, it will either overwrite the current value, or if necessary, create a new entry. In the end, when the writeINI() function is called, it does the entire thing backwards and outputs the file, so that extra stuff does NOT get removed. This may add a little bit more CPU and memory consumption, but for the most part it does things automatically, and manages it’s own stuff (and uses the C++ string stuff to improve stability).

On a side note, the new INI parsing stuff includes the new variable resolving code from ZDLSidekick. This allows access to environment variables, system variables (that is, ZDL system variables, such as version), and custom variables as described in the ZDL Extended Configuration. The eventual plan is to allow people to specify a path to their source ports, without having to encode that information inside the ini file (which can be shared with others).

But for now, that’s all in the backend, and is COMPLETELY transparent to the user. I’m still focusing on simplicity, stability, and robustness of the original ZDL.

Oh, and I’m really hoping to get qZDL out March 23rd, but we’ll have to see, no promises!