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 >> <[email protected]> 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. _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
