starting to feature MDI

[John Birch]

On Tue, 06 Mar 2001 21:59, Falk Brettschneider wrote:
> John Birch wrote:
> > > > 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 :-)
>
> But then the change is done within the:
> ####### kdevelop will overwrite this part!!! (begin)##########
> ...
> ####### kdevelop will overwrite this part!!! (end)############
>
> So I suppose changes made "by hand" will be overwritten, wont it?

I mean we change the dir itself, then kdevelop will use the new dir name. 
Which shows up yet another usability problem within kdevelop, namely how can 
we get kdevelop to rename a dir? It can't currently.

or I could add the lib name and version number to the project files and then 
use those instead. I'll see...

> > > 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?
>
> Sorry, only in case of emergency. I already have to care for a code copy in
> our company, for the QextMDI cvs-server and in the qt-addons project as
> well. I have this structure to be equal in all those projects... With
> different project structures I would lose the survey.
>
> > > 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?
>
> Maybe it's handleable.... But for instance libkdevelopqextmdi.so links
> against kpart in the defined Makefile.am additionally

qextmdi is an exception and kdevelop will ignore it.

>
> > but I suspect you'll want to do more before you've finished
>
> Of course. :-) But if you want, you can also hack the project...
>
> > a/
>
> Agreed
>
> > b/
>
> Agreed.
>
> > 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.
>
> Great. The problem is only: how can I get your features into 1.4 without
> getting my usuability-destructive change, too? :-) Do you commit to the
> 2_1_1 branch?

this is only for KDEVELOP_1_4 not for KDE_2_1_BRANCH. Is that what you mean? 
and I'll fix this all up later today.

>
> > And besides these two points, it's just far easier doing it in kdevelop
> > and that's always a pleasent surprise to me :-)
>
> Cool, if we could improve it in that way... :-)

surely can :-)

jbb

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