Max Horn wrote: > I firmly believe that one thing that makes Fink strong is its focus > on various key properties. Dilluting them is not going to help us. > One of these properties is that we stick as much as sanely possible > in /sw, and we package *unix* applications (except for a few > auxillary Cocoa/Carbon apps, like AquaTerm and XDarwin).
True. But it's also Fink's weakness. While Fink's documentation is great, Fink is still focused on porting apps to the exclusion of everything else--including usability. Don't get me wrong. I think Fink is wonderful, I use it myself all the time and frankly it's perfect for me. But out of all the mail I've gotten from users of my packages, between a third and a half are "how do I use this?" questions. Pretend for a minute that you've never touched a CLI before, and look at the current instructions for installing Galeon [comments in braces]: 1) Download Fink binary installer, double-click, follow instructions [so far so good]. 2) "pico ~/.cshrc", add "source /sw/bin/init.csh" [ugh]. 3) Command-tilde in the Finder, type in "/sw/fink/dists/unstable/main/finkinfo". Find .info/.patch files beginning with "galeon" [double ugh]. 4) "sudo cp " <drag files to terminal window> " /sw/fink/dists/local/main/finkinfo/" [this is the part users always seem to forget the next time they need to install a package from unstable]. 5) Do the same for all the dependencies [*real* ugh]. 6) "fink install galeon" [ahhh, finally the end]. The Linux users I tell about Fink pick this up real quick and love it; the bleeding-six-colours Mac users doze off around step 3. I'm *not* saying that the answer for this is packaging FC. Just that Fink's focus might be a bit too narrow, at least from my point of view--it's a free world though, you can disagree! A couple other points where this "narrow focus" comes up: a) We keep saying that Fink stable = Debian stable, Fink unstable = Debian testing, Fink unstable CVS = Debian unstable. Most "casual" Debian users use testing; just like Fink unstable, Debian testing is also "most likely to work as desktop user expects", even if it's not "least likely to break". But between the lack of a binary distro for unstable and the need to edit conf-files to access unstable, we make it hard for casual Fink users to access "Fink testing". b) "fink feedback"--arguably the most important tool in changing Fink so users can use it--seems very much on the backburner. No, I'm not blaming anyone, I know everyone works hard and Fink has improved a lot--and yes, I also know I could always add it myself, that's why I'm learning perl :-). Again, I'm not saying these are wrong decisions--for my personal usage of Fink, they're (nearly) perfect. But one of my goals in contributing to Fink is making UNIX software truly accessibly to Mac users who would never otherwise consider using it, and so I think these features are important. > Now I'd like to hear what others say. Why is it so important that we > have a FinkCommand package? Why is a GUI so important? Do people that > use stuff like Fink really have to have a GUI, for things that they > have from the command line in the end? Ok, well I already said why I think a GUI is necessary. Basically, it gives the user a clue. Sure, we could add a --check-unstable flag so that unstable packages would be installed if a stable package is unavailable. Or a --dont-annoy-busy-maintainer-with-feedback-warning-designed-for-users flag <g>. But the idea of a GUI is that it lets the user just dive into Fink, without forcing us to dumb down the command line interface. Ideally, we could create small "installer" applications, so that CLI-hating users can just download "Galeon" from Versiontracker double-click, and everything (installing Fink, installing FC, installing Galeon and deps) happens automagically. By the way, why assume that Fink apps are used "from the command line in the end"? For example, I patched OroborOSX so it scans which Fink packages I have installed, and creates a "Fink" menu listing the appropriate GUI apps--select one and it launches. (Sorry, the patch isn't fit for release yet and is out of date. If anybody wants a look anyway, tell me and I'll put it online.) I think it's likely that either FC will eventually include such a feature, or that there will be some other way of accomplishing the same thing. How many RedHat users really launch Mozilla from the CLI every time, hm? > I know there are maybe a few > cases, but is the majority of Fink users really going to need it? Why > is it so much better to have this a Fink package instead of a > seperate download? Ah, that's the clincher. I *do* think a Fink GUI is needed, and that integration between Fink and the GUI is needed, but I *don't* think it should be a Fink package. Users will want to move FC wherever they want, but that will break Fink. However, there are other things that can be done to make a GUI more accessible. Many of these are the responsibility of FC. Binaries of FC should definitely be released, and it should be announced on -users and -beginners, for sure. As for some of the issues that Martin brought up: - It's true that having to install Fink and then install FC can be tedious. Perhaps it would be better if instead of solving this on Fink's end (with a FC package), we solve it on FC's end. It's not complicated to automatically install Fink, I believe I sent Stephen a short script I wrote a while ago which does just that. - Having FC respond to Fink's updates isn't hard. Users would be expected to perform Fink updates through FC anyhow, in which case FC could interrupt and update itself if needed. Otherwise, FC can just check for updates upon launch; WikiWiki-cocoadev has some code to check for online status here: <http://www.cocoadev.com/index.pl?CheckingOnlineStatus>. However, there are things I'd like the Fink project to do to encourage GUI development. We can, and ought to, put a link to FC on the installing Fink page, or even on the home page once FC is more stable. This goes for any other GUIs that pop up, as well. Also, we should discuss some of the things that are needed from Fink for GUI development, like a debconf-ish system for alerts, and a way for Fink to call-back to an alternate front-end. These are some of those things which are harder to do the longer we wait, so I think they're at least worth discussing. Anyhow, I think this rant is long enough now. I realize that my goals in participating in Fink are not those of everyone else (and don't think that 'cause you know one of them, you know them all ;-). I look forward to hearing what other people have to say. Dave _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
