From owner-cvs-src@FreeBSD.ORG Mon Apr 18 19:33:41 2005 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C503E16A4CE; Mon, 18 Apr 2005 19:33:41 +0000 (GMT) Received: from pinus.cc.fer.hr (pinus.cc.fer.hr [161.53.73.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id D653743D41; Mon, 18 Apr 2005 19:33:40 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from [161.53.72.113] (lara.cc.fer.hr [161.53.72.113]) by pinus.cc.fer.hr (8.12.2/8.12.2) with ESMTP id j3IJYPhE000855; Mon, 18 Apr 2005 21:34:26 +0200 (MEST) Message-ID: <42640B87.2070001@fer.hr> Date: Mon, 18 Apr 2005 21:33:27 +0200 From: Ivan Voras User-Agent: Mozilla Thunderbird 1.0 (X11/20041213) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Giorgos Keramidas References: <200504161543.j3GFhclO075103@repoman.freebsd.org> <86acnyd2k7.fsf@xps.des.no> <20050418063321.GA85819@dragon.NUXI.org> <42636A16.2070702@elischer.org> <20050418095850.GB12892__4420.21584972299$1113818160$gmane$org@orion.daedalusnetworks.priv> <4263EDFF.8020005@fer.hr> <20050418174512.GA1847@orion.daedalusnetworks.priv> In-Reply-To: <20050418174512.GA1847@orion.daedalusnetworks.priv> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: cvs-src@freebsd.org Subject: Re: cvs commit: src/usr.bin/top machine.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 19:33:41 -0000 Giorgos Keramidas wrote: > [ snip suggestions for 3-column NICE, removal of PRI, procname/#threads > and removal of either CPU/WCPU ] I didn't sugest removing them, only shortening them - does anyone really need two decimal places on them? AFAIK, the information gathered by top is not really that precise (or if it is, the precision is not usable because of averaging over time/delays/etc). Maybe removing the decimal parts completely isn't a good idea, but trimming them to single decimal place probably is. > Even the procname/#threads suggestion is not as good as it sounds at > first, because too short terminals will end up clipping the thread count > anyway. Probably isn't feasable to do it here, but I like the way some Windows program deal with this problem: remove the middle part of the string. For example: "This is a really long filename.doc" becomes "This is ... filename.doc" Maybe it could be applied on this information: (IRL situation:) "xfce4-mcs-manager/30" -> "xfce4*ger/30" or, less fancy & probably more useful, trim the process name, leave thread count: "xfce4-mcs-m*/30" Just a thought... (I really like that form :) ) (trimming usernames would be BAD because most "business" installations today are hooked to LDAP or somesuch and have usernames of form "somename.domain", e.g. *long*) > The ideal solution of making every bit of every column configurable at > run-time *and* allowing the user to select: > > - What fields are displayed. > - In what order > - The width of every column > - The sort fields and their order Well, it is ideal, but then there's the effort/benefit thing: if you make it all configurable, nobody will configure it :) > ... *and* still making it possible to run top with a very narrow > terminal without nasty wrap-around effects, is probably going to require > a major rewrite of many parts of top. I'm still in the process of > judging if the result would be worth the effort :-/ Yes. Ok, another idea: instead of making everything configurable, make just one alternative mode: "rich client" - for those of us that mainly use X-terms & have insanely big terminal windows. That mode could have fancy & weird output, like using TWO lines for every process in the list - one with general information, pretty much like the default list now, and the second with detailed information about threads. Redability would be a concern, but IMO not a big one.