yay!

[D. Michael McIntyre-3]

make -f qt4-makefile src/sequencer/SequencerMmapper.o
/usr/bin/c++ -c -DQT3_SUPPORT -Wall -O0 -g -DHAVE_ALSA -DHAVE_LIBJACK -DHAVE_DSSI -DHAVE_LADSPA -DHAVE_LIBLO -DHAVE_LIBLRDF -DHAVE_XFT -DDEBUG -D'VERSION="2.0-yeah-whatever-innit"' -I/usr/include/qt4/Qt3Support -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtXml -I/usr/include/qt4/QtNetwork -I/usr/include/qt4 -I/usr/lib/kde4/include -I/usr/include -I/usr/local/include -I/usr/include/freetype2 -Isrc/base -Isrc
src/sequencer/SequencerMmapper.cpp -o src/sequencer/SequencerMmapper.o
src/sequencer/SequencerMmapper.cpp: In
constructor ‘Rosegarden::SequencerMmapper::SequencerMmapper()’:
src/sequencer/SequencerMmapper.cpp:64: error: no matching function for call
to ‘std::basic_string<char, std::char_traits<char>, std::allocator<char>
>::basic_string(QChar*)’
/usr/include/c++/4.2/bits/basic_string.tcc:233: note: candidates are:
std::basic_string<_CharT, _Traits, _Alloc>::basic_string(typename
_Alloc::rebind<_CharT>::other::size_type, _CharT, const _Alloc&) [with _CharT
= char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
/usr/include/c++/4.2/bits/basic_string.tcc:226: note:                
std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, const
_Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc =
std::allocator<char>]
/usr/include/c++/4.2/bits/basic_string.tcc:219: note:                
std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*,
typename _Alloc::rebind<_CharT>::other::size_type, const _Alloc&) [with
_CharT = char, _Traits = std::char_traits<char>, _Alloc =
std::allocator<char>]
/usr/include/c++/4.2/bits/basic_string.tcc:208: note:                
std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const
std::basic_string<_CharT, _Traits, _Alloc>&, typename
_Alloc::rebind<_CharT>::other::size_type, typename
_Alloc::rebind<_CharT>::other::size_type, const _Alloc&) [with _CharT = char,
_Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
/usr/include/c++/4.2/bits/basic_string.tcc:197: note:                
std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const
std::basic_string<_CharT, _Traits, _Alloc>&, typename
_Alloc::rebind<_CharT>::other::size_type, typename
_Alloc::rebind<_CharT>::other::size_type) [with _CharT = char, _Traits =
std::char_traits<char>, _Alloc = std::allocator<char>]
/usr/include/c++/4.2/bits/basic_string.tcc:183: note:                
std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const
std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits =
std::char_traits<char>, _Alloc = std::allocator<char>]
/usr/include/c++/4.2/bits/basic_string.tcc:191: note:                
std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _Alloc&) [with
_CharT = char, _Traits = std::char_traits<char>, _Alloc =
std::allocator<char>]
/usr/include/c++/4.2/bits/basic_string.h:2055: note:                
std::basic_string<_CharT, _Traits, _Alloc>::basic_string() [with _CharT =
char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
make: *** [src/sequencer/SequencerMmapper.o] Error 1

This looks like STL hell.  I have no idea what's going wrong at all.  Too
sleepy to try.  Abortng.gggggggggggggggggggggggggggggggggggggassef

--
D. Michael McIntyre

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[cannam]

On Sun, Sep 7, 2008 at 7:03 AM, D. Michael McIntyre
<rosegarden.trumpeter@...> wrote:
> src/sequencer/SequencerMmapper.cpp:64: error: no matching function for call
> to 'std::basic_string<char, std::char_traits<char>, std::allocator<char>
>>::basic_string(QChar*)'

This is from std::string(m_fileName.data()) where m_fileName is a QString.

This needs to be replaced by m_fileName.toStdString().  (Not
qstrtostr(), because filenames want to be treated as the local
encoding rather than utf8.  I think.)


Chris

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[Emanuel Rumpf-2]

2008/9/7 Chris Cannam <cannam@...>

This needs to be replaced by m_fileName.toStdString().  (Not
qstrtostr(), because filenames want to be treated as the local
encoding rather than utf8.  I think.)

hmm. ...   when I tried to use .toStdString(), I couldn't
either because I had QT3_SUPPORT enabled or not.....
or because anything else was missing?
... just wanted to remark it....

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[cannam]

On Sun, Sep 7, 2008 at 1:41 PM, Emanuel Rumpf <xbran@...> wrote:
> hmm. ...   when I tried to use .toStdString(), I couldn't

What is the error?

The header only declares this if QT_NO_STL is not defined, but I don't
think a reasonable configuration would define that.


Chris

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[cannam]

On Mon, Sep 8, 2008 at 6:30 PM, Chris Cannam
<cannam@...> wrote:
> On Sun, Sep 7, 2008 at 1:41 PM, Emanuel Rumpf <xbran@...> wrote:
>> hmm. ...   when I tried to use .toStdString(), I couldn't
>
> What is the error?
>
> The header only declares this if QT_NO_STL is not defined, but I don't
> think a reasonable configuration would define that.

Looking at your commit just now, I think that pretty much all of those
uses of qstrtostr(...).c_str() should instead be calls to either
toStdString().c_str() or toLocal8Bit().data().

If you can't compile it with your local system using toStdString(),
use toLocal8Bit().data() instead.  Actually, toLocal8Bit().data() is
probably the right default fix for most of our uses of the obsolete
Qt3 QString::data() method.


Chris

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[Emanuel Rumpf-2]

2008/9/8 Chris Cannam <cannam@...>:
> On Sun, Sep 7, 2008 at 1:41 PM, Emanuel Rumpf <xbran@...> wrote:
>> hmm. ...   when I tried to use .toStdString(), I couldn't
>
> What is the error?
>
misc/Strings.cpp: In function 'std::ostream& operator<<(std::ostream&,
const QString&)':
src/misc/Strings.cpp:

