Re: Gorm thoughts for the future...

[Ivan Vučica]

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 <greg.casamento@gmail.com> 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
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep