Page: 0 ... 5 ... 10 ... 15 ... 20 ... 25 ... 30 ... 35 ... 40 ... 45
Date: 19/9/2005
At some point I want to update my aging (borrowed) CRT to an LCD and by looking at the prices and models available it seems like there is a huge gap between the 19" and 20" models price wise.

For instance, you can buy a nice 19" LCD for A$450 which sports a resolution of 1280x1024. But to get 1600x1200 which is what I use you have to jump up to a 20" (wow a WHOLE extra inch!) and pay around A$1300. The price gap seems highly artifical. The average user looking at a little bit more than a 19" LCD would go for a 20" if it cost $600-700. But $1300 is just unreasonable. Esp. since dell regularly discount their 24" model to A$1440, if only it came in silver ;).

So is there anything <A$1000 that does 1600x1200? (I'm not hopeful but I thought I'd try)

I find it amusing that most 19" CRT's do 1600x1200 in their sleep, whereas the LCD crowd never do it.
(13) Comments | Add Comment

Html Layout
Date: 9/9/2005
I now have a far more intimate understanding of the absolute horror of HTML 4 layout. It's gruesome and evil and it haunts you, always promising more broken markup just around the corner to break your layout engine.

Well that aside, I did get some breakthough in the layout of 'p' elements in the HTML control. By keeping track of how many previous scanlines are 'margin' pixels in the flow construct I can get paragraphs to layout the same as firefox, under all the conditions I know about. Like nested, and self closed and so on. And gee it's only taken me like 2 years to get it thus far.

The tables are also looking much neater now. Although not totally perfect. At least all the work I put into validating the table structure has paid off, there is a bunch of code that re-arranges all the elements under a table tag to be 'correct' html. i.e. tables can only have 'tr's which can only have 'td's. I suppose you would believe how many people get that wrong. I have some classic example HTML emails from PayPal and Ebay that are ridiculous. Missing or wrong tags everywhere, badly formed CSS, nested table upon nest table. They really are a torture test. My personal fravorite was the PayPal email where nested 3 tables in they miss the end table tag. Oh man that just fries everything.

Anyway all these chucks of hideous HTML are stored away in source control with a HTML test suite program that runs through them all and renders it using the current HTML control. This way if I make any changes to the control I can scan quickly throught a bunch of hard files to render and check I havn't broken anything. So far it's passing the most it ever has, there are a few insane cases that it doesn't do yet, but for reading Outlook HTML it's enough. Speaking of which, the paragraphs generated by Outlook now appear correctly. Hurrah.
(2) Comments | Add Comment

Graphical Filter Editor
Date: 6/9/2005
The problem with modern applications is that they have to be both simple to use for beginners AND powerful for advanced users. One of the areas in Scribe where this clashes is the user defined filter conditions interface. Currently it kinda borrows from databases where it allows you to create a number of condition records, of which you can only see one at a time, and lets you edit the fields of each condition record using standard controls. However you are limited to either AND'ing or OR'ing all these conditions together. So you can't write powerful filters with combinations of AND and OR operators, or have any form of nested conditions.

So I'm playing around with a prototype user interface to replace the conditions editor tab. And this is what I've got so far:

This improves on the old UI in a number of ways. Firstly you can see all the conditions at once. You can now nest operators and conditions with ease. But hopefully it still remains easy to use for beginners. The short 3 button field allows you to create new conditions, AND or OR operators. The condition entries have editable fields and drop down helper menus. A nice legend at the top means the meaning of the icons will never be in doubt.

So what do you think? Any good?

The icons are rendered using the built in vector renderer in Lgi. They should scale to any size should the need arise. I had to fix a number of bugs in the vector renderer to get all this to display, but it was worth the effort.
(9) Comments | Add Comment

Date: 2/9/2005
The new build of i.Hex is now out, featuring the data visualisation tool that I talked about earlier. I've made a setup program to make it easy to install and uninstall, but it can still be moved around and copied the same as when it came in a zip file.

