On Fri, 21 Oct 2005 12:04:59 +1000 David Seikel <[EMAIL PROTECTED]> babbled:
> On Thu, 20 Oct 2005 21:43:19 -0400 dan sinclair <[EMAIL PROTECTED]> > wrote: > > > > A window manager does not know if closing this window closes the > > > application, or if closing this window can be easily reversed by the > > > application just opening it again. For these reasons, I think that > > > the Close item on the E17 window menu should be at the bottom of > > > the menu, and not at the top. The same argument applies to the > > > Kill button, but since it WILL kill the application, and possibly > > > in an unfriendly manner, it is more dangerous, and should be > > > slightly harder to do. Put Kill at the very bottom, maybe add a > > > "Are you sure?" dialog. > > > > > > > Why is it that all things done in the name of usability make an app > > harder to use? The only time I ever touch the window menu is to make > > an app sticky (almost never done) or to close/kill an app. Making > > killing an app harder by sticking it behind a dialog is just making > > the users life harder. Your adding in steps that don't need to be > > there. > > The point is to make it a little bit harder to kill an application by > accident. Adding an extra two mouse moves and an extra click is a > small price to pay if it saves you hours of work because you > accidentally selected Kill from the menu. Notice that I didn't > advocate making the window close button any harder to use. I also > didn't advocate adding a dialog to the Close item, only to the Kill > item. Kill is a desperate, unfriendly, only if you have to method to use > when the application misbehaves, it is appropriate that there are > safeguards. > > Note that all other items in the window menu are easily reversed. The > same cannot be said of Close and Kill. I think we should make them a > tiny bit safer. > > Alternatively we could always have menus re arrange themselves based > on frequent usage. That would make everybody happy. B-) the kill item is there as a manual kill. e17 actually will AUTO-KILL appllications that: * proivide a PID property so we know their PID * talk the netwm ping protocol * ask for the delete protocol of icccm * have actually not responded to a ping request for more than 10 seconds * you have innocently pressed the close button and the app hasnt closed * it has been more than 10 seconds since you pressed the close button e17 will literally kill off the pid with a kill - and if that doesnt work 10 seconds later a kill -9 :) this is of course configurable, but e tries to make sure things get done that you asked to be done - it gives the app a chance, but form e's point of view the app is totally hung solid. thgis just saves time that a lot of unxi users do - going "whhy the fuck doesn that app die?" - drag a window over it and notice it doesnt redraw, pop up a term, look at top, notice its using 99% cpu and otherwise nto responding - now find its pid kill the pid, find it still doesnt die (it has set up a sigint/sigterm handler etc.) and now kill -9 the same pid finally to rid yourself of the menace :) basicalyl= e just does this all for you quietly - if it has enough info to make an intelligent descision :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
