discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gorm thoughts for the future...


From: Riccardo Mottola
Subject: Re: Gorm thoughts for the future...
Date: Fri, 04 Apr 2014 15:35:07 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 SeaMonkey/2.25

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]