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