error: 'const class QString' has no member named 'toStdString'



> The header only declares this if QT_NO_STL is not defined, but I don't
> think a reasonable configuration would define that.
>

how to test for that?
I got that error with my first rg-qt4-port, and even recompiled qt4
with stl support.
So I'm pretty sure, I have it, unless I did something wrong.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[Emanuel Rumpf-2]

what about using:

std::string xxx = std::string( qstr.toAscii().data() );

instead?

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[cannam]

On Mon, Sep 8, 2008 at 6:57 PM, Emanuel Rumpf <xbran@...> wrote:
> what about using:
>
> std::string xxx = std::string( qstr.toAscii().data() );
>
> instead?

No, absolutely not.  We never want to constrain the conversion to
ASCII (or Latin-1 for that matter).

Use qstrtostr and strtoqstr for strings that are being stored for
later display in the GUI, and that we may want to convert back and
forth more than once.  (Reason: preserves UTF8 encoding in both
directions.)

Use toStdString() when the target is a std::string for immediate
display at the console (not in the GUI) or for use in an error message
or as a file or directory path.  (Reason: creates std::string
directly; uses local encoding; shorter than toLocal8Bit().data())

Use toLocal8Bit().data() when the target is a file or directory path
in a system call or similar.  (Reason: uses local encoding; creates
C-style string as desired)

I think.  Any advance on that from anyone else?


Chris

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[D. Michael McIntyre-3]

On Monday 08 September 2008, Chris Cannam wrote:

> I think.  Any advance on that from anyone else?

This sounds right to me.  I don't remember the context now, but I've used
toStdString() in at least one of my recent fixes, and it worked.  (Compiled
anyway.)

Or did I?  Maybe I deleted that because the overall file was still hopeless.  
The only toStdString() I see is
in ./src/document/MultiViewCommandHistory.cpp.  Did I do that?  Maybe.  I'm
too tired to check right now.

It builds anyway.
--
D. Michael McIntyre

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[Emanuel Rumpf-2]

2008/9/8 Chris Cannam <cannam@...>:

> Use qstrtostr and strtoqstr for strings that are being stored for
> later display in the GUI, and that we may want to convert back and
> forth more than once.  (Reason: preserves UTF8 encoding in both
> directions.)
>
> Use toStdString() when the target is a std::string for immediate
> display at the console (not in the GUI) or for use in an error message
> or as a file or directory path.  (Reason: creates std::string
> directly; uses local encoding; shorter than toLocal8Bit().data())
>

today, filesystems use utf8 too, as do some terminals (command-lines),
so I believe toLocal8 is appropriate here as well.

> Use toLocal8Bit().data() when the target is a file or directory path
> in a system call or similar.  (Reason: uses local encoding; creates
> C-style string as desired)
>
> I think.  Any advance on that from anyone else?
>
>

Now ... .toStdString() does not work here.
("error: 'const class QString' has no member named 'toStdString'")

It did not work with debians default qt4, nor with the sources
I compiled myself, to be shure I'd had STL enabled.
I still have the line at hand I used to configure:

