[wxPython-dev] 20071113 test build uploaded

[Chris Mellon]

On Nov 20, 2007 1:43 AM, Cody Precord <codyprecord at gmail.com> wrote:
> 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
>

I have my own gripes and ideas about some issues (mostly stylistic, a
few functional). Do you have a bug and/or patch tracker for public
commentary and patches?