Date: Wed, 19 Oct 2005 23:40:18 +0200 From: Roman Neuhauser <neuhauser@sigpipe.cz> To: Mark Linimon <linimon@lonesome.com> Cc: freebsd-ports@freebsd.org Subject: Re: [SUGGEST] Reform eclipse and eclipse related ports Message-ID: <20051019214018.GA5180@isis.sigpipe.cz> In-Reply-To: <20051018162907.GB14192@soaustin.net> 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> <FC88505D-7FB0-4AF3-821B-BBB88B0E82C7@softweyr.com> <20051018153752.GB11790@soaustin.net> <20051018160725.GB87664@isis.sigpipe.cz> <20051018162907.GB14192@soaustin.net>
next in thread | previous in thread | raw e-mail | index | archive | help
# 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051019214018.GA5180>