./configure --prefix=/usr -stl -system-sqlite -qt3support
-optimized-qmake -silent

output from ./configure --help:
    -no-stl ............ Do not compile STL support.
 *  -stl ............... Compile STL support.


Maybe it's just me, but if not, then we should care about it.
Do I miss a compiler option?
If it's related to QT3_SUPPORT, then I guess toStdString() will
disappear soon too.


I'd suggest to use the functions, I implemented in Strings.h.
That way, we know at least, what we are doing and would have a central place, in
case we needed modifications:

for gui-strings:
qStrToStrUtf8( &qstr );
qStrToCharPtrUtf8( &qstr );

for file-acces / system-call:
qStrToStrLocal8( &qstr );
qStrToCharPtrLocal8( &qstr );


Now we know the target encoding.
But what is the source encoding ?
With QString I think we don't have to think about it, but
if we converted std:string to QString, we had to do
something like QString.fromUtf8( stdStr ) , in case stdStr was utf8 encoded.

I thinks it's best, to use utf8 where possible.
Only convert to target encoding (utf8 / local8) at the very end of the chain.
Convert to utf8 as soon as a string has been received. (not necessary
with QStrings I think)
Maybe we should thus convert some functions to accept QStrings instead ?

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[cannam]

On Tue, Sep 9, 2008 at 4:01 PM, Emanuel Rumpf <xbran@...> wrote:
> today, filesystems use utf8 too

Yes, but not all of them.  The local 8-bit encoding is not always
going to be utf-8.

> Now ... .toStdString() does not work here.
> ("error: 'const class QString' has no member named 'toStdString'")

It's a pity, because toStdString is the obvious best function for many
situations and I use it in all my other Qt4 code.  I've never had a
problem with it in the past (and fwiw, I use the Ubuntu packaged Qt4
normally).  However, if it doesn't work for you and it isn't obvious
to you why not, then I guess it won't be obvious to other people
either, so perhaps we should avoid it.

> Do I miss a compiler option?

The lines you just printed looked OK to me.

> If it's related to QT3_SUPPORT, then I guess toStdString() will
> disappear soon too.

No, it isn't anything to do with Qt3.  It's a current, recommended
function.  It should be the right function.

Oh well.

btw, it's wise to be wary of lifecycle issues when using things like
.toLocal8Bit().data().  The C-style string pointer returned will be
invalidated when the temporary object returned by toLocal8Bit is
deleted, which will usually be at the end of the same line of code.
This is therefore only suitable for use when the pointer is being
passed in to a function like a system call that uses it only within
the scope of the function, or when constructing something l ike a
std::string from it (which copies the data).

Of course, the same would apply when calling toStdString().c_str()
(the std::string is a temporary that will be deleted at the end of the
line, invalidating the C-style string as well).

> Now we know the target encoding.
> But what is the source encoding ?
> With QString I think we don't have to think about it, but
> if we converted std:string to QString, we had to do
> something like QString.fromUtf8( stdStr ) , in case stdStr was utf8 encoded.

Our std::strings that we pass around and store (e.g. in events) are
intended to be always utf8.  The encoding should be preserved when
they are converted back and forth using qstrtostr and strtoqstr.  The
vast majority of our string handling falls into this category -- it
works, it's right already and it shouldn't need fixing so long as
qstrtostr and strtoqstr remain correct.

The exceptional cases are those in which std::string or a C-style
string are created from QString in order to write to the console
directly or pass to a system call.  In these cases we ought to convert
to local 8-bit encoding when converting from QString.  We also have
some rather ugly situations in which a string is thrown directly as an
exception -- I'm not keen on that style anyway, but utf8 is probably
as good as any other encoding there.

I'm not sure whether there are any cases in which we convert from
std::string to QString but the std::string is not utf8 already?


Chris

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[Emanuel Rumpf-2]

2008/9/9 Chris Cannam <cannam@...>:

>
>> Now ... .toStdString() does not work here.
>> ("error: 'const class QString' has no member named 'toStdString'")
>
> It's a pity, because toStdString is the obvious best function for many
> situations and I use it in all my other Qt4 code.  I've never had a
> problem with it in the past (and fwiw, I use the Ubuntu packaged Qt4
> normally).  However, if it doesn't work for you and it isn't obvious
> to you why not, then I guess it won't be obvious to other people
> either, so perhaps we should avoid it.
>

Found by googling the STL-error:
------------------------------------------------

"this happens ONLY if you're using
a different STL version, other than the one used when Qt was
compiled.. "


"
Using different STL versions is a major NO NO....

