From: Kevin A. <al...@se...> - 2004-08-23 17:45:09
|
I should have started this discussion on the list in the first place, but Alex is the only other person that has been working on resourceEditor changes, so I initially emailed him offlist. Feel free to chime in with ideas and comments. I've already checked in the function wrappers for all the custom dialogs as well as changes to the Property Editor so that the user doesn't have to click the Update button to change an attribute. The auto-updating will be optional in the future, settable via a menu item in the Options menu. If you are using PythonCard from cvs, you can keep up as changes are made. Unless a critical framework or tool bug pops up in 0.8 that requires a quick fix release, I expect the next version will be 0.8.1 out sometime in late September or early October. The more feedback people give on 0.8, the easier it will be to focus on which items to do for 0.8.1. Also see the to do lists on the wiki. ka Begin forwarded message: > From: "Alex Tweedly" <al...@tw...> > Date: August 22, 2004 7:46:57 AM PDT > To: "Kevin Altis" <al...@se...>, "Alex Tweedly" > <al...@tw...> > Subject: Re: planned resourceEditor changes > > At 19:37 21/08/2004 -0700, Kevin Altis wrote: > >> Now that 0.8 is out I want to move forward with a number of >> resourceEditor changes. Since you've been working on the code I >> thought you might be interested in some of these. Obviously, if you >> would like to see some other changes, then it is good to know that >> I'm planning on mucking around and changing things. >> >> First of all, I keep debating back and forth on whether to support >> closeField and select (choice) and mouseClick (checkbox) for updating >> components instead of requiring the user to press the Update button. >> It is easy to support, so this might be a good choice for turning on >> with a preference and in the event handler just calling the update >> command to avoid much code change. > > What's the argument against doing this ? Would anyone prefer to need > to press Update ? > >> 1. make sure all the custom dialogs are done with function wrappers >> for cleanliness sake >> 2 . switch to util.runScript >> 3. Refactor all the code ... self.layoutWindow. >> 4. Move all the code for moving and dragging the components to a new >> layout class and module. It is probably possible to refactor a large >> number of the component manipulation commands so they all move to the >> new layout class. > > They sound good - the component manipulation stuff is a bit hard to > follow right now. > >> 4a. Make sure the layoutWindow displays the real menubar, that >> dialogs don't have extra vertical space like they do today because of >> the forced menubar, show statusbar, etc. if needed. > > Sounds good - though to be hones, not something I've had a problem > with. > >> 5. Assuming all of the above goes well, then it is time to start >> adding some new functionality. The next items are just ideas. >> >> 6. Add group selection functionality to all more than one item to be >> selected, then do alignment operations such as align left, align top, >> etc. as well as group moves. Setting attributes via the property >> editor would likely need to be disabled. > > Do you see groups as anything other than a mechanism of the > resourceEditor ? (i.e. like Revolution groups ? or simply a way to > make move/alignment/distribution more convenient) > >> 8. Support multiple layout windows. This would be another refactor of >> item 3. I'm actually a bit hesitant about this change due to the >> confusion it might cause. > > Not sure I see a need for this. > >> 9. Add a palette for the components rather than having a menu of >> components. The palette doesn't have to be just bitmaps, it could be >> a wx.ListCtrl with the first column being an icon (if available) and >> the second column is the component name. Since the layoutWindow will >> be separate from the main window and menubar it might be best to roll >> the propertyEditor and palette into one main window? I haven't >> thought a lot about this. > > Palette of components sounds good - especially if you know someone who > can devise / draw suitable icons. Whether through a palette, or simply > from menu, I'd like to see automatic graphic positioning of newly > added components (not for copy/paste or edit/duplicate, just newly > created one). So when you select say Add/Button, it switches to a > different cursor type and allows you to press/drag/release to position > and size the button in one operation. Given a palette, this can be > "sticky" after a doubleclick. > >> That's enough for now. Other ideas or things you think are pressing >> issues? > > Two pressing issues - but maybe too big for now ..... > > 1. Sizer / geometry management. > > Haven't got a good handle on how this might be done - still playing > with sizers to see what's possible in wx. But this is the biggest > missing feature, in IMHO, in the whole of PythonCard. > > (Well, maybe an integrated debugger is a bigger feature - but this is > certainly the biggest one with any connection to the resourceEditor). > > 2. Undo. > > This can be a can of worms, but it would be really nice. Not sure if > it's possible (or necessary) to make absolutely everything undo-able, > but at least simple component moves, adds, deletes?, and text edits. > > -- Alex. |