starting to feature MDI

[John Birch]

On Tue, 06 Mar 2001 20:22, Falk Brettschneider wrote:
> Hi!
>
> John Birch wrote:
> > Hmmm yes, but both kwrite and qextmdi will always be loaded so what have
> > we really gained given that print and dbg are smallish. Also is that with
> > or without debug.
>
> I think it's very unprofessional to always link 13MB even if only one tiny
> single cpp file has changed in KDevelop. My CPU and memory are really
> hassled! ;) Now (with the split of code in several libraries) I only link
> what is really necessary. Changing a piece of cpp code doesn't become a
> pain any more.
>
> > > MDI is initally built in but is just committed to give you a chance to
> > > contribute the development (as we dealed with JBB and Ralf). Take a
> > > look at class DocViewMan, the central point for managing multiple
> > > documents that can have multiple views.
> > > CKDevelop::initView() and CKDevelop::switchToFile has initially
> > > changed, but is very unfinished, of course.
> > >
> > > I rebuild the kdevelop.kdevprj by the .kdevprj-file generator from
> > > KDevelop-1.4. (Works beaut BTW :-)
> >
> > Arrrgh - no - You were supposed to add qextmdi to the _existing_ kdevprj
> > file.
>
> The existing *.kdevprj file is very very restricted for the reasons listed
> below... :(
>
> > This has made the project file a custom file and it can not now recreated
> > the makefiles, so adding new files etc has to be done by hand. Also why
> > did you create the libkdevelop* names? This again means that the
> > makefiles cannot be regenerated.
>
> 1.) The old kdevelop.kdevprj restricts to use library names having the
> _same_ name as the source subdir. :-( This means we would get:
>       libdbg.so, libkwrite.so, libvc.so, ... which does not guarantee that
> we wouldn't get naming conflicts with other KDE libraries also being
> located in $KDEDIR/lib. (At least libkwrite.so). With the prefix
> libkdevelop* we simply avoid that.

Yes it is a restriction in kdevelop if kdevelop manages the libs - so we just 
change the dir name, this doesn't seem a big deal :-)

> 2.) The old kdevelop.kdevprj does not support such subdir structures like
> qextmdi/include, qextmdi/src, qextmdi/res. :-(

Not entirely - it means that kdevelop cannot _manage_ this structure. It can 
avoid it though...

Another alternative is to change the dir structure of qextmdi in kdevelop. 
Are you really very keen to hang onto that structure given the way kdevelop 
works?

> 3.) It seems there's no possibility to configure the subprojects. Only a
> change from static to dynamic and vice versa seems to be supported. :-(
> Some projects can need extra settings - where do I set them in such a case?

Add them after the kdevelop managed stuff. But what settings are you talking 
about in this case? I have version number settings - is there more?

> > It'll be good to fix this up so that we can use kdevelop to generate the
> > makefiles.
>
> It was 3:00am when I finished. 8o) Now, it's 7:30am and I'm already at work
> again. ;) I think I'll have a free day this day..., sorry

I wasn't meaning for you to do it, mate :-) I know you not only worked hard 
on it but I suspect you'll want to do more before you've finished

> > One other thing, why have you used libkdevelopqextmdi rather than an
> > installed libqextmdi, if it exists? I don't know _how_ that would be done
> > btw, Just asking...
>
> As long as KDevelop uses a copy of the QextMDI code which is a cvs version
> between some version numbers, I cannot guarantee that the official QextMDI
> version (1.0 or 2.0) for instance provided by SuSE-7.1 is compatible.
> But if I restricted the QextMDI copy to official version numbers, I would
> call it libkextmdi.so.2.0.0 then (because -DNO_KDE isn't set)


Now the reason I want kdevelop to manage the files is twofold

a/ It allows others to add and change kdevelop and supply us with new 
functionality without having to hassle with makefiles. This has always been a 
big hurdle for people - hence one of the reason for kdevelop's existance :-)

b/ It teaches us where the weaknesses in kdevelop are as we work with it. 
Just doing this for instance throws us up against the following issues
 - cannot set a version number against a shared lib
 - dir structure is restrictive
 - cannot set a lib name different to the dir
 - bug: the header templates weren't added to existing files when I added 
them to the project.

To me, both these points far outweigh the hassles we have in doing it and the 
hassles are not great even then. You're allowed to disagree, of course :-) 
but unless you are absolutely adament against it, I will fix this up so 
kdevelop can manage these libs (qextmdi excepted) In fact on my machine most 
of this has been done, I just have a bit of renaming left, but I'll leave 
this until I wake up again tommorrow.

And besides these two points, it's just far easier doing it in kdevelop and 
that's always a pleasent surprise to me :-)

jbb

-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«