ZDLSharp/qZDL Preparing for a Beta Release

It’s been some time, but the ZDLSharp Qt beta is nearing beta release. ZDLSharp 3.0.5.3q fixes issues that the C# version of ZDLSharp had. While still in beta, it will be referred to as ZDLSharp, but rebranding will take place once 3.0.5.3q leaves beta to qZDL. It’s currently only available in SVN (See the page for the version for access details), and should compile on all 3 major platforms (Windows, Linux, OSX) without many issues. Bug reporting may be done via the SourceForge Project Page. It’s currently only tested on x86 but there is evidence to support that x64 also works. Testers would be appreciated for all platforms/architectures. To compile, Qt 4.3 or greater is required (Ubuntu 8.04 LTS Hardy Heron or greater for example).

Update: Here’s a screenshot of the DMFlag picker running on Ubuntu 9.10.

qZDL DMFlag Picker

Migrating to a Gentoo-style Update System

Woah woah woah. ZDL is not dead! I’m planning on the new update stuff, and I must say I really like Gentoo’s updating method. There’s two different streams (beta and stable) on at least 3 different operating systems. Here’s a proposed package method…

• qzdl-win-x86 stable unstable
• qzdl-linux-x86 stable unstable
• qzdl-osx-x86 stable unstable

This of course would all be released in qZDL 3.0.6.0, and no plans are being made for x64 or ppc releases. I’m currently working on 3.0.5.3q, which is the transition release between ZDLSharp (C# based) to qZDL (Qt Based). I’m hoping with my past experience with Qt that I can quickly finish up what I have done so far, and start pushing out a release. I’m going to be releasing the ZDLSharp source around that time on my website (it’s currently on request only). Everything should be documented on the wiki, and I just made a commit to the svn repo.

Oh, Hi

Wow, has it really been two months since I’ve blogged? Sorry guys!

If you’ve been talking to me lately, you probably know I’m pretty busy with school. The assignments, papers, and midterms just keep on marching at me as fast as I can do them. Unfortunately, my schedule is extremely inefficient for getting things done. So let’s do a recap!

Christmas

Christmas was pretty busy, and unfortunately the weather played havoc with a few of my plans. There was a few storms around Christmas and on New Years, which forced me to juggle things around a bit. For those that don’t know, I got a shiny new Canon EOS 450D (Rebel XSi), and you can check out pictures on my flickr page.

School

I’m taking a few interesting courses right now:

• System Analysis, Design & Project Management
• Professional Practice
• Computer Organization II
• Operating Systems I
• Anthropology – Religion and the Sacred

This keeps me busy pretty much all the time, and I haven’t had much time to do anything but school work in the past couple weeks.

Programming

All of my current programming project are unfortunately put on hold. Thing’s I’d love to get done is qZDL, and OCam. OCam (name still under consideration), is a little program I developed during the Ottawa OCTranspo strike to look at the City of Ottawa webcams easily. The app lets me flick through all the webcams in a way that’s analogous to using a TV (including “stations”). I’m working to add more and more webcams to this, and maybe release it.

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.

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!

libzdl

Since a lot of ZDL code is redundant, and probably could be used in other ZDL projects, I think it makes sense to provide my backbone ZDL code as a library for others to use. I plan on both releasing the native C++ and a C interface.

Perhaps I’ll incorporate it into Bio’s ZDL as well, because that readINI stuff is wayyy to funky.

Also, I hope to get something to show in terms of ZDL this weekend, even if it is a halfbrained jumble of that that hardly works – it’s more than what I got now.

It’s Official

After toying more with Qt, I’m pretty sure that the Sharp bits in ZDLSharp will be replaced. For the most part, it’s going to be re-engineered using the ZDLSideKick code I have lying around. Since my Qt code is lots more class-y than it’s ZDLSharp cousin, things will roll together way better.

In addition, I’m going to be forced into using GPL. I also plan on using the SourceForge CVS from now on, and I’ll even accept patches and fixes from others! The advantage of Qt is that I’ll be able to move across platforms fairly transparently. I started compiling Qt on windows today, so it’ll be ready to go for a release. I’m also changing my development release system. Before now, I was more release-happy. Now that I plan on using Linux full time, I’ll have two streams for releases: a more stable release that doesn’t happen often, and more beta releases. The source will be released for the more beta releases, and this will allow Linux and Windows devs to compile it and test it out, while leaving the Windows end users to be on a more lagged release stream. While this sounds not as good, it will actually result in more and better releases (so I can code any time, instead of booting to Windows).

The original ZDL was developed to reduce complexity, and I must keep that in mind. One of the new cool features of ZDLSharp 3.0.5.3q (signifying a qt release), is that it’s resizable, and will accommodate DPIs other than 96.

Is C# Viable?

It recently has come to my attention that C# may not be the best platform for ZDL. It started out as a test to see how quickly I could get a product rolled out. In reality, really fast. The have been hurdles, however. Since I do all my C# dev from Microsoft Visual Studio, and I run Linux, I have to boot into Windows XP just to do some development work. This leads to significant delays in product updates. Then there’s the deal with cross platformness. ZDLSharp works under Mono, sort of. You have to build a recent CVS version to get it to work, that is, the normal version of Mono will not run ZDLSharp. When running under mono, the look and feel is that of Windows 9x, so not particularly pretty.

Others have griped that the requirement for the .NET runtime on the host computer has been a nuisance. People have complained that they’ve tried to take their installation elsewhere on a USB key, only to find out that the host doesn’t have .NET and is locked down to prevent installations. I think the only solution, is to move away from C# altogether, and move to a cross platform library.