| Summary: | "Execute" shouldn't be available if there is no executable target. | ||
|---|---|---|---|
| Product: | [Applications] kdevelop | Reporter: | Diederik van der Boor <vdboor> |
| Component: | general | Assignee: | KDevelop Developers <kdevelop-devel> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | wishlist | ||
| Priority: | LO | ||
| Version: | 4.0.0 | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Diederik van der Boor
2004-03-22 13:40:09 UTC
No, this is because that project type doesn't produce an executable. A Control Center Module is a dynamically loadable plugin for the KDE Control Center, not a selfsufficient executable. Registered (installed where KDE can find them) modules can be ran seperate from kcontrol using the 'kcmshell' command. > No, this is because that project type doesn't produce an executable.
Pardon my ignorance, but why is the "Execute" menu option visible when I create a control center module? I've tried to press it, but nothing happened. imho it either should be grayed out, or a message should appear explaining what to do next. I hope I didn't forget something here, but it was the first thing I naturally tried to do
It's visible because it is always visible. One could make the argument that if a project lacks an executable target, this menu entry shouldn't be available. Maybe a nice thing for someone to code some day, when it's raining, but hardly something to make a big fuss over. Changing to wish. I agree, it should have been a wish-report. btw, one thing that confuses me, the template of a control center module doesn't provide a user-interface, or something else that's initially available when you create that project. (I think this is a valid issue for this bug after all.) Currently if you try to execute a non-existent file, it will tell you that... are we changing the purpose of this bug to "disable run action when no project is open"? Or do we really want to disable the action when the config is wrong (and thus further confuse the user) Hamish I think I don't quite understand. Its important that our run-support doesn't depend on a project being open. I don't think we need to disable the action when the config is wrong and with the above I don't see why "run" should be disabled when no project is open. Unless you're talking about a 'run the default target in current project' action, which is completely wrong in itself. There's no "current project" and there surely is no "default" target. Running a target of a project should be a context-menu entry in the project tree (or anywhere else a project context is created) and we should have a way of re-running the last "execution". So actually I think we should close this as fixed or wontfix, as KDevelop4 will always allow to run something, no matter what projects are open. Andreas, my only point was the "run" button seams to be a "dummy" button in some project configurations. if pressing the run button does nothing, could you give a reason why, or just have it grayed out (so the user at least knows, but still has to figure out why). other then that, this is indeed a very low prio wish. This will be a bit different in KDevelop4, the run button will just re-run the last run executable on clicking. It can't just run the default target because it would need to have an apropriate selection in the project tree for that. For KDevelop3 its a wontfix, for KDevelop4 its in the work to be different enough. I hope you don't mind that I close this as wontfix then. |