Alo Sarv
lead developer

Donate via
MoneyBookers

Latest Builds

version 0.3
tar.gz tar.bz2
Boost 1.33.1 Headers
MLDonkey Downloads Import Module Development
Payment completed
Development in progress.
Developer's Diary
irc.hydranode.com/#hydranode

Monday, February 14, 2005

First GUI attempts

I'm trying to move the development more and more towards windows, but little success so far. The reason behind developing on windows is that the vast majority of users are on windows. And windows users expect fundamentally different approach to final application than Linux users - namely, graphical. While HydraNode works (somewhat) on Linux, it doesn't work at all on windows. Yes, it does compile, yes it does run, but no, it does not work. Because it's missing anything even resembling a graphical interface, and doing stuff in windows console just doesn't cut it.

So I'v been trying to cook up some kind of shell, along with some controls to help with further development - constantly parsing pages and pages of trace output in console got rather tedious a long time ago.

The GUI library choice pretty much came down to QT, after their announcement that QT4 for Windows will be released under GPL in late Q2/2005. First impressions on QT library were very positive - things that I had spent several days trying to get working with wxWidgets worked right out of the box. However, there are limitations.

Namely, one idea was to compile the engine to a dll, and link GUI against it. With this approach, the GUI could do direct core function calls, subscribe to core events directly using core event engine, etc, giving very fast responsiveness. However, I quickly discovered that QT's preprocessor, Moc, breaks on Boost headers, namely, Boost.Signal ones, which is not very surprising. There are means of working around it, for example, by not including any hydranode headers from moc'ed GUI headers, however, it quickly leads into one big pile of mess.

As an afterthought, I realized the idea wouldn't have worked anyway, since it would'v broken remote GUI capabilities anyway. The only reason for attempting this was to tie the engine and GUI together for windows platform only, in order to allow easier development/debugging, however, seems it's a no-go.

So, the GUI still needs to do everything it needs to do over Core/GUI communication layer, and that layer must simply provide a ton of features required by modern user interfaces, that windows users expect.

Madcat, ZzZz



Comments:
why create a linked gui?

the plan was to use hydranode as a service/daemon as far as i understood

just create a protocol to connect to the core, document it and create a sample gui using local widegts only

please avoid wxwidgets or any other redundant huge "cross platform" interface, native interfaces are easier to handle

if people want as local gui they can create it themselves unless you really want to maintain all the editions of the gui

mldonkey provides a gui protocol, a native ( basic ) webserver and telnet access, so please dont limit you clients to be locked to a gui, especially if they plan to use remote access to control the server
 
> why create a linked gui?
It was an attempt to tie it strongly together for win32 platform ONLY to make it better suitable for the platform, where applications are SUPPOSED to be tied together. And it wouldn't have released this way anyway, since it would'v broken multi-gui concept.

> the plan was to use hydranode as a
> service/daemon as far as i
> understood
You understood correctly.

> just create a protocol to connect
> to the core, document it and
> create a sample gui using local
> widegts only
Protocol is already created and documented (perhaps look at doc section?). And please define "local widgets" ? If you mean native, then both wxWidgets and QT are native toolkits.

> please avoid wxwidgets or any
> other redundant huge "cross
> platform" interface, native
> interfaces are easier to handle
Easier to handle for whom? For user? No, because I can create native cross-platform interfaces. For developer? No, because the developer must write in three or four different huge GUI toolkits (MFC, QT/GTK, Carbon). 3-4 times more code, 3-4 times more maintainance... how is it easier?

> mldonkey provides a gui protocol,
> a native ( basic ) webserver and
> telnet access, so please dont
> limit you clients to be locked to
> a gui, especially if they plan to
> use remote access to control the
> server
I never intended to lock the user into a GUI, nor to only local access. Furthermore, I intend to support both giFT AND mldonkey gui protocols, so those GUI's can also work with hydranode.

Madcat.
 
On osx, if hydranode worked together with either xfactor(giFT) or xdonkey guiĀ“s that would be superb.
 
QT yah! awsome! thanks
 
Post a Comment



<< Home

This page is powered by Blogger. Isn't yours?