On 8/13/07, David Chisnall <[EMAIL PROTECTED]> wrote: > On 13 Aug 2007, at 05:22, Yen-Ju Chen wrote: > > > On 8/12/07, Jesse Ross <[EMAIL PROTECTED]> wrote: > >> Menubar with: > >> - Menulets (volume control, wireless strength, battery, etc) > >> - Services menu (should be far right and should use the icon shown > >> in this mockup: http://jesseross.com/clients/etoile/ui/interface/ > >> 800x480.png ) > >> - Flower menu (should be far left and should be used for system- > >> wide tasks, such as logging out, shutting down, killing applications, > >> system updates, system preferences, etc) > >> - Tear off menus (using the tear-off bar shown in this mockup: > >> http://jesseross.com/clients/etoile/ui/interface/800x480.png ) > > The tear-off handle looks a lot nicer in those mockups than in the > real thing, as do the colours. I prefer our current UI for the menu > bar in one respect though; we have lines between menu items. On OS > X, it's often difficult to see clearly where one menu ends and the > other starts. > > >> Overview (Exposé like view described by David at the top of this > >> email, should show running apps along the bottom, and should show all > >> open windows--both active and minimized, default trigger is a click > >> in the lower left corner of the screen) > >> > > > > This is the second well-defined components we have so far. > > We should always call it 'Overview' in the future > > instead "Expose-like layer" or "Application switcher layer" > > unless anyone has different idea about the name ? > > In case you haven't noticed, I suck at naming things and probably > shouldn't be allowed to. Overview sounds good to me (which doesn't > necessarily mean it's actually a good idea...) > > > I agree that we show open and minimized window > > in slight different style. > > They will take most of space. > > For minimised windows, I suggest we keep them in their iconified form > (miniwindow + descriptive text), and other windows are just scaled > representations. > > > What I want to be clear is the bottom row for application icons. > > I would like to show only *running* application, not all > > applications. > > It is used to switch running application and bring back hidden > > windows. > > Therefore, users cannot use it to launch application. > > Launching applications has to be done by another components. > > That's why I brought up the tabbed shelf, which is not used anymore. > > Okay. For me, there is little distinction between the currently > running and most used applications. Perhaps we could keep app icons > there while they are not running in these cases: > > - If the app has just been exited (then remove it after a minute or > so), so people can quickly re-launch apps that they quit). > - If there is some spare space in the area for apps, keep the most > recently used apps there. > > We would need some visual clue for distinguishing running apps from > non-running apps, but I think we can do this. Keeping non-running > ones there for a while would also have the advantage that it make it > easier for the apps at the bottom to keep the same ordering, > preserving spacial memory better.
I think this is a good idea to use the extra space for commonly used application. > > > Another thing about Overview is working with Workspace/Projects. > > When we show the Overview, do we show all windows/document > > or only the ones used in current Workspace/Projects ? > > While project is not going to be implmented any time soon, > > we need to keep in mind to support it in the future. > > I would say that we keep it for the current project. If it's global > then it will be too cluttered to be useful > > > Minimize-in-place will take some experiments on implementation. > > Shading would be a poor man's 'Minimize-in-place' for now. > > WindowMaker has a minimise-in-place feature that doesn't rely on > composite. I'd be happy with this or shading as a fall-back. > > > I would like to have app icon along with title text to distinguish > > different type of applications. As in my another post, > > mac do this with text: "APP_NAME - DOCUMENT_NAME ", > > but we cannot force every application to put APP_NAME on title bar. > > Therefore, app icon on title bar serves the same purpose. > > I know this is a really (really) ugly hack, but could you do this: > > 1) Query the class of the window to find the app name. > 2) See if the returned string is in the window title. > 3) Prepend it if not. I would say it is not a good way to do that. I will drop the icon for now and see. > > >> Desktop (no icons on desktop, can be set to a user-defined color or > >> image) > > > > Done in AZBackground, I think, except the image is not scaled. > > NSImage can scale, but after scaling, it is not a bitmap image > > anymore and I cannot draw it on backgroud with X. > > So now, the background image is not scaled, which looks fine. :) > > Composite can easily scale images from pixmaps, but loading images is > a bit more of a problem for it. Maybe if Composite is running, > AZBackground could draw the image to a window the size of the image, > and then Composite could do the scaling, and then unmap the window so > it doesn't confuse things? The Render extension supports bilinear > filtering at worst, and may support better algorithms depending on > the implementation (there is an alias 'best' defined, which may not > be suitable for interactive use, but should be fine for this kind of > thing, as long as I remember to cache the resulting Picture). > Actually, the pixmap you get in Composite is unscaled background provided by AZBackground. (See root_tile() in Composite). So you only need to query the size of that pixmap, scale it accordingly. Then we have the scaled background image. You probably can get the size of pixmap by XGetGeometry(). http://tronche.com/gui/x/xlib/window-information/XGetGeometry.html 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
