Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
Auto-layout switching for debugger
Ceniza:
Could those textctrl to write the layout name be changed to a combobox where you can select one of the current layouts + an empty one that would mean 'no change'?
mandrav:
--- Quote from: Ceniza on January 11, 2006, 08:08:27 pm ---Could those textctrl to write the layout name be changed to a combobox where you can select one of the current layouts + an empty one that would mean 'no change'?
--- End quote ---
See below...
--- Quote from: 280Z28 on January 11, 2006, 05:21:50 pm ---
--- Quote from: thomas on January 11, 2006, 05:05:46 pm ---
--- Quote from: 280Z28 on January 11, 2006, 04:57:35 pm ---Can you make it:
--- End quote ---
Why? The event based approach is a lot better, as it is truly universal.
--- End quote ---
Huh? We must not be talking about the same thing. :?
--- End quote ---
Thomas knows what he 's talking about. The layout switch (from the debugger) is done by sending an event to the app.
What you (and Ceniza) probably missed is that the docking system is not part of the SDK. It is part of the main app. The SDK and plugins know absolutely nothing about wxAUI/wxDockit/wxIFM/whatever-docking-system-is-in-use. And that's A Good ThingTM. It allows us to easily switch docking systems by just updating the app.
The SDK and plugins only know that they can send the app some docking-related events. What the app does with them, is none of their business.
In other words: the SDK and plugins are not bound with the app. The app is bound to them...
And because events are of the fire-and-forget kind (i.e. we can't get return values from them), Ceniza you got your answer about retrieving a list of layouts...
yop:
--- Quote from: mandrav on January 12, 2006, 09:46:07 am ---In other words: the SDK and plugins are not bound with the app. The app is bound to them...
--- End quote ---
That is after all what a sdk is all about
Chriss:
maybe it could be possible to make a standard debug layout, for those who don't want to create a new layout. It would be more user-friendly
280Z28:
--- Quote from: mandrav on January 12, 2006, 09:46:07 am ---
--- Quote from: Ceniza on January 11, 2006, 08:08:27 pm ---Could those textctrl to write the layout name be changed to a combobox where you can select one of the current layouts + an empty one that would mean 'no change'?
--- End quote ---
See below...
--- Quote from: 280Z28 on January 11, 2006, 05:21:50 pm ---
--- Quote from: thomas on January 11, 2006, 05:05:46 pm ---
--- Quote from: 280Z28 on January 11, 2006, 04:57:35 pm ---Can you make it:
--- End quote ---
Why? The event based approach is a lot better, as it is truly universal.
--- End quote ---
Huh? We must not be talking about the same thing. :?
--- End quote ---
Thomas knows what he 's talking about. The layout switch (from the debugger) is done by sending an event to the app.
What you (and Ceniza) probably missed is that the docking system is not part of the SDK. It is part of the main app. The SDK and plugins know absolutely nothing about wxAUI/wxDockit/wxIFM/whatever-docking-system-is-in-use. And that's A Good ThingTM. It allows us to easily switch docking systems by just updating the app.
The SDK and plugins only know that they can send the app some docking-related events. What the app does with them, is none of their business.
In other words: the SDK and plugins are not bound with the app. The app is bound to them...
And because events are of the fire-and-forget kind (i.e. we can't get return values from them), Ceniza you got your answer about retrieving a list of layouts...
--- End quote ---
An SDK based approach might work like this:
1) When the plugin starts, it says "store the current view (whatever it may be for [insert name] library in use) temporarily (not to disk as a user layout) as 'debugger_temp_layout'" or any unique name that the debugger has come up with.
2) When the plugin is about to end, it says "store the current view permanently (in some irrelevant manner so long as it has access to it by name the next time the program runs) with the name 'debugger_layout'" then "restore the temporary view named 'debugger_temp_layout'"
The plugin only cares that a current "view" (abstract sdk concept that can be linked to whatever internal implementation is used by the app) can be referenced by name, and stored at least permanently with the possible option of temporarily. If the layout engine changes and a view from the old implementation is requested, just return "View not found" and the plugin should be happy.
This is both event based and covers my request. :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version