[wxPython-dev] 20071113 test build uploaded

[Kevin Ollivier]

Hi Cody,

On Nov 15, 2007, at 12:42 AM, Cody Precord wrote:

> Hello,
>
> On Nov 14, 2007, at 3:14 PM, Kevin Ollivier wrote:
>
>>
>> Editra:
>>
>> - I really, really need to find some time to figure out how to get  
>> the function list from wxSTC so that we can have a "Go To Function"  
>> dropdown. ;-) This is the feature I really miss from TextWrangler.
>>
> This would be very welcomed :)
>
>> - The Projects tab is really nice. I think it should be installed  
>> by default, like the FileBrowser plugin. There are some issues with  
>> it ("compare to previous version" seems not to do anything with  
>> svn, and it would be nice to have a console window to send messages  
>> regarding status of svn update, etc.), but overall it works nicely,  
>> updating me when I have modified sources, etc. Of course, I'd  
>> really like a New Project/Open Project/Save Project option too.  
>> Most of the sources I work on are part of some project, and I think  
>> that's fairly common, so I think it should be a first-class part of  
>> the interface.
>>
> The compare to previous version works well on my machine is the  
> config set to use 'opendiff' or 'builtin' on yours (see the plugins  
> configure dialog)? The builtin uses the webbrowser to display an  
> html diff but it also uses the 'open_new_tab' call as reported in  
> your error report so it will unfortunately only work on py2.5 until  
> the next revision, opendiff uses FileMerge from the Apple developer  
> tools I see you are on 10.5 is FileMerge still installed as part of  
> the developer tools on there? It is also possible to set the path to  
> any other preferred file diff program to use for displaying the  
> comparison.

I'm using the builtin on Py 2.4, which would explain my problem. ;-)  
FileMerge does still come with the devtools on 10.5. I'll wait for a  
fix as I don't like unsetting the defaults unless I have to, since I'd  
like to test the 'out of box' experience that the average user gets.

>
> 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'? ;-)

>
>> - 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.

>
>> - 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.

Thanks,

Kevin

>
> The toolbar was an oversite the order should indeed be Cut/Copy/ 
> Paste and this change has been made.
>
>> - Python 2.5 issue with webbrowser.open_new_tab. I already reported  
>> this via the bug reporter (a nice tool :-), but I'm mentioning it  
>> here as a reminder.
>>
> Fixed
>
>> I'll try to devote some more time to the demo itself a little later  
>> today, but I kinda got caught up playing with all the new  
>> goodies... ;-)
>>
>> Thanks,
>>
>> Kevin
>>
>
> Regards,
>
> Cody Precord
> codyprecord at gmail.com
> admin at editra.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wxPython-dev-unsubscribe at lists.wxwidgets.org
> For additional commands, e-mail: wxPython-dev-help at lists.wxwidgets.org
>