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