[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Gorm thoughts for the future...
From: |
Gregory Casamento |
Subject: |
Gorm thoughts for the future... |
Date: |
Thu, 3 Apr 2014 17:04:47 -0400 |
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
- Gorm thoughts for the future...,
Gregory Casamento <=
- Re: Gorm thoughts for the future..., Gregory Casamento, 2014/04/03
- Re: Gorm thoughts for the future..., Ivan Vučica, 2014/04/03
- Re: Gorm thoughts for the future..., Lundberg, Johannes, 2014/04/03
- Re: Gorm thoughts for the future..., Gregory Casamento, 2014/04/03
- Re: Gorm thoughts for the future..., Lundberg, Johannes, 2014/04/06
- Re: Gorm thoughts for the future..., Riccardo Mottola, 2014/04/09
- Re: Gorm thoughts for the future..., Lundberg, Johannes, 2014/04/09
- Re: Gorm thoughts for the future..., Gregory Casamento, 2014/04/09
- Re: Gorm thoughts for the future..., Thom Cherryhomes, 2014/04/09