First two sound good. Single window, I'm not so sure. Possibly not single window, but sidebar-in-each-window? Xcode has a vast disregard for the potential size of my total workspace.
Having a NSDocument with single NSWindowController that can be "duplicated" and then independently manipulated (while still touching original objects) would be ideal. Given that we're speculating about radical changes to Gorm, I have one more: If you decide to build the UI around an NSViewController that just happens to represent a view tree directly embedded in a NSWindow, that would later allow building an embedded IDE such as Xcode4/5... taking the opportunity to fix what is essentially a discouragement of a multiwindow environment, of course... > On 03.04.2014., at 22:04, 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 > > > > > _______________________________________________ > Discuss-gnustep mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnustep _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
