One more... Layed inspectors JUSTIFICATION: Currently an inspector in Gorm functions like those in IB2.0... XCode/IB3.0 inspectors are "layered" that is to say they are built up based on the inspectors for classes which are subclasses of a given class of which an instance is being edited... i.e. when editing a button, you get an inspector for NSButton, NSControl, and NSView since these are the subclasses of NSButton. You get them layered on top of one another. so that you have all options available to you. This is something which is needed in Gorm since I have to typically stuff all of the things needed for editing anything into ONE inspector and then reinvent them for any instance of a superclass. Workable, but wasteful and doesn't promote reuse.
GC On Thu, Apr 3, 2014 at 5:04 PM, Gregory Casamento <[email protected]>wrote: > I am thinking about a few things when it comes to Gorm. Some of which > people might not agree with, some of which people will love, I'm sure. > > Here's what I've been thinking for a long time... in no particular order: > > * Personally, though the name Gorm seems to be fitting, it's also not > really in line with PC. > JUSTIFICATION: I've always thought that on OPENSTEP we had PB and IB. > Why not for GNUstep have PC and IC. InterfaceCenter... InterfaceCreator... > something like that... this is a passing thought to change the name, and is > certainly not something that we NEED to do. It's just a thought. > > * Get rid of palettes and move to a library style of storing widgets... > JUSTIFICATION: Part of the issue here is that the palettes are of > limited size. A library like on Xcode can handle an unbounded number of > widgets and also allow a user to search for the one the want. The palette > approach causes the need to unnaturally place the widgets into categories > and has limited space available to show the widgets.. so they end up > crammed in. Additionally, the library approach can provide descriptions > for the widgets in the cells that are used to display the widget in > question. > > * One window design... NOW NOW... don't panic, this is something I've been > thinking about for a while and here's why > JUSTIFICATION: Right now there are a few bugs in Gorm related to the > fact that we do not use this approach. One is standalone views. At > present Gorm needs to wrap a standalone view in a special window subclass > so that it knows NOT to persist the window the view is placed in and JUST > save the view as part of the document. While this sounds like dynamite on > paper, it's a real pain in the ass to deal with in the code. Just look at > GormCore/GormViewWindow.[hm] to see WHY it's such a pain. With a one > window design (ala Xcode) much of this heartache simply goes away. It also > gives a consistent place for the top level objects to be shown instead of > them potentially being behind another window while you're trying to work on > your interface. > > I have been having some other thoughts about Gorm recently, but these are > really the main ones which have been on mind. Any thoughts and feedback > are appreciated. > > Gregory Casamento > GNUstep Maintainer/Lead Developer > greg_casamento (Skype) > (240)274-9630 > > > > -- Gregory Casamento Open Logic Corporation, Principal Consultant yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) http://www.gnustep.org http://heronsperch.blogspot.com
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
