partselector

[Richard Dale]

On Thu, 10 May 2001, Bernd Gehrmann wrote:
> The more parts we get, the more it becomes clear that the current way of
> selecting them isn't sufficient. For example, when I develop a C++
> application, I want to use a native debugger, when I develop Java
> I want to use the java debugger. You normally don't want to use both
> at the same time (unless your're Richard ;-) This is only most obvious
> example since other parts are more 'hidden'.
Yes, even I don't run two debuggers at one, and use the excellent combination of
printf() and System.out.println() when debugging combined java/JNI/Qt/KDE code.
But I think we should allow for both debuggers for it (they should
have unique tab names for instance), but there is no need for that to be a
standard configuration for any 'normal' KDevelop project. The java debugger menu
currently reads 'Java Debugger' with a space, is that ok with the KDE UI
guidelines, should it be 'Jdb' or 'JavaDbg', 'JavaDebug' or similar instead?


On Thu, 10 May 2001, Bernd Gehrmann wrote:
> So I think we need configuration on a per-project basis. But maybe
> for some parts it makes sense to be present always, and not only
> when a project is loaded. What is the best way to implement this?
> Offer both a global and a per-project part selector? Let the parts
> decide themselves whether they are global or not? Any other
> possibilities?
Do we need entries like this in the project file?

<!DOCTYPE kdevelop ><kdevelop>
 <general>
  <projectmanagement>KDevAutoProject</projectmanagement>
  <primarylanguage>Java</primarylanguage>
  <languagesupport>KDevJavaSupport</languagesupport>
  <debugger>KDevJavaDebugger</debugger>
 </general>
</kdevelop>

On Fri, 11 May 2001, Ralf Nolden wrote:
> You could
> also imagine someone writing a part outside the project as a replacement
> for a part we have because he can handle things better with it. Then you
> need a simple way to decide which one to use. We could inspect the KDE
> mime-type dialog to think about how this can be done similar towards the
> user to decide which part in which order to use for which project type.
Do KParts have an attribute called 'goodness' or similar, for resolving this
sort of problem? Then you would set the goodness to a high value for a new and
better part than the standard one, and pick it up automatically. But you might
stll want to override 'goodness', so there would still be a need to select
parts.

-- Richard

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