-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2 Dec 2004 at 1:26, Lothar Scholz wrote:

> ND> BTW, go SVN rather than CVS for any new project. SVN is now very
> ND> stable indeed.
> 
> Does sourceforge already offer a public SVN server ?

It will next year. I'm using berlios.de right now.

> ND> I therefore indicate that I would be happy to let others have
> write ND> access to development branches of the TnFOX SVN. If the
> development ND> branch proves good, it gets merged to mainline. I
> offer my ND> coordination here as admin.
> 
> I hoped to get an answer like this.

It still is with regret that I offer it. I believe that Jeroen will 
get onto this himself eventually anyway.

> ND> 4. Exception awareness for all existing FOX code and conversion of
> OS ND> errors to exception throws.
> 
> This is a problem for me and everyone who uses language bindings
> around C++.

Hardly! If you are using SWIG based wrappings then I believe it's 
mostly handled for you. All you must do is insert a try...catch 
around the point where C++ returns back into your language, 
converting the exception into your language's error system.

It works fine for python anyway, in fact you can throw an exception, 
it gets converted to a python exception which then can get converted 
*back* into a C++ exception!

> Is there any way to disable exceptions ?

No. And writing exception aware code is around 10% more work than 
writing normal C++ code. But it has to be done if you are writing 
mission critical code.

> At least i would like to see signals like SIGSEGV etc. passing through
> and not get catched by an exception handler. I'm using GNU Eiffel and
> this has the best crash reporting system i've ever seen. It's
> completely useless with the use of "try_handle" in the latest branches
> because now all exceptions are silently catched. I really can't accept
> that this is a good programming style. Errors are errors ignoring them
> is evil.

Signals aren't exceptions and in fact most signals must be disabled 
in multithreaded code. TnFOX doesn't require you to multithread your 
code, but it does require you to choose between either forking or 
multithreading. You can't do both. It's also biased towards 
multithreading.

Right now TnFOX installs a default signal handler for all terminating 
signals at process start which deletes the secure heap and spits out 
some debug info. Any later code can freely override them.

> I would also suggest that we should look into support for Apples
> MacOSX. Unfortunately this requires some changes, especially for the
> menu system. Menuitems can't be FXWindow anymore. I've never seen
> someone using other things then normal items in menus. Or at least we
> should offer hooks where people can do this.

Or you could emulate the MacOS X menu system. I don't know enough 
about it, but it's what Qt does.

> And if you want to use Aqua themes you must first do a carbon port.
> You can't use the themes from the X11 server. So this would be
> something that i like to put between your number 2 and 4.

Well part of theming is the removal of all the per-X11 code into a 
theming module. So in my mind a MacOS X theme meant just that.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBQa71fcEcvDLFGKbPEQLa3QCeKtUzVroeAgo21QTwuRyMBgRqjawAoKyq
8wIIs6MzKorWJN3SenDT0rzv
=95D2
-----END PGP SIGNATURE-----


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Tnfox-discussion mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

Reply via email to