Re: [Tnfox-discussion] Library separation?

[Brian O. <bo...@pi...>]

I'll grab the subversion archive and give it a look see.

Inside FXProcess & QBlkSocket I found direct calls to FXApp in case of 
failure conditions.
It would make sense to rip out these static calls and replace them with 
some sort of functor to provide more decoupling.

Most of these FXApp dependencies are pretty cosmetic, there's just lots 
of them. (I could do this and then post a patch, I just haven't used svn 
before).

QBlkSocket.cxx: dependency on FXProcess
FXProcess.cxx: dependency on FXApp for posting messages. (win only)
QTrans.cxx: debug dependency on FXApp

FXSettings depends on FXApp/FXLockHold for its global lock.  I know this 
is a fox problem, likely should be solved by an FXSettings specific 
static QMutex instead of an application wide mutex.  I'll just comment 
this out and try again.

I was using FXSettings for only reading a config file.  I thought it 
would be a good idea to leverage someone else's code for config file 
handling.

Also I was hoping to use this little project to get an idea of how good 
or bad the TnFOX libraries are and whether I should try to base new 
development off of them.  I have some misgivings about some design 
decisions made in the FOX portion but if I feel the bad stuff can be 
isolated it won't bother me so much to use it.

Just FYI I've got gentoo ~x86 smp, ~amd64 and fedora core 3 x86_64 all 
handy.
If things work out I'd ultimately use xmingw for cross compiles also.  I 
honestly cant' stand working in windows, but I do everything I can to 
make sure what I write is cross platform.

Thanks!

Niall Douglas wrote:

>On 15 Aug 2005 at 8:53, Brian Olsen wrote:
>
>  
>
>>I was interested in using some of TnFox's services to build a server.
>>The services I wanted were:
>>
>>QBlkSocket
>>FXProcess
>>FXSettings
>>QThread
>>FXRex
>>etc.
>>
>>Unfortunately because of the monolithic library I was forced to pull
>>in all sorts of X11 & related dependencies which I definitely didn't
>>want.  So I would like to request that the non GUI service library be
>>broken out from the GUI service library if possible.
>>    
>>
>
>That's not a problem, simply build a static library by saying so in 
>config.py and link against that. Only the code that is required will 
>be pulled in.
>
>Now, in /theory/ there is no coupling between the TnFOX extensions 
>and FOX itself apart from FXApp and FXEventLoop. However in reality, 
>there is probably enough to pull in code you don't want. Depending on 
>how slim you want your binary, this may be a problem.
>
>What I am willing to do is adjust the TnFOX extensions to ensure 
>almost no GUI code is pulled in, but I won't alter FOX code. 
>Therefore I won't touch FXSettings or FXRex unless it's a simple 
>#ifdef. FXRex shouldn't cause you any problems, but FXSettings might 
>as it yanks in a whole pile of other FOX code.
>
>All other dependencies you won't need should auto-disable except I 
>think FAM. There was some very good reason I couldn't disable FAM 
>inclusion but I can't think of it now.
>
>  
>
>>Some general comments:  We're currently using Qt at work for a lot of
>>things, over the past couple of years I've done all I can to isolate
>>the Qt specific stuff since Troll Tech wants it to be borgish.  From
>>this cursory work with TnFOX it actually looks pretty promising, I
>>like some of the added features.  Thread safety, exceptions, etc.
>>    
>>
>
>You probably won't believe me, but it was I who persuaded Trolltech 
>to add many of the new features in Qt 4. It's hence why TnFOX has 
>many of the same features, except I did them a lot better. And I 
>don't add a smiley there, because I'm not joking! :)
>
>  
>
>>Probably my biggest complaint would be lack of simple example apps and
>>overly sparse documentation for getting started (example what's the
>>second parameter of FX::FXSettings::parseFile(const char* file, bool
>>mark) supposed to do?)
>>    
>>
>
>Well the docs for the FOX code are as FOX has them. There isn't much 
>I can do about that really, as it should be FOX that fixes that. In 
>answer to your question, I have no idea - except to suggest not to 
>use FXSettings at all (I don't - I don't like the windows registry, 
>how it's organised and I certainly don't want to confine myself to 
>such a limited structure). In Tn, I simply invoke a data structure 
>extractor and get it to do all the work. However sans Tn, I'd suggest 
>inspecting the source code - probably that for FXDict as FXSettings 
>is based on FXDict.
>
>BTW, I strongly recommend you use TnFOX from SVN as I've renamed all 
>the Qt-compatible classes to start with Q instead of FX.
>
>Cheers,
>Niall
>
>
>
>  
>