In making the release build I had to work around a bug in the aging VC6 Compiler. I had a line of code:
int Bytes = min(Block, Len - i);
That causes this:
D:\matthew\Lgi\i.Hex\Code\iHex.cpp(990) : fatal error C1001: INTERNAL COMPILER ERROR
  (compiler file 'F:\9782vc98p2\src\P2main.c', line 494)
    Please choose the Technical Support command on the Visual C++
    Help menu, or open the Technical Support help file for more information
Error executing cl.exe.

iHex.exe - 1 error(s), 0 warning(s)
Lovely eh?

Well it was easier enough to fix:
int64 Bytes = min(Block, Len - i);
(0) Comments | Add Comment

Mac Development
Date: 31/8/2005
So I swap all the usb cables across to the Mini, power cycle the cable modem, plug in the firewire drive, shutdown that noisy old PC and just sit there in the silence stairing at XCode. Now what?

I originally thought that I'd copy the Linux port into a new directory, rename it "Mac" and then get it compiling against the MacOS X X11 SDK. But when I actually tried that I realised that a) all the Xft and XRender extensions that I use aren't there and b) I know I'm going to throw away all that code and write a cocoa port anyway. So I stopped doing that, and resigned myself to working cocoa out.

Um. So um, how do you connect a C++ API to cocoa again? It seems there is several ways hinted at in various webpages:
  • Use the (MIA) cocoa C bindings.
  • Write in Objective-C++. (How?)
  • Write some glue in Objective-C between the C++ and cocoa.
None of these options are documented anywhere I can find. So I'm really just stabbing in the dark at the moment.

I have a body of C++ code that defines the Lgi API and I want to connect that to cocoa somehow. Ideally I'd like to be able to just call cocoa stuff from within my C++ files, which is what it seems Objective-C++ might be. So on one side I could have a C++ API and the implementation of that C++ calls cocoa. Does anyone know how to do that?

Maybe however you can't do that, and somehow you have to link the C++ against some glue code in a different language. Like maybe Objective-C or C++. Can obj-c/c++ export an API that C++ can call? Probably not... but I thought I'd ask.

This mythical "C API for Cocoa" only gets hinted at in various webpages. Anyone know where to get some docs or headers for that?
(4) Comments | Add Comment

Hex Editor Data Visualisation
Date: 30/8/2005
Over the last few days I've implemented a data visualisation tool for i.Hex. The basic idea is to allow the user to define the format of the data they are viewing. This is displayed in a 2nd pane as an object dump. Check out the screen shot:

The structure "Main" defined in the "Map Editor" window is being formatted from the current cursor location into the pane on the bottom right. Fields can be base types like "uint32" and "float" or user defined types, like "IccDateTime" which are defined in the Map Editor as well. e.g. the field "CreationDate" has sub fields.

You can reuse fields defined above the current member variable as array lengths.

You can also define specialisations of a classes that furthur define data. For instance you might have something like a generic field:
struct Field
    uint32 Id;
    uint32 Size;
    uint8 Data[Size];
But then go on to furthur define sub-types of "Field" like this:
struct StringField : inherits Field
    uint32 Id = 1001;
    uint32 Size;
    char String[Size];

struct IntField : inherits Field
    uint32 Id = 1002;
    uint32 Size = 4;
    uint32 IntValue;
Where the "= ????" parts define conditions that if met mean that the sub-type is to be used. Otherwise the parent type is used. This is the start of a powerful binary data definition language.

I don't know of any software package that lets you do this, even C++ isn't this powerful. I have thought that maybe a great C++ library would be something that reads the same structure map file that i.Hex now reads and then gives you access to the fields via a DOM so that you never have to do direct serialization in C++ ever again. Hmmm that sounds kinda nice. And if the file format changes you just edit the schema and don't have to recompile any code. My only thought is that it might be dog slow. However trading some flexibility for speed is often benificial, as long as you don't go too far. The right tool for the right job is a good motto.
(1) Comment | Add Comment