[wxPython-dev] 20071113 test build uploaded

[Cody Precord]

Hello,

On Nov 19, 2007, at 8:20 PM, Kevin Ollivier wrote:

>> Coincidentally the idea of the output console was something I was  
>> just discussing with the main author of that plugin yesterday  
>> (http://code.google.com/p/editra-plugins/issues/detail?id=29) so  
>> it sounds like it will be part of the next revision. Currently  
>> though you can put Editra in DEBUG Mode by either setting it in  
>> the preferences or passing a '-d' at the command line which will  
>> send the output of the commands to the console (Console.app on  
>> OSX). Please feel free to post your other ideas to the issue  
>> tracker at the aforementioned link and assign them to Kevin D.  
>> Smith or myself.
>
> Okay, thanks; is the difference between the 'modes' (CODE, DEBUG,  
> and DEBUG_GUI) documented anywhere? I guess 'CODE' is like  
> 'Normal'? ;-)
>
No, I don't think so but I will add it sometime soon as I need to  
update the documentation in a number of places already. Its pretty  
simple though, CODE=Normal, DEBUG=print debug messages to console,  
DEBUG_GUI= redirect debug messages to output window.

>>
>>> - IMHO editra should internally save and restore the state/ 
>>> perspective at time of application close. Having to reopen the  
>>> Projects tab, or save and reload the perspective, each time  
>>> manually gets to be tedius.
>>>
>> It does currently have the ability to do this but the behavior  
>> needs some adjustments. To save your perspective between sessions  
>> first create one by setting the window up how you like it an going  
>> to  "View=>Perspectives=>Save Perspective", then (here is was  
>> needs to change) go to the preferences dialog and set the new  
>> perspective as your default one, it will now be reloaded each time  
>> you start the program. This step can be avoided however if you  
>> just save the current perspective with the 'Default' name as it is  
>> what is set as the preferred perspective under an initial  
>> installation.
>
> Ah, I see. I have to admit I've never really gotten the AUI  
> perspectives approach down. The idea of saving multiple named  
> configs for persistence is somewhat foreign to me. ;-)
>
>>
>> Changing this to add an 'auto-perspective' that just auto saves on  
>> exit is something I have been meaning to do for quite awhile now  
>> but have forgotten to do, I will try to get it in in the next day  
>> or so if I can.
>
> Thanks, I think this is what would work for most people.
>

Done and set as the default

>>
>>> - Consistency issues: I think it would be nice for Editra to have  
>>> (if not use) the wxPython Demo's code highlighting style. Also,  
>>> Copy appears before Cut in the toolbar, but not in the right- 
>>> click menu and not in XRCEd. It's a minor thing but since Editra  
>>> and XRCEd use the same base icons I think having them in the same  
>>> order too promotes a consistent look across apps. In fact, it's  
>>> because of that consistency that this discrepancy stuck out so  
>>> visibly for me.
>>>
>> I don' t know how much of an issue this really is as it would only  
>> be in comparison to the stc demo. I wouldn't be against adding an  
>> extra style sheet that has the demos color scheme as an option in  
>> Editra, but don' t think that I want it as the default. If this is  
>> an important point I would rather suggest that it would seem more  
>> sensible to make the demo become consistent with Editra instead of  
>> visa versa.
>
> I could live without the consistency issue, that's more of a  
> nicety; I guess it's more that I've started feeling that the  
> default style sheet tends to emphasize text strings (via the  
> different background color) and at the same time, de-emphasize  
> comments (by reducing their contrast with the background). So as I  
> work with it, I've started feeling it makes comments harder to read  
> (which I often want to read) and calls undue attention to strings  
> (which, typically, don't need changing once written unless there's  
> a typo). I can see why that would be a good thing for certain files  
> or certain cases, but for the default, I think it's good to have  
> something that covers as many use cases as possible, then offer  
> some options for those who want to have a style that optimizes for  
> their particular coding style, etc.
>
I will re-analyze some of the style choices for future releases

> Thanks,
>
> Kevin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wxPython-dev-unsubscribe at lists.wxwidgets.org
> For additional commands, e-mail: wxPython-dev-help at lists.wxwidgets.org
>