From: Alex T. <al...@tw...> - 2004-09-26 22:09:44
|
At 13:37 26/09/2004 -0700, Kevin Altis wrote: >The issue of providing alternate styles for the underlying controls with >PythonCard has been a long-standing one, so let me give a little >background before suggesting some possible solutions. I would like to get >feedback on the styleOverride idea below. > >There has been a general goal of focusing on the most commonly used style >for a component as the default and if there are multiple common variations >then there are typically extra attributes that let you choose those styles >as alternatives. Most of the underlying wxPython controls, only let you >set the style when the control is initialized, so the style information >must be available during the __init__ method of the component. For a long >time PythonCard also avoided wrapping components or supporting styles that >weren't available on all platforms, to simplify writing cross-platform >code. That is no longer true, and so you have controls like the >IEHtmlWindow which only works on Windows. On the other hand, the TextArea >control will continue to use the wx.TE_RICH2 style so that it behaves >almost identically on Mac, Linux, and Windows. > >Personally, I don't want to have a corresponding style attribute for every >possible style available in the underlying wxPython control since more >choices just makes it more difficult to use, so the trick is figuring out >which are the common cases and supporting those. In the case of the >horizontal scrollbar, which is optional on Windows, but not on GTK, I can >see having a specific attribute to control the setting, but it still won't >allow the scrollbar to be toggled once the control is created because >wxWidgets doesn't support that. Yes, I like the fact that I don't get presented with a large number of choices when 99% of the time I want none or very few of them. >A general solution to this problem would be to have something like a >styleOverride attribute for components that would be for expert users that >need complete control over the style flags. One implementation that might >work would be to make it a list of strings such as ['wx.TE_RICH2', >'wx.TE_MULTILINE', 'wx.HSCROLL']. By default styleOverride would be None, >but if it exists, each style string would be converted into a style flag >using eval() and logically ORed (|) with the other styles and used instead >of the normal style processing. That power would also mean you could >easily create a program that wouldn't run correctly, especially if you >made a typo, but also because you didn't include all the required style >options, so it definitely would be an expert option and I'm not sure what >changes might be necessary to protect normal users from styleOverride in >the resourceEditor. Anyone have opinions on this idea? Sounds really scary. You said ".... and used instead of the normal style processing." I'd rather see something that would be used in addition to the normal style, rather than replacing it. As a replacement, I'd never be able to use it without going to check in the Pythoncard source code which styles were used for the default, and duplicating them. I'd rather see it be a list of words that would be XOR'ed into the standard style (or simply OR'ed in, and allow a "no" format like "no wx.TE_MULTILINE" to remove any of the defaults). Even better might be to make it like Color or Font and have a pop-up dialog for styleOverride that presented either a set of checkboxes, or a multichoice list (with a button to "Reset Defaults"). The words set in the default could be already checked, making it easy to vary as needed. -- Alex. |