From owner-freebsd-ports@FreeBSD.ORG Wed Oct 19 21:40:21 2005 Return-Path: X-Original-To: freebsd-ports@freebsd.org Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFED216A41F for ; Wed, 19 Oct 2005 21:40:21 +0000 (GMT) (envelope-from neuhauser@sigpipe.cz) Received: from isis.sigpipe.cz (fw.sigpipe.cz [62.245.70.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id E10CA43D64 for ; Wed, 19 Oct 2005 21:40:20 +0000 (GMT) (envelope-from neuhauser@sigpipe.cz) Received: by isis.sigpipe.cz (Postfix, from userid 1001) id CAD9E1F87BFD; Wed, 19 Oct 2005 23:40:18 +0200 (CEST) Date: Wed, 19 Oct 2005 23:40:18 +0200 From: Roman Neuhauser To: Mark Linimon Message-ID: <20051019214018.GA5180@isis.sigpipe.cz> Mail-Followup-To: Mark Linimon , freebsd-ports@freebsd.org References: <1B8112AF-8C0E-4BA0-8D1C-DA6AD529F327@softweyr.com> <20051017153024.GA23494@arabica.esil.univ-mrs.fr> <20051017212748.GD71766@isis.sigpipe.cz> <790a9fff0510171505i4010cc05yc30f67d459d1a0e4@mail.gmail.com> <20051018010446.GH71766@isis.sigpipe.cz> <20051018011616.GA57969@xor.obsecurity.org> <20051018153752.GB11790@soaustin.net> <20051018160725.GB87664@isis.sigpipe.cz> <20051018162907.GB14192@soaustin.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051018162907.GB14192@soaustin.net> User-Agent: Mutt/1.5.9i Cc: freebsd-ports@freebsd.org Subject: Re: [SUGGEST] Reform eclipse and eclipse related ports X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2005 21:40:21 -0000 # linimon@lonesome.com / 2005-10-18 11:29:07 -0500: > On Tue, Oct 18, 2005 at 06:07:25PM +0200, Roman Neuhauser wrote: > > > That highlights my point that IMHO we need two different functionalities: > > > 'search' and 'browse'. 'make search' is barely adequate for searching. > > > > What are you missing from make search? I'll try and add it if it's > > within reasonable bounds of complexity. > > e.g. searching when you don't know the exact spelling of the name. Would optional use of double metaphone or another algorithm help? Also, another variable, e. g. KEYWORDS, could be used. > > > We have nothing at all for browsing (unless you count reading an entire > > > list of ports in hierarchy as 'browsing', which even an old command-line > > > kind of guy like me thinks is crude). > > > > Can you define 'browsing'? > > "show me the ports that have something to do with the Internet"; What are you missing from make search cat=net ? (I'm not suggesting you don't have valid complaints, I'd like to learn about them.) > "show me a list of plugins that work with Apache2". Create a virtual category, apache_mod, and then: make search cat=apache_mod Go a step further, use materialized virtual categories, and do ls apache_mod If you think this wouldn't fly, I'd also like to hear the reasoning. > > How will the Wes' colleagues find it? You need to be able to find > > a port to install it. If a port is required to make sense of the > > structure, we need a bootstrap mechanism, like something in the > > base. Like, ls. > > Don't be silly. I don't think I am. I'm pointing out a chicken-and-egg condition present in your proposal. > Neither portupgrade nor cvsup are in base. People pkg_install them > and then they're good to go. Neither tries to facilitate the browsing or searching of the collection, and I consider their being part of the problem they try to solve their weakest spot. > ls is _not_, by any stretch of the imagination, an adequate tool > unless you already have a pretty good idea of what it is you're > looking for. Same applies to Google, or basically any search interface, or, closer to the topic, to FreshPorts, which I used about thrice in my life, BTW. make search is not The Final Solution, of course, but it can be made better. Feel free to mail me any suggestions you have. > I really do not believe that anything with a UI belongs in base, and > I believe that 'search' and 'browse', to be useful to the largest number > of people, need to be UI-based; whether that's as applications, or from > web pages, or more likely, both. Note: The shell is also a User Interface, but I understand you mean a Graphical User Interface, or more precisely (because libdialog(3) is a GUI toolkit), GTK, QT, and the likes. I agree with what you say. I've learned over the last 15 years that the most comfortable UI for the majority of people is a single OK button in the middle of the screen. I'm fine with that unless someone tries to shove it down *my* throat. In compliance with your assessment that FreeBSD is put together by different people scratching their different needs, I'm doing myself a favor by contributing the tools that I want to see in the operating system. (I'm probably one of three people who use [the extended capabilities of] make search, which IMO proves both your and mine points.) Unless, or until, someone tries to discourage improvements to the interface they dislike, everybody can be happy. > > I would certainly prefer if we considered the fs structure to be the > > primary interface (and treated it accordingly). I'm weird, I know. > > It's always going to be the 'primary' interface but if we don't build > tools on top of it, it's simply going to limit the ports tree's usefulness > to people who aren't as hardcore as you or I are. That's in agreement with what the angry guy pushes: don't let the rules of yesterday limit the ways you use it today. I don't mind you spending time writing a web interface (which I won't use), please don't mind me extending the ways make or ls can be used. > But, I mean, honestly, I think I can state without much fear of > contradiction that I have as good a working knowledge of what's in the > ports tree as anyone. Even so, the other day I went looking to see if > there was any port specifically geared to synchronizing file systems on > two peer machines (rather than, e.g., geared to just backing up a file > system). It was really painful to do that, and it shouldn't have been. > None of the existing tools are even vaguely adequate for that. The last two paragraphs seem to back the need to extend the basic concepts. If we stop thinking in terms of "real" vs "virtual" categories, and represent membership in multiple categories in terms of symlinks, we can greatly improve the usability by merely doubling the number of categories. If we can have cnt path 11 /usr/ports/hebrew 13 /usr/ports/accessibility 13 /usr/ports/arabic 13 /usr/ports/ukrainian 14 /usr/ports/hungarian 16 /usr/ports/portuguese 19 /usr/ports/mbone 19 /usr/ports/x11-servers 21 /usr/ports/polish 21 /usr/ports/vietnamese 25 /usr/ports/french then there's surely room for 24 /usr/ports/eclipse And, 1620 /usr/ports/devel could use a close look at. -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991