Re: [Armory-devel] About using qt in armory

[darrik m. <da...@my...>]

ana...@gm... wrote:
> the client and the statistics gathering programs are very much
> separate (please see the server and client code in the 'backend'
> directory in 'test' on sf SVN, though it can be improved much more)
>
>   
Qt provides a plugin framework for this sort of thing, allowing us to
develop and release all the stat mining functionality separately from
the client. It does this in a platform-independent way, using dll's for
plugins on windows and .so for *nix. To be truthful, I have no idea how
libraries are linked at runtime on mac, but supposedly Qt handles this
as well. ;)
>
> I am not familiar with Qt other than that it a tool to develop GUI,
> but have you taken a look at the ADAPTIVE Communication Environment
> (ACE) C++ libraries (http://www.cs.wustl.edu/~schmidt/ACE.html)? It
> has been developed written specifically to make platform dependent
> things like network programming, process and thread creation, inter
> process communications portable across OSes. There is also the BOOST
> libs (asio.sorurceforge.net), but this is not as wide as ACE in terms
> of system programming interfaces provided. Let me know what you think
> of this.
>   
I am familiar with boost but haven't used it, and I used ACE on another
project. As for Qt, while it's very good for GUIs, the libraries are
modularly linked, and it provides a lot of other platform-independent
functionality (process and thread management, ipc, etc). Personally, I'm
partial to Qt, simply because I've only used ACE once and boost not at
all, while I'm very experienced with Qt.
> But one thing is using these tools wont help in getting the
> performance statistics because they *are* highly OS specific. we cant
> make that portable.
>   
Agreed. There's only so much a toolkit can do without being a beast. ;)
At least a cross-platform toolkit removes a lot of the redundancy from
our development effort and time. What needs to be OS-specific will just
have to be. Another benefit to Qt, though, is that it provides a
platform-independent build process with convenient conditional
compilation (without #ifdefs and whatnot) for a lot of os/compiler
combinations.
> Do let me know you opinions.
>   
These are they. ;)

I've got most of the code you wrote converted to Qt, with a lot more
other code in place (threaded server, plugin framework, etc). I was
waiting to get a working copy before committing to sf svn, but if you
want, I can commit most of what I have for you to look at.

~Darrik Mazey