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

List:       kde-core-devel
Subject:    Re: developer faq
From:       David Faure <david () mandrakesoft ! com>
Date:       2001-03-09 17:55:36
[Download RAW message or body]

On Friday 09 March 2001 16:04, Philippe Fremy wrote:
> On Thursday 08 March 2001 19:20, David Faure wrote:
> > On Thursday 08 March 2001 17:41, Philippe Fremy wrote:
> > > Hi,
> > >
> > > There use to be a developer faq on developer.kde.org but it has gone
> > > away. I don't what was inside, but while I develop daily for Kde, I have
> > > many questions that I would be glad to see answered in a faq. There are a
> > > few documents available, but they don't answer my questions.
> >
> > Would you put such a document together, if I answered your questions ? :)
> >
> 
> Yes, I will gather everything and put something online.

Great !

> > > - how to rebuild ksycoca database ?
> >
> > No, that's completely unrelated. "How" : by typing "kbuildsycoca".
> > "When": in theory never. But if you suspect a corruption of your database,
> > or if you think it hasn't picked up a change in the global or local desktop
> Exaclyt. For example, I just installed a kpart in my .kde/lib and a .desktop 
> but it doesn't show-up. What do I do ?

Investigate :-)
I mean, if it doesn't show up after running kbuildsycoca, then there's an even
more serious flaw somewhere.
Can't give any more tips here, it really depends on what the developer did wrong :)

> Mmh, I didn't remember the name of this program. It lacks a feature 
> 'check/uncheck all entries matching regexp', to help configuring it quickly.

There's --on <area> on the command line, where area is a number or a (sub)string...
But it's not a regexp, granted.

> The doc, the thing that never compiles!
Speak for yourself :-)

> Is there a way to 
> - always avoid the doc to compile ?
Yes - but this has just changed again so I'll let Stephan answer ;-)
Deinstalling any jade or docbook related package used to do the trick, in any case :-)

> - always avoid the doc to update when using cvs update ?
Don't think so.

> > The best way? Just using kdDebug(). Areas are more suited for libraries,
> > so that "users" of the libraries can turn off the library's debug output to
> > see their own.
> How do you define an area ?

Just like in kdebug.h
I don't think we want to document the whole KDE API in your FAQ :)
This is part of the API, so reading the API doc is the best place.

> I just read the doc for kdebugdialog, there is a serious flaw. Why isn't 
> there one window proposing to configure areas like in full mode or to check 
> area like in normal mode. Having two programs in one commandline is not a 
> good idea, especially when one feature is somehow hidden. There is no help 
> menu in kdebugdialog by the way.
> 
> Someone need to spend one hour or two to make it a decent tool. I would 
> prefer you to spend these hour on kword, so it is up to a normal developer 
> like me to fix it. Unfortunately, my personal agenda is already full with 
> other stuff.

Feel free to improve it if you really think it's necessary.
From my experience it's always been more than sufficient as it is now.
 
> Is there other cool targets to know in the Makfile ? I only know 
> make all, make clean and make distclean.

See below :)

> > > If I add a new QObject in my program, what should I do to get the .moc
> > > automatically generated ?
> >
> > METASOURCES = AUTO
> The thing is, if I add that QOjbect _after_ having generated the Makefile, in 
> a file that was already in the Makefile but didn't contain QObject, it won't 
> be noticed by the Makefile and my program won't compile, right ? I need to do 
> a perl am_edit for that, right ?

No, make force-reedit
That's the new target for today :)

Or use create_makefile[s] from kdesdk/scripts.

> > Add blah.skel or blah.stub to the _SOURCES line.
> Idem, will it be always noticed by the Makefile ?
Yes, because adding that one requires to edit Makefile.am -> Makefile gets regenerated.

> > > - how to print a QString ?
> > your ~/.gdbinit where /mnt/kdecvs is the path to your sources,
> > in which you checked out the kdesdk/scripts module :)
> cool, this is not listed in the README

Oh, the README under kdesdk/scripts ? Forgot about that one. Fixed.

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://perso.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today

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