[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] WCOWORK operating mode



tor, 14,.07.2005 kl. 00.08 +0200, skrev Arnaud BERCEGEAY:
> Hello,
> 
> >  I care about all evolutions. But we need to be careful not to create
> > more problems with MP, VM and other things we dont have yet.
> 
> Agree 100%
> 
> I've done a big clean-up in windom2 (the next MT version of windom) to  
> remove all old hack (support of iconification utilities, extended file  
> selector etc...) that uses a BRA to a cookie. Now, windom applications  
> should work fine with MP enable (not tested).
> 
> > If we
> > continue to develop bad designs, we'll never see those things either.
> 
> I still don't see why putting AES functions is a library is a bad design,  
> and i still don't see why this kill any AES new features. It's just a  
> library that may be updated to support new AES features, just like  
> applications may be updated to support new AES features.... i really don't  
> understand you.

 There should be one lib for handling the GUI side of an application
(WinDom). Then the application can link agains as many other libs as it
needs to, but none of those other libs should ever go directly to the
GUI. Even if you add libjpg to windom, libjpg should NOT be used by
windom without the user telling it to, by providing the glue-functions
between the library API's. And then it will work as if the two libs were
separate anyway. And keeping those two libs separate will make both libs
a lot more portable, versatile and easy to maintain. One should be able
to use libjpg in a simple CLI app, 'print_jpg.tos' as well as in zView.


 Odd Skancke