|
From: | Dr. H. Nikolaus Schaller |
Subject: | Re: New ProjectCenter Icons |
Date: | Thu, 13 Sep 2007 15:18:27 +0200 |
Am 13.09.2007 um 14:59 schrieb Richard Frith-Macdonald:
On 12 Sep 2007, at 17:45, Dr. H. Nikolaus Schaller wrote:Am 12.09.2007 um 18:16 schrieb Wolfgang Lux:Dr. H. Nikolaus Schaller wrote:That works only if your class has just IBOutlets (IB is not showing and handling any other ivars!). And any changes made manually to the .h file are overwritten.On my system (OS X 10.4) IB asks whether I want to replace the existing files or merge the changes, and if I choose the latter it happily invokes FileMerge for both the header and the source file. Obviously, this means that we need an equivalent of FileMerge in order to get this to work under GNUstep :-(Yes, it also works this way.If you are asked three times per hour by the development environment to replace or merge and then a third (!) application opens where you have to click around, you will probably start looking for simpler solutions...What I still do not understand is why almost all arguments against my proposal finally end up like (well I am making it quite black&white):"It is already good how it is solved (because it comes from NextStep). Well, Xcode/IP have now something that is missing in GNUstep/PC/GORM. So we just have to add the missing things, i.e. some DO between PC and GORM and FileMerge to interact between both and everything is fine."I guess that's because most people think that separate apps integrated via DO and distributed notifications will provide a better user experience than a monolithic application that does everything. My favorite example of the app that does everything is microsoft word ... which I find utterly unusable. You either live with a huge amount of clutter in toolbars and
200% agreed! Apple has shown with Pages how the same amount of functions (and document file compatibility) can be provided with a better UI design.
menus, or you customise it to the point where it's completely non- standard, and you can't effectively use anyone elses customised version.I am sure, there are better (from a user's point of view) solutions than copying Xcode/IB...I guess so (I'm not too keen on Xcode) ... but I don't think a monolithic app is one of them. I would prefer to go the other way ... more small apps tailored to their specific jobs, and integrating with each other. Technically, I think that well defined interfaces between apps using DO/notifications are no harder to program than well defined interfaces between
Hm, if you replace "apps" with "views" and integration "through DO" with "classes (potentially from loadable bundles)" - where is the difference for the user?
modules in the same app ... and you need such modularisation for maintainability in any large project whether its multiple apps or multiple modules in one app.
Generally, I think we are mixing features / user interface design with application architecture and are argueing that a DO based multi- application architecture can improve the user experience.
I would keep it simple anyway. My vision is (like I have tried to draw with ASCII characters in a previous mail):
* a single NSBrowser to select items (source file, NIB item, Makefile)* a single View (NSTabView with invisible tabs) area where you either see source code (NSTextView) or Menus or a NSWindow with NSView hierarchy or a property list (NSOutlineView) * an inspector for attributes of the currently selected item (which can be a source file or a NIB item)
If I had more spare time I would draft such an application...
[Prev in Thread] | Current Thread | [Next in Thread] |