Re: Gorm thoughts for the future...

[Riccardo Mottola]

Hi,

since you tickled me on the phone to reply public, I will! From a 
long-time Gorm user, IB user, who has used also many other interface 
builders...

Let me start that I think Gorm is actually quite usable, especially 
compared with other apps and tools we have. It has a couple of bugs and 
could use a lot of refinements! My comments below though.

Gregory Casamento 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.
InterfaceCenter :) That would be consistent with PC. It's not something 
really necessary though and we still have "gorm" files... I don't 
dislike Gorm, but everyone has its hates.

> * 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.
The current situation is quite crammed and it even misses a couple of 
widgets. Also, it imposes that new objects added need their own palette.

However, let's not discard a palette approach: it stimulates visual 
memory, it is very compact and easy to recognize. "Searching" in a 
library for something known is not the same and if it is not well 
known... even worse.
Howwever a library approach can be very efficient with a search 
function. I propose thus a hybrid, as we discussed on the phone yesterday.

* make a library view, searchable where there is a preview view which 
offers a representation of the object when selected
* set an attribute to each object which represents the "palette" do be 
part of and dynamically construct the palettes. This will be done 
perhaps with more a grid-view with a couple of standard sizes and will 
be less packed and optimized than the current ones, but wil lbe far more 
flexible.



> * 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.
Personally I prefer a multi-window approach, it always ends up being 
more flexible. I just like the current interface and displake the new IB 
one. However trying to express the concept of "distaste" better, having 
used single-window applications like Eclipse (!) MS-Office and to a 
certain extent the old Opera with its in-window panel approach, I come 
out with a very disturbing thing:
It*sucks* with multiple monitors, which when I can, use often. Even 
something like having a big and a small montir for palettes, doesn't work.

Also, it is usually impossible of quite awkward to have "two" items open 
(e.g. two documents) and compare then. This applies even with a 
single-monitor approach. If you make each document a window, it will be 
difficult for -inter-items (e.g. two panels). if you make the whole app 
a window, you won't be able to even compare documents...

Riccardo