[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Future of KDE Development
From:       Hans Meine <hans_meine () gmx ! net>
Date:       2005-02-21 9:40:59
Message-ID: 200502211041.00162.hans_meine () gmx ! net
[Download RAW message or body]

Hi again!

A lot of the patches from the Solaris patchset seem to add STL headers; 
actually I found these types of changes:
- additional includes (I don't think there would be a problem with adding
  necessary #includes to CVS)
- substituting C functionality / C headers with C++ ones (this is something
  that could be integrated if it fixes things on a specific platform, too -
  however there are chances that it breaks stuff on other platforms, so it
  should be discussed where this is necessary and why, and we can't integrate
  it shortly before a release AFAICS)
- replacing "using namespace std" by "std::" prefixes. I wonder if this is
  necessary at all (apart from being a coding style thingy), and unfortunately
  all these changes make the diff files hard to read (needs more time).

On Saturday 19 February 2005 23:32, Stefan Teleman wrote:
> 1. Why duplicate glib header and implementation files within arts ?
> This doesn't really remove the dependency on glib, and it causes
> conflicts.
Yes, this removes the dependancy of GSL on glib.  You are of course free to 
patch GSL, but it ships as part of aRts and is developed in a separate 
repository, so your patches have no chance to be applied upstream.

> 2. The trader does not find any mimetypes. Therefore you cannot play
> any sounds. The problem with the trader not returning any matches
> from the trader cache can be easily reproduced with the trader test
> program.
This is very interesting.  However the hardcoded mimetypes are *clearly* a 
hack.  Note that I said "wondering who hacked this together and why"; I was 
sure there was a reason for this, but now one should find out *why* the 
trader does not return any matches! (Or wait for KDE4's multimedia solution.)

> 3. The direntry handling changes are for the memory corruption caused
> by the original implementation.
Again - one should discuss the problems with the original implementation in 
public, and fix them.

> The consequences of 2 and 3 are that you cannot play any sounds, and
> Noatun (or any other of the players in kdemultimedia) will crash on
> startup with the famous "Cannot instantiate aRts object". These
> patches fix these problems.
Thanks for posting these reasons.  For the records: With GCC, noatun seems to 
work fine.

> There is no problem with AC_SYS_LARGEFILE or truncate64 when building
> with the Sun compilers.
Lucky one! :-)

Ciao, /  /
     /--/
    /  / ANS
[prev in list] [next in list] [prev in thread] [next in thread]