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

List:       kde-devel
Subject:    Re: Nana and KDE
From:       Mirko Sucker <mirko.sucker () unibw-hamburg ! de>
Date:       1999-11-21 17:39:04
[Download RAW message or body]

Phil Maker wrote:

> > Currently, it is considered to (finally) add Nana as the basic KDE debugging
> > system to the KDE sources. A debugging handler specific to the KDE´s user
> > interface will be developed on top of it.
>
> Excellent, I've got a few more improvements to add into the next version
> contributed by Paul Suggs. I'm planning on a new release in the next month
> but there shouldn't be too many user visible changes (hopefully).
>
> > To test this, I took the nana-2.4 package, cut out the src directory and added
> > it to my local kdelibs copy as a subdirectory. I modified the Makefile.am there
> > to produce a dynamically linked library called libnana.so.2.0.4 (just a guess).
> >
> > Is there any reason to use a statically rather than a dynamically linked
> > version of the library?
>
> Its static currently because I don't understand how to do dynamic libraries
> across all platforms. If it is easy to autodetect this with autoconf then
> fine.

Our library maintainer has quite a lot of experience in this matter. The
KDE libraries, which are heavily portable, use shared versions as much as possible.
Integrating Nana in the source trees should be easy.
Are you able to list the system types Nana is known to work on?

> One minor point, the name config.h scares me a bit, perhaps an easier
> way would to reverse the including. You produce a file called perhaps
> kde-nana.h which looks like:
>
>         #ifndef _KDE_NANA_H_
>         /* kde-nana.h - standard KDE setup for nana */
>         #define I_DEFAULT_HANDLER .... /* options */
>
>         #include <nana.h>
>         #include <L_buffer.h>
>         #endif

config.h is created by the autoconf stuff, it contains merely the same definitions
and settings you handle over using the command line. Excerpt:

/* Define if you have the vsnprintf function.  */
#define HAVE_VSNPRINTF 1

/* Define if you have the <X11/ICE/ICElib.h> header file.  */
#define HAVE_X11_ICE_ICELIB_H 1

/* Define if you have the <X11/extensions/shape.h> header file.  */
#define HAVE_X11_EXTENSIONS_SHAPE_H 1

/* Define if you have the <alloca.h> header file.  */
#define HAVE_ALLOCA_H 1

That is why I had to include it. Minor problem.

There is a kind of KDE specific debugging support (kdebug.h), currently. After
integrating Nana, I would port the functions/macros there to use Nana and write some
GUI-based log handlers, for example.

> ... > PS: I forwarded this message to kde-core-devel@kde.org. If you do not mind,
> I
> > will forward your answer, too. If you like, you might get posting permissions
> > to it to be able to answer Nana-specific questions. Why not join KDE?
>
> I'd be happy/honoured to assist the KDE project for the nana stuff,
> the only problem is I'm a bit busy running my own company currently so
> I'm afraid my contributions would have to be limited to nana and
> perhaps a bit of advice/tool support for testing.
>
> Would it be considered appropriate to be on the list with a procmail
> filter only accepting nana in the subject/body?

Of course, it would be a lot of help if you could answer to problem reports
concerning the Nana stuff. You have far more experience with it than we.
Write to Martin Konold (konold@kde.org) for posting permissions on
kde-core-devel@kde.org, this is the mailing list dealing with KDE library
development.
Greetings,
--Mirko.

--
Denn der  Mensch  liebt und ehrt den  Menschen,  solange er ihn
nicht zu beurteilen vermag, und die Sehnsucht ist ein Erzeugnis
mangelhafter Erkenntnis. (Thomas Mann)

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