[...]
> 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".
 
 
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
[email protected]

Reply via email to