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.

Oh Dear

There seems to be a problem with the new ZDLSharp. I wrote some of the code for ZDLSharp 3.0.5.3 on the train on my way to a friend’s place, I also had previously made a backup of all that information. Well it appears I deleted those files on arrival, and started work on 3.0.5.3 again thinking this was the files I had modified, but apparently I was wrong.

Some of the bugsfixes I made for 3.0.5.3 didn’t actually happen. I only fixed one bug, and that was for Mono users. Since the weekend is coming up, I really want to get a new version out ASAP. It has also come to my attention that the source for ZDLSharp hasn’t been released, so I want to put that up on sourceforge, and keep binary releases to my own servers. I think that works best.

Anyways, keep your eyes and ears peeled for new and exciting news!

Prepping for ZDLSharp 3.0.5.3

I’ve made great headway on a couple of the bugs. Unfortunately there’s one that will take some time, so now I’m faced with the decision to either fix it or leave it for another time. I really want to get this version out the door, as it’s taken a long time. Part of the changes I want to implement to fix it are slated for 3.0.6.0. I planning a better configuration backend and doing away with the old ReadINI support. Of course, since a substantial amount of the program is built on this old code, it will take quite a few hours of coding. The current bug is pretty isolated I think.

As for my plans in the wiki for 3.0.6.0, this is what I’m planning:

1. New Update System
• I’ve chosen to do a hybrid between self updating and leaving it alone. I don’t want people to have to open their browser every time just to update
2. Community Functionality
• This feature won’t be in 3.0.6.0 at all. Perhaps in subsequent versions, but it’s not in the pipeline yet.
3. Config File Trampling
• Currently with the readINI() functions, any unknown lines are completely removed. I’m going to change this, plus also keep track of what version wrote the last config file. I recommend that all ZDL ports use this functionality, and warn users if they’re using an old config file. If the user agree’s it’s cool, overwrite it if a better system isn’t implemented. If the user isn’t cool with it, read the config, but do not write it back at the end.

What Happened to ZDLSharp?

So if you’ve been looking for the promised 3.0.6.0 version of ZDLSharp, and feel disheartended by the talk of Triplet, don’t fear!

I promised a few weeks ago that there would be a bugfix 3.0.5.3 version out, however, due to family issues, I was unable to work on ZDLSharp. Now that I’m about to start Exams, I won’t have much time for either Triplet or ZDLSharp. Not to worry! I will be free after the 18th with loads of time until I start work on January 14th. I really want to roll out 3.0.5.3, and then roll out 3.0.6.0 by January 14th. No promises though! There are plenty of bugs to fix up, for both the windows and mono versions. It’s important that these be fixed up quickly, so that we can get to a stable point. There are a few critical blockers, that abolutely need to be released ASAP. Normally, 3.0.6.0 would have been released, skipping 3.0.5.3. One of the features of 3.0.6.0 is the reworked backend, ditching Bio’s old readini functionality. This has proved not to be useful, and very inflexible, introducing compatibility problems. Any new features I introduce in the ini file are erased as soon as an older client opens it. I would like to merge my changes with Risen’s version of ZDL 3.1. I believe it is very important that non-understood entries in the config file stay untouched.