[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]