|
Size: 1743
Comment:
|
Size: 3963
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 3: | Line 3: |
| 1. A simple way to add support for custom (read "written by you") controls. I think it might be really cool to only have to add a function that returns a dict of the attributes that can be set on the control, and then add the module that contains the control to a list somewhere accessible from the XRCed GUI. | 1. A simple way to add support for custom (read "written by you") controls. I think it might be really cool to only have to add a function that returns a dict of the attributes that can be set on the control, and then add the module that contains the control to a list somewhere accessible from the XRCed GUI. --EliGolovinsky |
| Line 5: | Line 5: |
| * One way to approach this is to use a plugin-in or drop-in architecture where every widget type has it's own module located in a certain directory. The module contains everythign that is needed to allow XRCed to support that widget, instead of having bits and pieces scattered around the XRCed code. When XRCed starts up it can load all modules in this directory and build it's menus and control bar based on what it finds loads. | * One way to approach this is to use a plugin-in or drop-in architecture where every widget type has it's own module located in a certain directory. The module contains everythign that is needed to allow XRCed to support that widget, instead of having bits and pieces scattered around the XRCed code. When XRCed starts up it can load all modules in this directory and build it's menus and control bar based on what it finds loads. --RobinDunn |
| Line 7: | Line 7: |
| 1. A graphic way to put controls on a container at a fixed position with a fixed size. I even think this should be the default behavior to ease the use of XRCed for first time users. | 2. A graphic way to put controls on a container at a fixed position with a fixed size. I even think this should be the default behavior to ease the use of XRCed for first time users. --EliGolovinsky |
| Line 9: | Line 9: |
| 1. A way to define which event handlers the control should handle. The code generator (pywxrc) will then be able to generate empty overridable methods. This one is already on Eli's list and will hopefully be implemented soon. |
3. A way to define which event handlers the control should handle. The code generator (pywxrc) will then be able to generate empty overridable methods. This one is already on mys list and will hopefully be implemented soon. --EliGolovinsky |
| Line 12: | Line 11: |
| 1. Code generation for languages other than Python. Eli will probably implement the C++ code generation, but maybe we should help our wxRuby and wxPerl friends as well. | 4. Code generation for languages other than Python. I will probably implement the C++ code generation, but maybe we should help our wxRuby and wxPerl friends as well. --EliGolovinsky |
| Line 14: | Line 13: |
| 1. Refactor to make it easy to embed XRCed functionality into other applications, such as full fledged IDEs or RAD tools. | 5. Refactor to make it easy to embed XRCed functionality into other applications, such as full fledged IDEs or RAD tools. --RobinDunn |
| Line 16: | Line 15: |
| 1. An option to always set default 5pt borders on all sides for all new controls. | 6. An option to always set default 5pt borders on all sides for all new controls. --EliGolovinsky |
| Line 18: | Line 17: |
| 1. A way to select multiple controls for delete / cut / copy | 7. A way to select multiple controls for delete / cut / copy --EliGolovinsky |
| Line 20: | Line 19: |
| 1. The ability to select a group of controls/containers and say "wrap these in a sizer of this kind". | 8. The ability to select a group of controls/containers and say "wrap these in a sizer of this kind". --DonDwiggings 9. Drag-and-drop of controls for reorganization. One issue I found while trying to use XRCed the other day was that trying to insert a predecessor sibling was a bit of a pain. Offering a drag-and-drop method for moving around entire sections of the tree would be nice. One would need to be careful about whether a drop is 'insert as sibling before', 'insert as sibling after', and 'add as child', though I believe the child case is solvable with temporary dummy controls (you only need to add siblings). --JosiahCarlson 10. Allow importing part of or all of another XRC file into the one being edited. --DonDwiggins 11. Provide for "templates" or a kind of macro facility that makes it easy to do common things like label-control pairs. --DonDwiggins * For example, this could be implmented by having a Insert Template toolbar item that allows the user to select from a list of named items. When one is selected it simply inserts tree nodes from the template to the current location in the tree. The templates themselves can simply be snippets of XRC XML located in a certain directory (or perhaps a standard location and also a location in the user's documents directory.) We should also allow the user to select part of or all of their current XRC tree and save it as a template. --RobinDunn 12. Allow specifying the size of a window (control or container) in terms other than absolute pixels. For instance, "I want a text control just large enough to hold the string '12345-6789' in the standard font". For another: make this window 110% of the size of that other one (horizontally, vertically, or both). --DonDwiggins * This will require modifications to the C++ XRC code, and will probably be a hard sell unless we can come up with a specific and simple set of alternate sizing methods. The percentage method may also need support from the sizers. --RobinDunn 13. Allow specifying one or both of a minimum and maximum size. --DonDwiggins * This one will also need changes to the C++ XRC code, but will be an easy modification. |
XRCed Wish List
1. A simple way to add support for custom (read "written by you") controls. I think it might be really cool to only have to add a function that returns a dict of the attributes that can be set on the control, and then add the module that contains the control to a list somewhere accessible from the XRCed GUI. --EliGolovinsky
One way to approach this is to use a plugin-in or drop-in architecture where every widget type has it's own module located in a certain directory. The module contains everythign that is needed to allow XRCed to support that widget, instead of having bits and pieces scattered around the XRCed code. When XRCed starts up it can load all modules in this directory and build it's menus and control bar based on what it finds loads. --RobinDunn
2. A graphic way to put controls on a container at a fixed position with a fixed size. I even think this should be the default behavior to ease the use of XRCed for first time users. --EliGolovinsky
3. A way to define which event handlers the control should handle. The code generator (pywxrc) will then be able to generate empty overridable methods. This one is already on mys list and will hopefully be implemented soon. --EliGolovinsky
4. Code generation for languages other than Python. I will probably implement the C++ code generation, but maybe we should help our wxRuby and wxPerl friends as well. --EliGolovinsky
5. Refactor to make it easy to embed XRCed functionality into other applications, such as full fledged IDEs or RAD tools. --RobinDunn
6. An option to always set default 5pt borders on all sides for all new controls. --EliGolovinsky
7. A way to select multiple controls for delete / cut / copy --EliGolovinsky
8. The ability to select a group of controls/containers and say "wrap these in a sizer of this kind". --DonDwiggings
9. Drag-and-drop of controls for reorganization. One issue I found while trying to use XRCed the other day was that trying to insert a predecessor sibling was a bit of a pain. Offering a drag-and-drop method for moving around entire sections of the tree would be nice. One would need to be careful about whether a drop is 'insert as sibling before', 'insert as sibling after', and 'add as child', though I believe the child case is solvable with temporary dummy controls (you only need to add siblings). --JosiahCarlson
10. Allow importing part of or all of another XRC file into the one being edited. --DonDwiggins
11. Provide for "templates" or a kind of macro facility that makes it easy to do common things like label-control pairs. --DonDwiggins
For example, this could be implmented by having a Insert Template toolbar item that allows the user to select from a list of named items. When one is selected it simply inserts tree nodes from the template to the current location in the tree. The templates themselves can simply be snippets of XRC XML located in a certain directory (or perhaps a standard location and also a location in the user's documents directory.) We should also allow the user to select part of or all of their current XRC tree and save it as a template. --RobinDunn
12. Allow specifying the size of a window (control or container) in terms other than absolute pixels. For instance, "I want a text control just large enough to hold the string '12345-6789' in the standard font". For another: make this window 110% of the size of that other one (horizontally, vertically, or both). --DonDwiggins
This will require modifications to the C++ XRC code, and will probably be a hard sell unless we can come up with a specific and simple set of alternate sizing methods. The percentage method may also need support from the sizers. --RobinDunn
13. Allow specifying one or both of a minimum and maximum size. --DonDwiggins
- This one will also need changes to the C++ XRC code, but will be an easy modification.