Re: Gorm thoughts for the future...

[Fred Kiefer]

On 03.04.2014 23:37, Ivan Vučica wrote:
> 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.

Not sure either, I have seen to many badly designed single window user
interfaces. But you could prove me wrong here.

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

Yes, this idea keeps coming up and I really like it. It would make a lot
of unclear user interface a lot easier to understand and manipulate.

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

Actually, I like the name GORM (Graphical Object Relationship Modeller).
There is not much we could loose by changing that name, but I see
nothing to be gained here either. Its like renaming GNUstep to something
else, we just loose a lot of time and effort in explaining that change.


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

I like the idea of adding a library interface, but the old way could
still be around. I really get confused when looking for a certain user
interface element in the new IB.

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