On Wednesday 24 May 2006 00:35, Richard L. Hamilton wrote: > [...] > > > Very nice; now, nautilus and iPod integration, so > > that the iTunesDB is treated > > like a directory, the information inside are > > displayed as files, thus, > > allowing any files to be 'dragged and dropped' into > > the mock-file to be > > copied to said device and iTunesDB updated at the > > same time (same process > > when deleteing). > > That's an interesting sounding idea. Unfortunately, I suspect the > practical obstacles would be considerable. Whether anyone in GNOME > even on the Linux side would actually want to participate in the work is > another story, and for something like iPod support, I would think absent > _paying_ customers that wanted a really high level of integration, it would > (has) happen(ed) faster by porting something that already exists (gtkpod). > I don't personally know enough about how nautilus* works to know whether > such a thing could be done as some sort of plug-in, or whether it would > have to be a patch to the outside nautilus distro; if the latter, I suspect > there'd be some resistance to diverging from it absent some serious market > demand; given that there _is_ some demand to update the desktop software > fairly frequently, that's a lot easier done if it's a straight port, with > platform-specific patches kept to a bare minimum, and all patches and > enhancements accepted by the outside developers. > > * But I don't have to, since I don't work for Sun and in any event GUI code > is usually the _last_ thing I'd write, 'cause past the basics, it's the > last thing I'd use. Not that if it's there, it shouldn't satisfy most > reasonable expectations. But that's something I'm usually content to leave > to others. > > As for administrative GUIs, as much as I despise the generally useless > differences of AIX, I have to admit that in some ways "smit" doesn't suck. > It provides menu access to 95%+ of what one could do with commands, can log > the actions it takes, and can even show the command-line equivalents, so > that when a _real_ administrator wants to script some repetitive task, the > worst they have to do is do something they haven't done before once with > smit, capture the equivalent commands it can show, and use them with some > shell variables within the loop of their script. And ISTR it has both > graphical and text (curses?) based forms, so it could work on a serial > terminal, too. All in all, something that could serve both junior admins > and more senior ones that were spread thin, and with the logging, could > help with accountability, too, when the junior ones still went and screwed > things up even though they had a GUI. > > I think there are a _lot_ of lessons that could be learned from "smit".
Well, I'm a bit of a 'KDE old timer' having used it since 1.0 with a rickety old version of Red Hat many years ago - the one difference I think with GNOME and KDE is this; there appears to actually be an effort by KDE to integrate the UI and OS together, so that one *chooses* to use the CLI rather than compelled/forced to because of crappy administration tools. One should be given the option of using one or another; one should feel that they *must have to* use the CLI on Solaris, when the most common of tasks - setting up network, administrating the various components of Solaris Enterprise Server, xorg, printers, hardware and driver installation, package maintainence etc. etc. should be all available via a 'teh snappy' interface (SMC doesn't count, its a dog) which has a modular back end as to allow third parties to hook into the front end and provide configuration modules for their particular products. Turn the facility into something where by the whole system can be configured and maintained from that one central location - Apple has it right, more or less, with their System Preferences. Matty _______________________________________________ opensolaris-discuss mailing list [email protected]
