The point is that, if you missed it the first time, you don't know to go looking for the information. Let alone where to find it in the mass of dependencies that may have been installed. Experienced users know to scroll back through their Terminal history; new users, not so much. In the year or so that I've been following macports-users, several people have had this problem.

I think using TextEdit is preferable to a temp file since it would be more 'in-your-face'. As well, the user can easily cut/copy, print or save the info if they desire.

If this is implemented, there should probably be a command line switch to turn it off. So cron (or crown!) jobs don't litter the system with a bunch of windows.

Craig

At 12:11 AM -0500 2/25/13, Jeremy Lavergne wrote:
So the notes are available easily enough as we have demonstrated, and we could repeat spewing them again after all installations. I would hesitate removing them after each installation as a user could halt the install process.

As for how many packed will be installed, that should be available since one csn use the verbose flag to see the list of dependencies. in the end this is all meta data about what will be going on. It might be only immediate dependencies however.

Ian Wadham <iandw...@gmail.com> wrote:


On 25/02/2013, at 12:54 PM, Jeremy Lavergne wrote:
 There are issues on all fronts: crown job updates, distributed
installs, etc. No one size fits all :-)

Notes that flash by are one of  my pet (only) gripes in Macports.  May
I suggest:

4) Macports remembers, on a temp file, which ports in the run had
notes,
   then, at the end, puts out a reminder about the "port notes" command
and a list of the ports that might require follow-up action, assuming
you
    have not covered all those notes after earlier Macports runs.

Would that cover all bases?  (Sorry, dunno what a "crown job update"
is.)

I am considering doing something like that in the Macports GUI I am
working on.


 Craig Treleaven <ctrelea...@cogeco.ca> wrote:
 Jim likely missed some important info while installing kdenlive but
 it is easy to see how it happened.  If you look at the rdeps for
 kdenlive, there are _270_ lines!  I don't know how many of those
 dependencies use Notes to inform the user of some important fact or
 other.  I *do* know that they scroll by very quickly in the midst of

 what may be a long, unattended install.  Important information is
 interspersed amongst reams of output that requires no action.

This was my biggest problem on first installing Macports 20 months
ago, when there were fewer binary packages.  The first port I asked
for was kdegames4, but first came qt4-mac and all ITS dependencies
(i.e. large parts of Linux).  Those took all night Š and I had to
sleep.

Again, a warning about how many dependencies need to be built
could be produced right at the start by Macports, with options to
proceed or start again another time.  I certainly plan to do something
like that in the Macports GUI I am looking at.

 Right now, some ports use basic text formatting to try to draw
 attention to these messages (lines of asterisks, etc).  That's good,

 but could we do more?

 Options:
 1) Make users acknowledge messages:  ie, "Press any key to proceed".

 (Shades of CPAN!)  My take:  please God, no!!!

 2) Make such messages stand out more:  use more distinct visual cues

 such as colour or font.  Could definitely help but I don't know what

 is supported by all the versions of Terminal.  (Let alone other apps

 or remote connections.)  What do others think?

 3) Deliver the messages in another manner:  eg, cause them to open
in
 TextEdit or a browser window.  I think a few lines of Applescript
 >>> would be enough to create a new window and display all the Notes
 messages from an install.  (We would even have the option to use rtf

 or html to format the messages to improve delivery.)  The user would

 essentially have an action list after the install.  Drawbacks:
 doesn't work for ssh-type connections to remote machines.  I think
 this could be very helpful

 Unfortunately, I lack most of the skills to actually implement
 anything like this.  :-(

 Thoughts?

 Craig

All the best, Ian W.


_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users


--
--
Craig Treleaven, CA -- Clearview Consulting
(905) 829-2054  ctrelea...@cogeco.ca
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Reply via email to