Bug 284254 - New debugger configuration half-dirty
Summary: New debugger configuration half-dirty
Status: NEW
Alias: None
Product: CDT
Classification: Tools
Component: cdt-debug (show other bugs)
Version: 6.0   Edit
Hardware: Other Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: cdt-debug-inbox@eclipse.org CLA
QA Contact: Jonah Graham CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-22 08:36 EDT by Vladimir Prus CLA
Modified: 2020-09-04 15:19 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Prus CLA 2009-07-22 08:36:10 EDT
1. Create and build new C project.
2. Create new launch config, using "C/C++ Local Application" type.
3. Observe that project and binary were defaulted. Also observe that "Apply" button is grayed out.
4. Switch to debugger tab.

Observed behaviour: the Apply button becomes enabled.
Expected behaviour: since I did not actually change anything, Apply button
should remain disabled.

This bug appears to be related to 

    https://bugs.eclipse.org/bugs/show_bug.cgi?id=284251

in that missing call to setDefaults for the debugger page causes some things, like name of debugger, to be not saved in the launch config. Then, after switching to a new tab, performApply on that tab is called, which saves the default name of debugger, "gdb" that initializeFrom used. Therefore, the configuration now differs.

I am filing this separately because there are different ways of fixing 284251 and some of them might leave this one still unfixed.
Comment 1 Vladimir Prus CLA 2009-07-22 09:26:48 EDT
In fact, it seems to be now that no easy fix 284251 will fix this one, and here's why. When a new configuration is created, we call setDefaults for all tabs. At this point, the tabs exists, but UI for them does not. The dynamic tab for the chosen debugger is not created yet. So, while the initial configuration might contain the selected debugger id, it cannot contain any default options for it.

When this newly created configuration is loaded via initializeFrom, loadDebuggerCombo sets the debugger combo index to the right value, and then creates page specific for that debugger and then calls setDefaults on it. At this point, the configuration shown by the UI is no longer equal to what setDefaults created, so the Apply button is enabled.

The right solution would be to make setDefaults create a complete default config, including options for the selected debugger. Right now, it does not seem possible, because the page is not created yet, and even the debugger combo is not created yet, so the solutions are either:
1. Create enough of UI before calling setDefaults
2. Move initialization of defaults into an UI-independent "Model" class