Even assigned an optimized version of a STL string to a Debug version
can (and often does) cause problems.

STL has no interface/implementation separation... There is no .lib to
get linked in.  Everything is in the header.  This is by design.
"


" It is a bug in QT. definitely not in his
code and using the same STL will make us more it more confusing because
I didn't see any STL version info in the QT docs.

basically the toStdString() function is not very nice and you should
avoid it... unless you're willing to wait for a QT release for every STL
release and make sure they're the same which seem to be impossible to
me. and what about using other compilers that are compatible with
general libs that has different stl implementation ?
"


"this be a problem of mixing debug and release versions"




"Brian Hahn" suggested this operator code:

"
#include <QString>
#include <ostream>
#include <string>

std::string& operator += ( std::string& _Std, const QString& _QStr )
    {
    return _Std += _QStr.toLocal8Bit().data();
    }

std::ostream& operator << ( std::ostream& _Stream, const QString& _QStr )
    {
    _Stream << _QStr.toLocal8Bit().data();
    return _Stream;
    }



-- usage -

QString QStr = "Hello world";

std::string String;
String += QStr;

std::stringstream Stream;
Stream << QStr;

--------------

unfortunately you cannot overload the assignment operator =() without
modifying the QString class itself, which I do not recommend.

"

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[D. Michael McIntyre-3]

On Tuesday 09 September 2008, Chris Cannam wrote:

> On Tue, Sep 9, 2008 at 4:01 PM, Emanuel Rumpf <xbran@...> wrote:
> > today, filesystems use utf8 too
>
> Yes, but not all of them.  The local 8-bit encoding is not always
> going to be utf-8.

Including here, for instance.  I never converted my /home filesystem to UTF-8.

> > Now ... .toStdString() does not work here.
> > ("error: 'const class QString' has no member named 'toStdString'")
>
> It's a pity, because toStdString is the obvious best function for many
> situations and I use it in all my other Qt4 code.  I've never had a
> problem with it in the past (and fwiw, I use the Ubuntu packaged Qt4
> normally).  However, if it doesn't work for you and it isn't obvious
> to you why not, then I guess it won't be obvious to other people
> either, so perhaps we should avoid it.

Here's the relevant part of the header, in QtCore/qstring.h:

#ifndef QT_NO_STL
    static inline QString fromStdString(const std::string &s);
    inline std::string toStdString() const;
# ifdef qdoc
    static inline QString fromStdWString(const std::wstring &s);
    inline std::wstring toStdWString() const;
# else
#  ifndef QT_NO_STL_WCHAR
    static inline QString fromStdWString(const QStdWString &s);
    inline QStdWString toStdWString() const;
#  endif // QT_NO_STL_WCHAR
# endif // qdoc
#endif

So it looks to me like he's on track with the idea that compiling with STL
support should enable that code.

It's a mystery.  I guess he could watch QT compile and see if there's
a -DQT_NO_STL in there in spite of what he thought he told his build system.


As far as this whole discussion, I don't even really understand what any of
this is about.  I haven't studied the issue.  All I can say is that when it
comes to whose opinion I trust the most, you and I have worked together for
almost 10 years, Chris, and my default state is to agree with you unless I
have a reason to do otherwise, which I don't in this case.  If you feel
strongly about this toStdString() thing, then it's definitely worth the
trouble of figuring out why it isn't working for Emanuel, if at all possible.
--
D. Michael McIntyre

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[D. Michael McIntyre-3]

On Tuesday 09 September 2008, Emanuel Rumpf wrote:
> basically the toStdString() function is not very nice and you should
> avoid it... unless you're willing to wait for a QT release for every STL
> release and make sure they're the same which seem to be impossible to
> me.

Well, there you go.  That looks like a reason to have an opinion, and it looks
like Emanuel really has a point here.  That looks nasty.

We'd better figure something else out.  Is Emanuel's idea workable?  If so,
let's go that way.
--
D. Michael McIntyre

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[cannam]

On Tue, Sep 9, 2008 at 9:48 PM, D. Michael McIntyre
<rosegarden.trumpeter@...> wrote:
> If you feel strongly about this toStdString() thing

I feel strongly that it's irritating that it isn't working.  (btw,
Emanuel, the articles you quoted sound like they're talking about
binary compatibility rather than source headers?)

But I don't feel all that strongly about using this function.  It's
just one function, its behaviour is easily replicated, and we can make
do fine with a suitable wrapper that does "whatever works for
everyone" instead.  The route Emanuel is taking is fine with me.


Chris

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel