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

List:       kdevelop-bugs
Subject:    [Bug 109953] KDevelop should warn if an external tool isn't present
From:       kdevelop-bugs-admin () barney ! cs ! uni-potsdam ! de
Date:       2005-08-26 22:08:28
Message-ID: 20050826220828.2757.qmail () ktown ! kde ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=109953         




------- Additional Comments From greatbunzinni gmail com  2005-08-27 00:08 -------
First of all, please forgive my "should be corrected imediately" remark. Unfortunately it came off \
sounding terribly like a command, which it wasn't. I'll try to rephrase and explain what I intended to \
say.

There are components in KDevelop which are hard-linked to it but that depend on 3rd party packages. \
Altough they bring features to kdevelop which are very usefull, I don't see how it is a good thing to \
list those features before the 3rd party packages are configured in KDevelop or even installed in the \
system. It isn't a matter of wishing that KDevelop did sanity and existencial checks on the plugins. It \
is simply a matter of enabling and listing the plugin's functionality when it is installed/configures and \
disabling it when it is uninstalled/configured. I don't see why this is a bad thing. Oh, and I use the \
term "plugin" assuming that the 3rd party features aren't being hard-coded into kdevelop, which wouldn't \
be exactly the best thing to do.

So, to rephrase what I said previously, listing functionality before it is available and without \
installing anything isn't the best way to go. It is better if the user gets what he sees. And to avoid \
the bad impression that "loose-ends" give, it would be in the best interests of the KDevelop project that \
this issue would be tackled.


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