On 8/11/07, David Chisnall <[EMAIL PROTECTED]> wrote: > On 11 Aug 2007, at 08:04, Jesse Ross wrote: > > > Just Minimize, and yes, it should be on the left. I don't know how > > useful Maximize really is -- I never use it on OS X, maybe because > > the implementation is so weird and inconsistent. If no one has > > objections to getting rid of Maximize, I'd say ditch it. > > OS X doesn't have maximise, it has zoom. Zoom says 'make this window > big enough for the contents' while maximise says 'make this window > fill the screen.' The zoom button is really useful, but it relies on > the application implementing it. I'd like to support it if we can, > but if not then it's not a big deal. > > >> 2. keep close button on the right > > > > Yep. > > > >> 3. have title in the middle, > > > > Yep. > > Have you noticed the button order in OS X? It's (from left to right): > > Close > Iconify > Zoom > > This ordering makes sense (in left to right reading order countries), > since it means that the most back (left) option is close, and the > most forward (right) option is 'make bigger.' > > It's a bit odd that they got this right but put the dock in the wrong > place. >
Yes, the mac design makes sense. Some people do argue the close button should be away from others. So now, the proposal is "Minimize/iconify" on the left corner and "Close" on the right cornder and title on the middle. > >> 4. double click on title will shade window > > > > Hmm... I would prefer if there were only one way of temporarily > > putting a window away, and having that be via Minimize. If people > > really want window shading, then I can't really argue it, but we > > should allow it only if we can also put the window into that state > > using a menu command (ie: something like 'Shade' should exist along > > with 'Minimize' and 'Close'). > > If we're doing minimise-in-place then we don't need shading. I personally like shading, and it is indeed just a minimize-in-place. Regarding a menu for minimize, close, shading (like MS Windows), actually I removed it from Azalea. That menu is usually brought up by clicking icon on title bar. So if we remove the icon, then only contextual menu can do so. I personally believe that all the actions for windows should be presented in front, not in one-click-away menu. So all the actions on windows are on the title bar and visible. Well, shading is not explicitly indicated on the title bar. > > >> Traditionally X window always have icon on title bar. > >> On mac, it only have icon on title bar when it is a document > >> window, > >> and that icon is draggable. > >> On X, Azalea may not be able to tell whether it is a document > >> window > >> or regular window. So the icon will probably always stay with > >> title bar. > >> And I am not sure it is easy to make it draggable. > >> It will require some private communication betweem Azalea and > >> GNUstep application. > > > > I suggest we just get rid of titlebar icons completely if we're not > > going to be able to use them as a draggable proxy icons. The only > > function they serve if we keep them in their current state is just to > > be able to tell what app a document is open in, and since we want to > > lessen the importance of applications, they don't seem worth having. > > Proxy icons on OS X represent files, and we don't want files as a > user-visible abstraction, however it would be nice if we could have > them representing objects, so you could drag an proxy icon to a > person to send them some representation of that object. > On mac, all window title looks like this: APP_NAME - whatever_information_you_want_to_say. On X window, it is usually like: icon - whatever_information_you_want_to_say. So the icon represents the kind of applications. Mac use text while X traditionally use icon. But in any case, we need something to show the kind of application on the title bar. We have no control to ask all applications to put their application name on the title bar as text. So the icon is the only way we can gurantee that users can see the application on the title bar because it is done by WM. Yen-Ju > David > > _______________________________________________ > Etoile-dev mailing list > [email protected] > https://mail.gna.org/listinfo/etoile-dev > _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
