Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| An alternative is to wait until a 0.10.37 is released. There has been
| so much time since 0.10.35 that I suspect many people have been
| sending patches lately.
0.10.37 is out now.
--
Lgb
Allan Rae <[EMAIL PROTECTED]> writes:
| I've updated libsigc++ in the stable branch. It should be a bit more
| cross platform/compiler happy now although I suspect that Sun CC still
| won't be able to compile it.
|
| Feel free to test it -- assuming you can get it.
|
| BTW,
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
Allan> BTW, has anyone else noticed that gettext-0.10.36 has been
Allan> released? Should we be updating that in 1.2.0cvs? (I'm not
Allan> volunteering BTW)
Yes, I saw that. We should probably do the update, since it will fix
some of our pro
I've updated libsigc++ in the stable branch. It should be a bit more
cross platform/compiler happy now although I suspect that Sun CC still
won't be able to compile it.
Feel free to test it -- assuming you can get it.
BTW, has anyone else noticed that gettext-0.10.36 has been releas
are concerned. Just for paranoia.
We'll change if and when libsigc++ does -- in otherwords probably never.
Otherwise we end up with problems with #include'ing the headers from
either the internal or external library.
Allan. (ARRae)
On Sun, 30 Jan 2000 23:06:39 -0800, Karl Nelson wrote:
>One last suggestion is to rename sigc++config.h sigc++/config.h
>in all the headers so that you don't need to include sigc++
>in your include paths. (and of course make the corresponding
>rename in the configure.in.)
Hi,
once again I'
> Karl,
> the sigc++ acconfig.in patch needed to get things to compile correctly on NT,
> did that go into CVS?
> Allan could you please include that?
Yep, the change is in. Since Allan is building from a CVS, it
should be in when he builds it with the most recent makeLyx script.
--Karl
Karl,
the sigc++ acconfig.in patch needed to get things to compile correctly on NT,
did that go into CVS?
Allan could you please include that?
Background: libsigc++-0.8.6 does not compile out of the box on cygnus-b20
because there are little issues with the configuration. Karl send me a patch
>
> Compile speed and saving a few extra bytes in the distribution. It is
> also a heavy handed way of forcing everyone to think carefully about why
> they want more than 2 parameters.
I have ways of vastly reducing the number of templates involved
but they are much to space hungry (involve cha
On Sun, 30 Jan 2000, Karl Nelson wrote:
> Okay, I will poke at it a bit. You really don't want to
> generate the *.h files in the src_dir though as it can mess some
> things up. Not a problem, I will just add $(builddir) to the include
> path as well to fix that.
You're right. I was in a hurr
> >
> > You likely need to add a "-I $(top_srcdir)/sigc++/macros" or something
> > to that effect in the Makefile.am.
>
> That will make m4 find the template.macros.m4 however the bigger problem
> is that the generated headers are put into:
>
Okay, I will poke at it a bit. You really don't want to
generate the *.h files in the src_dir though as it can mess some
things up. Not a problem, I will just add $(builddir) to the include
path as well to fix that.
BTW, just curious why you are truncating the signal system numbers down?
Those
On Sun, 30 Jan 2000, Karl Nelson wrote:
> >
> > An extremely annoying thing about libsigc++ is that is doesn't support
> > VPATH compiles. So it has broken those for LyX unless you use an external
> > library.
>
> Not sure what a VPATH compile is. Care to
>
> An extremely annoying thing about libsigc++ is that is doesn't support
> VPATH compiles. So it has broken those for LyX unless you use an external
> library.
Not sure what a VPATH compile is. Care to clue me in?
(I know autoconf well, automake poorly, and rpm/deb not at a
An extremely annoying thing about libsigc++ is that is doesn't support
VPATH compiles. So it has broken those for LyX unless you use an external
library.
So if you try this and it fails don't blame me blame Karl. Then get a cvs
copy of libsigc++ and fix it for Karl (and us).
> I have thought a bit about this, and perhaps we should switch to the
> more generally accepted term: "Dialog".
> Popups are really something else...
I'm not sure if Allan already did this renaming, but I strongly agree
that we should use the term "dialog".
> - work on the painter
>
Karl Nelson <[EMAIL PROTECTED]> writes:
| > On Thu, 27 Jan 2000 11:47:55 +1000 (GMT+1000), Allan Rae wrote:
| >
| > >The first draft of libsigc++ integration uses a slightly modified version
| > >of the libsigc++ configure.in in the sigc++ directory. Hmmm, does NT let
|
On Thu, 27 Jan 2000 12:49:03 -0800, Karl Nelson wrote:
>> On Thu, 27 Jan 2000 11:47:55 +1000 (GMT+1000), Allan Rae wrote:
>>
>> >The first draft of libsigc++ integration uses a slightly modified version
>> >of the libsigc++ configure.in in the sigc++ directory. Hm
ing this. At present it would be
> better to not mess with libsigc++, i.e. use that thing out of the box,
> since that's what it was made for. If, at a later point this would
> become a real issue I am sure a solution can and will be found. But
> maybe I am misunderstanding what you wer
> On Thu, 27 Jan 2000 11:47:55 +1000 (GMT+1000), Allan Rae wrote:
>
> >The first draft of libsigc++ integration uses a slightly modified version
> >of the libsigc++ configure.in in the sigc++ directory. Hmmm, does NT let
> >you have a directory called "sigc++"
Allan,
long post indeed.
Allan Rae wrote:
> I noticed you filed a report to the libsigc++ list.
Yes, I havent gotten any replies, I have not subscribed to the list but the issue
was:
libsigc++ version 0.8.5 compiles and works on cygnus b20 NT version 0.8.6 does not
compile due to a fau
On Thu, 27 Jan 2000 11:47:55 +1000 (GMT+1000), Allan Rae wrote:
>The first draft of libsigc++ integration uses a slightly modified version
>of the libsigc++ configure.in in the sigc++ directory. Hmmm, does NT let
>you have a directory called "sigc++"? What about OS/2?
OS/2
I forgot to mention libsigc++ will drastically affect which compilers will
be able to compile LyX. It looks like gcc-2.7.2 will never work and
gcc-2.8.x is only just capable perhaps-maybe (sorry JMarc looks like
you'll have some extra work).
Libsigc++ is developed with egcs-1.1. It h
On 27 Jan 2000, Lars Gullik Bjønnes wrote:
> Allan Rae <[EMAIL PROTECTED]> writes:
>
> [I dropped the sigc++ list]
It was just Karl's private mail address not the list.
> So you are not letting the included sigc++ use its own ./configure?
My first draft does but its a pain -- 12 hours yesterd
lthough that may
| change after a long arguement and much swearing) and we only compile it as
| a static library that isn't installed. If someone wants a libsigc++
| library on their system then they should get the real thing.
Agree. So you are not letting the included sigc++ use its own
./con
Tue, 25 Jan 2000, Dr. Ing. Roland Krause wrote:
> Allan, thanks for your reply.
> Yesterday I took some time to look closer into libsigc++ and I must
> say, that it is pretty good. It is really easy to use and I do not
> even think that it is to large to incorporate. If it really hold
On Mon, Mar 08, 1999 at 10:46:56AM +1000, Allan Rae wrote:
>
> One last little bit of explanation for this disjoint thread.
> Allan. (ARRae)
> PS Thanks for the feedback Asger + Amir.
>
I seem to be all over the list today. However, I won't accept the blame for
this one. Allan spells 'therefore
One last little bit of explanation for this disjoint thread.
Allan. (ARRae)
PS Thanks for the feedback Asger + Amir.
-- Forwarded message --
Date: Fri, 05 Mar 1999 12:27:52 -0800
From: Karl Nelson <[EMAIL PROTECTED]>
To: Allan Rae <[EMAIL PROTECTED]>
Subject: Re: [gt
[Should the interface provide advanced functionality or not.]
> So the question that this raises it to whom this part of the signal
> system is targeting?
I feel that power is the thing to aim for. We should not decide on the behalf
of the users of the signal/slot system what constitutes a good
A bit more discussion about libsigc++. Don't worry I'll stop forwarding
these soon.
Allan. (ARRae)
-- Forwarded message --
Date: Thu, 04 Mar 1999 22:07:49 -0800
From: Karl Nelson <[EMAIL PROTECTED]>
To: Allan Rae <[EMAIL PROTECTED]>
Subject: Re: [gtkmm]
ssage --
Date: Thu, 04 Mar 1999 18:04:10 -0800
From: Karl Nelson <[EMAIL PROTECTED]>
To: Allan Rae <[EMAIL PROTECTED]>
Subject: Re: [gtkmm] Libsigc++
Glad you liked it. As you dicover other problems or
awkward parts of the API, please mail me.
Now I need a small amount of feedba
I contacted Karl Nelson who is the main author of libsigc++ with a few
questions about documentation etc. I enclose below his informative
response.
Allan. (ARRae)
-- Forwarded message --
Date: Thu, 04 Mar 1999 03:20:12 -0800
From: Karl Nelson <[EMAIL PROTECTED]>
To: All
AR> I forgot to mention that a number of wrappers are being written
AR> around this implementation to emulate the gtk-- signals we've
AR> grown to know and love as well as Qt signals/slots.
AR> The gtk-- signal system will eventually be replaced by libsigc++
AR> (in case
lementation to emulate the gtk-- signals we've grown to know and
love as well as Qt signals/slots.
The gtk-- signal system will eventually be replaced by libsigc++ (in case
you hadn't figured that out already :)
Allan. (ARRae)
which has changed from what we're used to in gtk-- (it has in fact
reverted to something closer to the original API for signals in gtk--).
setenv CVSROOT ":pserver:[EMAIL PROTECTED]:/cvs/gnome"
cvs login
hit for password
cvs co libsigc++
Allan. (ARRae)
35 matches
Mail list logo
