h2g2 The Hitchhiker's Guide to the Galaxy: Earth Edition

Well, I'm still going to use IE as the base for this project, until something better comes along. I just think it's easier to work with the grain than go against it.

Okay, I'm not particularly intending to have a debate about the evils of Microsoft because I'm already familiar with them. However, I would strongly disagree that just because Microsoft have a very large share of the x86 desktop market that they should be catered for exclusively, nor is their way necessarily the one you should take. I've used Microsoft development tools and I really rather despise them. Their APIs are mucky and horrible, the documentation is frequently wrong and they cost far too much. Therefore I don't use them, nor do I develop using Microsoft's solutions because I don't get on with them.

On the political side, Microsoft are basically evil. Do you want to be able to choose what you can do with your computer? Microsoft don't seem to think that that should be a choice you can make by yourself.

Sorry, but *I* really couldn't give a sick dog's dump as to whether or not Microsoft is 'evil' or not. It seems to me that a lot of people who work with computers need some bogeyman or another to get worked up about. First, it was IBM, now it's Microsoft. Who next: Cisco? They should get some perspective: to me, 'evil' is what went on in Bosnia, Nazi Germany or Fred West's cellar. Microsoft is just a business trying to hold onto its market share, just as any of the other champions of compting 'liberty' would, given half the chance.

I've worked exclusively with their tools for about eight years now, and they do everything I need for my job (which is actually quite a high-powered scientific computing one). In my own little universe, the boundaries of which do not go beyond work or the occasional project I do outside it (such as GuideDog), I am able to achieve everything I need to: this includes writing a GuideML editor. If there is an easier or quicker way to achieve the same ends then I will certainly consider it, but I'm not going to cut off my nose just to spite my face.

I hardly think it worth the time of day to get exercised about Microsoft's domination of the desktop. The success of this project will be judged on (a) whether it achieves its objectives and (b) whether it is accessible to the greatest number of people. I'm pretty certain we can do this using the tools that me and Jonny are most familiar with. If you feel like you want to influence the technical direction of this project I can only suggest that you sign up to it and get involved in both the Windows and Linux versions instead of writing your *own* editor.

Finally, you ask me whether I want to be able to choose what I can do with my computer. I can do everything I want (and more), and and I suspect that is a very large superset of what my prospective customer base does. I regard the computer as a *tool* to achieve my ends, not as an end in itself.

Absolutely

*decides to cautiously enter the debate*

I'm not exactly a Microsoft fan. (OK, I don't like them) but I do think it's best for the GuideDog project to work with current browser technology, and to take advantage of the things Microsoft provide. So far my only real experience in programming for Windows is using Microsoft Developer tools. You might think you've found some better programming methods, but we think we've found a way of doing what we want to do.

Unfortunately it seems that most of the world is driven by Microsoft. We are trying to provide a service for non-technical h2g2 users, who are likely to be using Microsoft products already. It seems odd to write GuideDog using any other API which would not naturally be on many people's computers.

I never said there were easier tools. In fact, were I to start programming from scratch right now and had in one hand something like Visual C#, and in the other the Mono C# development tools, I bet I'd choose the Microsoft one.

However, not only am I a sucker for punishment, I also am now used to the way I develop with non-Microsoft tools, and thus don't get on with Microsoft ones when the time comes to use them.

For what you want to do, your choice of tools is most appropriate, but for what I want to do - which is to play, basically, gtkmm2 on Linux is the way to go.

Well, I don't want to play. I just see a screaming demand for a tool and I think with my skill set I can probably fulfil that demand. If I couldn't program in VB then the chances are that I would probably leave this issue to someone else to resolve.
We have different objectives regarding this project: I want to produce something of value to the community, you have you own wishes which are to explore and and investigate the tools available. The objectives differ, and hence so will the approaches. C'est la vie...

..and, I should haved said, 'vive la difference!'

And that, of course, is precisely what makes programming for onesself so much fun...

...and programming for others so much of a bind...

Indeed. Now, if everyone ran Linux my work would be a lot easier...

But gtk+ 2.1 should have proper, official Windows support, and the C++ bindings for the 2.0 series already compile on Windows most of the time, so who knows? If I'm very careful about portability, I may be able to make it run on Windows. Mac OS X should be a snap, if the user's already running other graphical UNIX apps, or if gtk+ gets a native Aqua port any time soon (hope it does!)

I still think you should throw your weight behind the Linux version of this project. It needs someone withy your skills.

I am. What I was attempting to say (badly as usual) is that in a few months, the toolkits I'll eventually be using to write the Linux version will also enable, with some judicious effort, the Linux version to compile and run on Windows, and that I should already have few problems making it run on Mac OS X, FreeBSD, NetBSD, OpenBSD, Solaris... etc. etc. Which is good. However, I suspect your version will prove more popular, both due to being Windows-native, requiring support libraries people might actually be able to install fairly easily, and with being finished first.

...being finished extremely first, by the looks of things. I haven't even started yet. Is Spike still listening to this thread? If so, have you done anything? I'd like to have a muck about with some stuff, and it might be advantageous to bash heads together as if we're heading in the same direction it'd be better to produce one project than two I think.

Agreed. And you live just up the road from me, which is always good.
I've followed a fairly structured approach to all of this. The 'work products': documents, standards, approaches and code, should all be usable in their own right. You may or may not have read the functional spec. If you haven't, and you would like to help, please read this: there's a link on the main page. Can I put you down on the team list as a developer?
Undoubtedly (and I'd stake my life on it) the greatest demand will be for a Windows version first, and a Linux version afterwards. If you can live with this less than appealing situation then we can fight about what technologies we use to solve the problems afterwards. My own preference is still to base it upon MSHTML (as this will be easiest) except that I think I will be pressing for C# running under SharpDevelop as the main tool (as it's FREE!). I've managed to get the COM interop side of it working.
If you can think of an easier way of achieving our objectives then please let me know asap.

Cheers
FM

There's no way the Linux and Windows versions can share codebase as far as I can see unless you're willing to produce a .NET one, and that's only feasible in a cross-platform way when the Mono libraries develop a bit more. The equivalent of the COM components you're using on Windows simply doesn't exist on Linux, it's going to require more effort than under Windows I think, as I can't currently find any XML editor projects which are editors of the kind we need. They're more structured data editors - I guess because they're generic XML and not a specific XML application like a GuideML editor is.

At the moment I'm investigating the prospect of using GTK+ 2 for it, haven't quite got all the features of the TextView control sorted out though. I think it should be suitable though. The idea being that the text can be marked with Tags, which can be used by the save code to pick out the right bits to put in the right XML tags. That's if I understand them correctly, anyway. I'll be doing more research.

I do know now how to use libxml, and it's good... saving documents isn't going to be very hard

Smart. I suggest that if you are going to produce a Linux version that we have a very similar UI to the Windows version. If you could let me know what you think of the functional spec then I can adapt it to take into account any better suggestions you might have. This way, GuideDog for Linux ends up just like GuideDog for Windows.

The 'tags' approach is essentially what we are going to use for GD4W. We'll use an XSL stylesheet to transform the XML to HTML, decorating it with custom attributes. Then, we'll intercept the creation of HTML nodes in GD4W and decorate them too. Finally, we'll use another XSL stylesheet to convert it back to XML using the custom attributes to enable the conversion. You might care to look at http://www.itwriting.com/htmleditor/index.php, also http://www.codeproject.com/books/0764549146_8.asp for how I intend to use MSHTML.

Finally, I hope very much that
* IE 7.0 is IE.NET, which implies...
* The MSHTML library will become a proper .NET namespace with properly declared delegates and classes,
* and the .NET runtime will be installed along with IE 7.0 when users load it from a CD-ROM stuck to the cover of a magazine.
This will make programming and deployment of GD4W very much easier for us.

FM

Indeed it will! .NET runtimes will spread pretty quickly I think. Especially if IE 7 uses them.

If GuideDog does become a pure .NET project at any stage, then I'll probably help out - although I may have to put some work into the Mono project to allow me to run it on Linux, I do have the .NET Framework SDK for Windows, and C# is an acceptable language - certainly better than Java.

In the mean time I'll be aiming for a native Linux feature-port really, but I have to experiment a bit to get the transform mechanism working right. Since the editing control doesn't work on an XML document natively, it's not as simple as yours is

Re the native Linux feature port: please do this with our blessing. Also, we'd very very much like you to (a) base it upon the functional specification (which has cut down on your work) and (b) call it GuideDog for Linux. We'll call our version GuideDog for Windows.

Just to clear something up: as far as I know MSHTML doesn't edit XML directly, hence we have to go through the rigmarole of XML->HTML->XML round-tripping just like you will. This is where we can definitely help each other. I have done some work on this already and have it working in a rudimentary fashion.

I have been playing with C# and it is a very nice language indeed. Getting it to work with the wilfully-isolationist design of MSHTML (which makes NO concessions to anyone who can't use C++) is less nice, but possible nevertheless. A possible scenario is that MS will use IE 7 primarily as a means of getting the .NET runtime onto as many boxes as possible. We are definitely looking at GuideDog becoming a .NET project as, future developments notwithstanding, using the Framework remains the most likely method of unlocking the fully power of MSHTML.

So that would then just depend on having access to MSHTML workalikes under Mono - which isn't going to happen, methinks. Not for a while at least.

Unfortunately, it's not that easy for me - Gtk::TextView doesn't use HTML. I'm still looking in to exactly how I should be doing this.

So exactly at what point are you at the moment? Investigating Gtk::TextView to see whether it can be force fitted into what we want to do?