Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
On Feb 26 22:01:36, ctrelea...@cogeco.ca wrote: At 11:56 PM +0100 2/26/13, Chris Jones wrote: A simple notes happened above message would be ideal. Conversely, we'd be spewing twice as many messages if the install isn't interrupted. Why? If the messages were _only_ printed at the end? Why move where we're printing them when a simple hey, scroll up will suffice? Not everyone has their scroll history set to a reasonable size (in fact the default is often quite small) so if a lot of ports where installed, it may not even be possible to scroll up enough to see them... So I don't think you can just assume this will always work. It won't. I think the messages should probably be printed at the end, in one place. I don't particularly care either way if they are printed as well when the port in question is installed, but would tend toward yes, they should. So, my observation and proposal generated a substantial volume of discussion... The good: this seems to indicate that a number of people recognize the current situation is less-than-ideal. Yes. The bad: no clear consensus on how to improve. For consideration: it was a user's problem with the port kdenlive that prompted the discussion. Of its 270 dependencies, 6 use Notes (aspell, dbus, ffmpeg, kdelibs4, hunspell and python27; thanks pixilla) or approximately 2%. [1] So, for a new user who comes here specifically to install kdenlive as their first--maybe only--port, it would be a miracle if they actually noticed ANY of these messages. Yes. That is one part of the problem: (I) The user does not even know that some of the installs that happened above produced install messages he should read. The second part is: (II) Even if the user does know about the messages above, he has no _convenient_ way to go read them: (II.1) They are interspersed among all the other output. The user needs to _look_for_them_ in the other output. (II.2) The messages exist after the install finishes in a. the scroll buffer of the terminal window where the install happened. It is suggested that the user scrolls this buffer, possibly back to package one. This means proper 'port install' functionality relies on the user's terminal window's scroll buffer being large enough (and it assumes the user is in a 'window' in the first place). That's just plain wrong. b. the 'notes' of the installed/updated packages. To see those, it requires the user to take further action (namely, run 'port notes' with the right package's names). That's also less then ideal, and some packages don't even use notes, they use ui_msg (which is another thing we need to get rid of). The solution I propose solves all af the above: just print all the install notes at the end of the port run, possibly followed by a line 'read the install notes above'. It solves (I) because it's what the user sees when the port job finishes. It solves (II.1) because the notes are all in one place. As for (II.2), if the messages fit one screen, which is the majority of cases: just read them. If they don't fit on screen (what would be an example?), you have to either scroll back _BUT_ scroll back the few lines that didn't fit the screen (as opposed to scrolling back to package 7 of 270!) or run the port job through less or tee or whatever and see the bottom of it (as opposed to searching for it among other output). Another possibility is to just inform the user that certain packages have install notes, and simply name those packages. 25 lines should be enough for that. For comparison, the OpenBSD package system recognizes 'install messages' that get printed at the bottom of an install output, and 'package readmes' - longer texts that are just mentioned to exist in /usr/local/doc/pkgname at the bottom of the install output (example: the document that comes with a DB server describing how to set the DB up). Using a TextEdit window--for the 2% of ports needing to pass post-activation information to the user--would act much like the ReadMe window many .dmg installers finish with. God, no. Do not _open_a_window_ to display text. (1) It's completely unneeded. (2) It won't work for remote installs. To be clear, I was suggesting one window containing all the notes from that install run. It won't happen that often but it sure highlights important info for new users. That's desirable, but not via _opening_a_window_. It's text for christsakes! Printf it out and be done with it. For MacPorts experts, a command line switch and/or configuration setting could suppress these abominations. (Jan, please don't bother reiterating your opinion...you've made yourself crystal clear. I'd like to hear from others.) Ah, too late; sorry :-) However, I believe I have only made the argument crystal clear above. That said, just printing all the Notes messages at the end of an install run would
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
On Feb 25, 2013, at 3:42 PM, Jan Stary wrote: The modification IMHO belongs to port(1) itself: remember what was installed in this run, then print out all the messages (as opposed to printing every message just after the given port is installed), so that they are in one place and the user doesn't have to watch for it or scan the output. Re-posting all the notes at the end of an install/upgrade run may not give all the details you are looking for. What if all the dependencies were already installed and the current version? What is wrong with this current functionality for getting at the notes: $ port notes depof:kdenlive or more complete: $ port notes rdepof:kdenlive and less noisy: $ port notes rdepof:kdenlive | grep -v has no notes. Regards, Bradley Giesbrecht (pixilla) smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
On Feb 26 10:12:57, pixi...@macports.org wrote: On Feb 25, 2013, at 3:42 PM, Jan Stary wrote: The modification IMHO belongs to port(1) itself: remember what was installed in this run, then print out all the messages (as opposed to printing every message just after the given port is installed), so that they are in one place and the user doesn't have to watch for it or scan the output. Re-posting all the notes at the end of an install/upgrade run may not give all the details you are looking for. Such as? If there is notes for a package, it's because the package wants to say something to the user; the installing user IMHO is not 'looking for details' himself. What if all the dependencies were already installed and the current version? Then none of them was installed in this run (no need), and there is nothing to display. What is wrong with this current functionality for getting at the notes: $ port notes depof:kdenlive or more complete: $ port notes rdepof:kdenlive and less noisy: $ port notes rdepof:kdenlive | grep -v has no notes. There is nothing wrong with that; apparently I need to re-read the port manpage. However, this still requires an action of the user besides 'install'; I believe that the notes of the newly installed packages (if any) should be displayed as a part of 'install' automatically. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
On Feb 26 15:44:12, jer...@lavergne.gotdns.org wrote: There is nothing wrong with that; apparently I need to re-read the port manpage. However, this still requires an action of the user besides 'install'; I believe that the notes of the newly installed packages (if any) should be displayed as a part of 'install' automatically. A port's notes are printed as a package is installed. This is just semantically different than the request to get them all printed at once at the end of all operations. Well, that's exactly the difference as I understood it - there is currently no comfort way to get to the messages of all the things that got installed in a 'port install' job that just ended; the user needs to read and scan the whole output; a bit of searching makes it easier of course, but it would IMHO be desirable to have them all at the end (and therefore in one place). The suggested 'port notes' works for a given package; for example, if I run 'port install package', I can run 'port note depof:package' after that and get all the notes, in one place. But: (1) this should happen automatically as a part of the 'port install'. (2) it is bit of typing if it's actually port install one two three four five six port notes depof:one depof:two depof:three ... (3) as an extreme case, after 'port update outdated', there is no 'port notes depof:outdated'; the only way to get to all the install messages of everything that got installed or updated in this 'port update outdated' run is to scan through the whole output. Right? Jan ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
On Feb 26, 2013, at 4:10 PM, Jan Stary h...@stare.cz wrote: (3) as an extreme case, after 'port update outdated', there is no 'port notes depof:outdated'; the only way to get to all the install messages of everything that got installed or updated in this 'port update outdated' run is to scan through the whole output. Right? This is also the case for ports that for one reason or another (or maybe for no reason at all) output messages using ui_msg. vq ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
The suggested 'port notes' works for a given package; for example, if I run 'port install package', I can run 'port note depof:package' after that and get all the notes, in one place. But: (1) this should happen automatically as a part of the 'port install'. Well, we shouldn't put the messages solely at the end because an install can be interrupted for any number of reasons. Upon retry, those packages are then already installed and will not re-emit their messages unless you explicitly ask for them. Conversely, we'd be spewing twice as many messages if the install isn't interrupted. I propose a simple counter be used instead of a list: if we encountered any notes during an install, we alert the user to scroll up and read the notes. This avoids duplicate notes while ensuring the user gets a message. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
On Feb 26 16:34:07, jer...@lavergne.gotdns.org wrote: The suggested 'port notes' works for a given package; for example, if I run 'port install package', I can run 'port note depof:package' after that and get all the notes, in one place. But: (1) this should happen automatically as a part of the 'port install'. Well, we shouldn't put the messages solely at the end because an install can be interrupted for any number of reasons. Surely the install process does some maintenance at its exit (read: catches signals), and can spit out those messages even if it is exiting due to being interrupted (as opposed to finishing without error). Upon retry, those packages are then already installed and will not re-emit their messages unless you explicitly ask for them. Yes. Conversely, we'd be spewing twice as many messages if the install isn't interrupted. Why? If the messages were _only_ printed at the end? I propose a simple counter be used instead of a list: if we encountered any notes during an install, we alert the user to scroll up and read the notes. Yes, the user can scroll up and look for those messages. This inconvenience (not that serious of course) is my whole point here: that the user has to scrool and look for it. Isn't it trivial to cat all the install messages to a file, and cat that file upon exit (succesful or not)? This avoids duplicate notes What duplicate notes? ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
Surely the install process does some maintenance at its exit (read: catches signals), and can spit out those messages even if it is exiting due to being interrupted (as opposed to finishing without error). If MacPorts is quitting because the user is closing the window mid-process or the computer is rebooting, what difference will any messages make? If it alone was being killed by the user then we'd be flooding the screen with notes, when something (quite possibly displayed on the screen) made the user want to kill the command. A simple notes happened above message would be ideal. Conversely, we'd be spewing twice as many messages if the install isn't interrupted. Why? If the messages were _only_ printed at the end? Why move where we're printing them when a simple hey, scroll up will suffice? Yes, the user can scroll up and look for those messages. This inconvenience (not that serious of course) is my whole point here: that the user has to scrool and look for it. If there are more than 24 lines of notes, the user is already scrolling up. A simple message alerting you to the need to scroll up address the real concern (not knowing anything happened until after having scroll up--now you know before scrolling). Isn't it trivial to cat all the install messages to a file, and cat that file upon exit (succesful or not)? This avoids duplicate notes What duplicate notes? I was thinking we couldn't print notes solely at the end as we'd be pummeling the screen when the program exits. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
On Feb 26 16:56:23, jer...@lavergne.gotdns.org wrote: Surely the install process does some maintenance at its exit (read: catches signals), and can spit out those messages even if it is exiting due to being interrupted (as opposed to finishing without error). If MacPorts is quitting because the user is closing the window mid-process or the computer is rebooting, what difference will any messages make? What? Whay would the user be closing a window where an installation he started is running? Of course, if that is the case, or even a restart, then there will be no install messages either way; that's not what we're talking about. If it alone was being killed by the user (or anything) then we'd be flooding the screen with notes, What flooding? We would display the install messages of the package that got installed so far. when something (quite possibly displayed on the screen) made the user want to kill the command. Fair point. But he can scroll back to that too, right? Also, the majority (IMHO) of the port jobs, the typical run, is just that stuff gets installed/updated and that's it. So let's let the user have all the install messages in one convenient place for_such_typical_run, and have him scroll back _if_ there were errors. Right? A simple notes happened above message would be ideal. No, it's not ideal. That's my whole point. Having to scroll back and actively search for what packages wanted to tell me is not ideal. Conversely, we'd be spewing twice as many messages if the install isn't interrupted. Why? If the messages were _only_ printed at the end? Why move where we're printing them when a simple hey, scroll up will suffice? Yes, it will _suffice_. It will also suffice to write the logs and let the user read them after every run, so why are we even printing the pkg messages? Yes, the user can scroll up and look for those messages. This inconvenience (not that serious of course) is my whole point here: that the user has to scrool and look for it. If there are more than 24 lines of notes, the user is already scrolling up. A simple message alerting you to the need to scroll up address the real concern (not knowing anything happened until after having scroll up --now you know before scrolling). The problem here is not scrolling (of course it takes nothing to scroll up), but that the messages from the various packages are dispersed all over the output and the user has to search for them in the whole output. The modification I am proposing is SOLELY to have them at one place (namely, the bottom; where else). What duplicate notes? I was thinking we couldn't print notes solely at the end as we'd be pummeling the screen when the program exits. What pumelling the screen? Why are we printing the messages at all then? If they are printed after each individual package, there is not any less of them. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
On Feb 26 23:22:46, h...@stare.cz wrote: On Feb 26 16:56:23, jer...@lavergne.gotdns.org wrote: Surely the install process does some maintenance at its exit (read: catches signals), and can spit out those messages even if it is exiting due to being interrupted (as opposed to finishing without error). If MacPorts is quitting because the user is closing the window mid-process or the computer is rebooting, what difference will any messages make? What? Whay would the user be closing a window where an installation he started is running? And even if he wanted to kill the ongoing installation, why would he close the window, as opposed to simply killing the process in that (terminal) window? To lose any possibility of looking at the output? Even if you kills the installation, you still want to see the install messages of everything that got istalled so far. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
And even if he wanted to kill the ongoing installation, why would he close the window, as opposed to simply killing the process in that (terminal) window? There's a button there, the user can hit it. To lose any possibility of looking at the output? It was an accident! Tell me you've never accidentally closed anything in your life. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
Hi, A simple notes happened above message would be ideal. Conversely, we'd be spewing twice as many messages if the install isn't interrupted. Why? If the messages were _only_ printed at the end? Why move where we're printing them when a simple hey, scroll up will suffice? Not everyone has their scroll history set to a reasonable size (in fact the default is often quite small) so if a lot of ports where installed, it may not even be possible to scroll up enough to see them... So I don't think you can just assume this will always work. I think the messages should probably be printed at the end, in one place. I don't particularly care either way if they are printed as well when the port in question is installed, but would tend toward yes, they should. Chris ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
On Feb 26 17:35:45, jer...@lavergne.gotdns.org wrote: And even if he wanted to kill the ongoing installation, why would he close the window, as opposed to simply killing the process in that (terminal) window? There's a button there, the user can hit it. To lose any possibility of looking at the output? It was an accident! Tell me you've never accidentally closed anything in your life. Jesus, yes. Are you avoiding it on purpose? The user accidentally closes the window; the system reboots; you forgot - the whole computer crashes. I agree, in such situations we cannot do anything. How does that make install messages interspersed in various places in the install output better than having them at one place? ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
On Tue, Feb 26, 2013 at 3:04 PM, Jan Stary h...@stare.cz wrote: I agree, in such situations we cannot do anything. How does that make install messages interspersed in various places in the install output better than having them at one place? Perhaps it is minor, but because if you are watching the install you can still see the notes get printed, before your system crashes. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
At 11:56 PM +0100 2/26/13, Chris Jones wrote: A simple notes happened above message would be ideal. Conversely, we'd be spewing twice as many messages if the install isn't interrupted. Why? If the messages were _only_ printed at the end? Why move where we're printing them when a simple hey, scroll up will suffice? Not everyone has their scroll history set to a reasonable size (in fact the default is often quite small) so if a lot of ports where installed, it may not even be possible to scroll up enough to see them... So I don't think you can just assume this will always work. I think the messages should probably be printed at the end, in one place. I don't particularly care either way if they are printed as well when the port in question is installed, but would tend toward yes, they should. So, my observation and proposal generated a substantial volume of discussion... The good: this seems to indicate that a number of people recognize the current situation is less-than-ideal. The bad: no clear consensus on how to improve. For consideration: it was a user's problem with the port kdenlive that prompted the discussion. Of its 270 dependencies, 6 use Notes (aspell, dbus, ffmpeg, kdelibs4, hunspell and python27; thanks pixilla) or approximately 2%. [1] So, for a new user who comes here specifically to install kdenlive as their first--maybe only--port, it would be a miracle if they actually noticed ANY of these messages. Using a TextEdit window--for the 2% of ports needing to pass post-activation information to the user--would act much like the ReadMe window many .dmg installers finish with. To be clear, I was suggesting one window containing all the notes from that install run. It won't happen that often but it sure highlights important info for new users. For MacPorts experts, a command line switch and/or configuration setting could suppress these abominations. (Jan, please don't bother reiterating your opinion...you've made yourself crystal clear. I'd like to hear from others.) That said, just printing all the Notes messages at the end of an install run would be a huge improvement. Doesn't matter if only 1 dependency installed or everything; if a port with a Note installed, presumably the user needs to address that requirement. Craig [1] Also checked the rdeps for another sizable package I have installed: gramps. It has 192 dependencies of which 4 use Notes; again about 2%. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
On Feb 26 15:37:45, sewebs...@gmail.com wrote: On Tue, Feb 26, 2013 at 3:04 PM, Jan Stary h...@stare.cz wrote: I agree, in such situations we cannot do anything. How does that make install messages interspersed in various places in the install output better than having them at one place? Perhaps it is minor, but because if you are watching the install you ^^^ You mean you launch 'port install' and watch it line by line, playing the game of read-it--before-it-scrolls-away? Are you serious? can still see the notes get printed, Possibly, if you spend the entire time an install takes to run staring into the screen. Laughable. before your system crashes. What's with the crashes? I am talking about a normal routine port job. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
On Feb 24 20:50:52, ctrelea...@cogeco.ca wrote: At 5:23 PM -0600 2/24/13, Jim Graham wrote: On Sun, Feb 24, 2013 at 11:03:54PM +, Chris Jones wrote: On 24 Feb 2013, at 10:59pm, Jim Graham spooky1...@gmail.com wrote: There is nothing wrong with KDE, as long as you properly install the dependencies it requires. My reading of this rather long thread is all of the problems would have been avoided if the OP had followed the instructions as presented to them. You cannot blame KDE for the problems that arose because they didn't. But as the OP in question, I didn't KNOW about any of the KDE stuff AT ALL. I didn't know that I needed this, that, and the other bit. I didn't know that I needed to run other stuff first, or that macports does not actually install aoo of the dependent stuff for KDE as I'd assumed it did. The errors I saw were completely alien to me. I'd never run into stuff like that before. So excuse me if I can't read minds. Oh, and I didn't install KDE. It was installed by something else (maybe it was kdenlive, maybe something a long time ago...I don't know). 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. 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!!! No way. 2) Make such messages stand out more: use more distinct visual cues such as colour or font. No. 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? That still needs me to watch the terminal closely as the installation progresses. No. 3) Deliver the messages in another manner: eg, cause them to open in TextEdit or a browser window. That needs the capability to open a window. No way. 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.) No fucking way. 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 Thoughts? How about: print all the meesages at the very end of the whole install. That's how OpenBSD does it. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
On Feb 25 00:05:09, jer...@lavergne.gotdns.org wrote: Crown was a lovely autocorrect for cron Crown job sounds a bit nasty though. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
On Mon, Feb 25, 2013 at 02:05:07PM +0100, Jan Stary wrote:
On Feb 24 20:50:52, ctrelea...@cogeco.ca wrote:
3) Deliver the messages in another manner: eg, cause them to open
in TextEdit or a browser window.
That needs the capability to open a window.
No way.
There may be something I'm missing here, but why No way ?
I've already written a command-line pair of Tcl/Tk scripts
that should work fine, and last night, e-mailed them to
Craig (off-list) in a response to the post you're responding
to.
It works like this:
First, there's a server app that opens a text widget in Tk, and listens
on a port (by default, port 12345). When it receives a message, it
displays it in the text window. I wrote it with two fonts for the
text: {Courier 18 bold} (and a tag to make it red for stuff that needs
to be stressed) and {Courier 16} for normal text. An arg to the client
determines which, and that is then sent to the server before the message
itself.
The client app can take the message text from either the second arg (the
first is the text mode described above) OR from stdin.
The idea is, you start the server at the very beginning, a text widget
(with a scrollbar and, if the autoscroll extension is included, the
scrollbar will only show up if needed). Then, when you have a message
(say, this is a text message) with an important header (important
header) you could do something like this (after starting the server
at the beginning):
add_text.tcl boldred important header
add_text.tcl normal this is a text message
It would also be trivial to modify the server to put a blank line between
text messages, but last night, I was trying to finish up between
thunderstorms
Anyways, it's out there if anyone thinks it's a good idea. If not, oh
well.
Later,
--jim
--
THE SCORE: ME: 2 CANCER: 0
73 DE N5IAL (/4)MiSTie #49997 Running Mac OS X Lion
spooky1...@gmail.com ICBM/Hurricane: 30.44406N 86.59909W
Do not look into laser with remaining eye.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
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
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
At 2:05 PM +0100 2/25/13, Jan Stary wrote: On Feb 24 20:50:52, ctrelea...@cogeco.ca wrote: At 5:23 PM -0600 2/24/13, Jim Graham wrote: On Sun, Feb 24, 2013 at 11:03:54PM +, Chris Jones wrote: On 24 Feb 2013, at 10:59pm, Jim Graham spooky1...@gmail.com wrote: [...] 3) Deliver the messages in another manner: eg, cause them to open in TextEdit or a browser window. That needs the capability to open a window. No way. Um, OS X includes this graphical user interface thingy. We don't have to ignore it _all_ the time! 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.) No fucking way. Interesting. Which part offends you so much: Applescript or formatting? 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 Thoughts? How about: print all the meesages at the very end of the whole install. That's how OpenBSD does it. That would be an improvement as long as users aren't left hanging on cancelled or failed installs. Craig ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
Another idea would be to pause by default on all important messages, maybe with an CLI argument to suppress the pause for people who don't need it. On Mon, Feb 25, 2013 at 2:57 PM, Craig Treleaven ctrelea...@cogeco.cawrote: At 2:05 PM +0100 2/25/13, Jan Stary wrote: On Feb 24 20:50:52, ctrelea...@cogeco.ca wrote: At 5:23 PM -0600 2/24/13, Jim Graham wrote: On Sun, Feb 24, 2013 at 11:03:54PM +, Chris Jones wrote: On 24 Feb 2013, at 10:59pm, Jim Graham spooky1...@gmail.com wrote: [...] 3) Deliver the messages in another manner: eg, cause them to open in TextEdit or a browser window. That needs the capability to open a window. No way. Um, OS X includes this graphical user interface thingy. We don't have to ignore it _all_ the time! 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.) No fucking way. Interesting. Which part offends you so much: Applescript or formatting? 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 Thoughts? How about: print all the meesages at the very end of the whole install. That's how OpenBSD does it. That would be an improvement as long as users aren't left hanging on cancelled or failed installs. Craig __**_ macports-users mailing list macports-users@lists.**macosforge.orgmacports-users@lists.macosforge.org https://lists.macosforge.org/**mailman/listinfo/macports-**usershttps://lists.macosforge.org/mailman/listinfo/macports-users -- Jean Gobin, CCENT, CCNA, CCNA Security http://newsfromjean.blogspot.com/ ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
On Feb 25, 2013, at 5:42 AM, Jim Graham wrote: On Mon, Feb 25, 2013 at 02:05:07PM +0100, Jan Stary wrote: On Feb 24 20:50:52, ctrelea...@cogeco.ca wrote: 3) Deliver the messages in another manner: eg, cause them to open in TextEdit or a browser window. That needs the capability to open a window. No way. There may be something I'm missing here, but why No way ? Where would the window open for remote installs via ssh? Regards, Bradley Giesbrecht (pixilla) smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
On Mon, Feb 25, 2013 at 07:56:13AM -0800, Bradley Giesbrecht wrote: On Feb 25, 2013, at 5:42 AM, Jim Graham wrote: On Mon, Feb 25, 2013 at 02:05:07PM +0100, Jan Stary wrote: On Feb 24 20:50:52, ctrelea...@cogeco.ca wrote: 3) Deliver the messages in another manner: eg, cause them to open in TextEdit or a browser window. That needs the capability to open a window. No way. There may be something I'm missing here, but why No way ? Where would the window open for remote installs via ssh? As long as Tcl/Tk is built as an X11 app, I would assume that it would be opened as any other X11 app would be opened remotely. On the other hand, I'm fairly certain that Tcl's socket command works with remote systems, too. But between harsh chemotherapy and the resulting chemobrain (if you dkn't know, look it up), 3 brain tumors (the worst being a 2.5 cm diameter tumor in my left occipital lobe, 3 severe brain surgeries in one ten hour session to remove each of the 3 tumors, then whole-brain max-dose radiation therapy to the brain (all of this from cancer #1), I've got limits on how long I can work on stuff, and between yesterday and today, I've gone WAY beyond the point where those limits decided to be today (they're anything but consistent).. Result: my eyes are about 99% blurred, and I'm headed for a whopper of a migraine in about 45 minutes (that part IS consistent). So I'll have to look into that later. That, or someone else can. It's in the Tcl docs (Tcl commands) under socket. I tried, but I can't keep my eyes focused for more than a fraction of a second at best, Later (as in, maybe by tomorrow or a day or two later), --jim -- THE SCORE: ME: 2 CANCER: 0 73 DE N5IAL (/4) | Peter da Silva: No, try rm -rf / spooky1...@gmail.com | Dave Aronson:As your life flashes before Running Mac OS X Lion | your eyes, in the unit of time known as an ICBM / Hurricane: | ohnosecond (alt.sysadmin.recovery) 30.44406N 86. 59909W | ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
On Feb 25 07:42:04, spooky1...@gmail.com wrote:
On Mon, Feb 25, 2013 at 02:05:07PM +0100, Jan Stary wrote:
On Feb 24 20:50:52, ctrelea...@cogeco.ca wrote:
3) Deliver the messages in another manner: eg, cause them to open
in TextEdit or a browser window.
That needs the capability to open a window.
No way.
There may be something I'm missing here, but why No way ?
Because it wants to open new windows.
I've already written a command-line pair of Tcl/Tk scripts
that should work fine, and last night, e-mailed them to
Craig (off-list) in a response to the post you're responding
to.
It works like this:
First, there's a server app that opens a text widget in Tk, and listens
on a port (by default, port 12345). When it receives a message, it
displays it in the text window. I wrote it with two fonts for the
text: {Courier 18 bold} (and a tag to make it red for stuff that needs
to be stressed) and {Courier 16} for normal text. An arg to the client
determines which, and that is then sent to the server before the message
itself.
Are you trolling or just high?
Running a server application that opens new windows
just to _display_a_few_lines_of_text_ ??
(Using various fonts, for sure.
But where's the piechart?
Where is the XML, I ask.)
The client app can take the message text from either the second arg (the
first is the text mode described above) OR from stdin.
The idea is, you start the server at the very beginning, a text widget
(with a scrollbar and, if the autoscroll extension is included, the
scrollbar will only show up if needed). Then, when you have a message
(say, this is a text message) with an important header (important
header) you could do something like this (after starting the server
at the beginning):
add_text.tcl boldred important header
add_text.tcl normal this is a text message
It would also be trivial to modify the server to put a blank line between
text messages, but last night, I was trying to finish up between
thunderstorms
How's about you just display all the packages messages
after the port(1) job finishes, and the user, uh, I don't know,
reads them?
Whether you have ever heard about the Keep It Simple, Stupid
principle before or not, you are trying to fsck it in the ear.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
On Feb 25 11:18:38, spooky1...@gmail.com wrote: On Mon, Feb 25, 2013 at 07:56:13AM -0800, Bradley Giesbrecht wrote: On Feb 25, 2013, at 5:42 AM, Jim Graham wrote: On Mon, Feb 25, 2013 at 02:05:07PM +0100, Jan Stary wrote: On Feb 24 20:50:52, ctrelea...@cogeco.ca wrote: 3) Deliver the messages in another manner: eg, cause them to open in TextEdit or a browser window. That needs the capability to open a window. No way. There may be something I'm missing here, but why No way ? Where would the window open for remote installs via ssh? As long as Tcl/Tk is built as an X11 app, I would assume that it would be opened as any other X11 app would be opened remotely. Would it be in color too? ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
How's about you just display all the packages messages after the port(1) job finishes, and the user, uh, I don't know, reads them? It would probably be sufficient to re-display notes after a more-than-one-port-was-installed command. you are trying to fsck it in the ear. Come on, Jan. No need to tcl the man to /dev/null. :-P ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
On Feb 25 08:57:09, ctrelea...@cogeco.ca wrote: At 2:05 PM +0100 2/25/13, Jan Stary wrote: On Feb 24 20:50:52, ctrelea...@cogeco.ca wrote: At 5:23 PM -0600 2/24/13, Jim Graham wrote: On Sun, Feb 24, 2013 at 11:03:54PM +, Chris Jones wrote: On 24 Feb 2013, at 10:59pm, Jim Graham spooky1...@gmail.com wrote: [...] 3) Deliver the messages in another manner: eg, cause them to open in TextEdit or a browser window. That needs the capability to open a window. No way. Um, OS X includes this graphical user interface thingy. We don't have to ignore it _all_ the time! Which clearly is a reason to _display_text_ with a GUI. Right. We also have the say(1) command. I'd like my install message in a southern Irish voice please. 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.) No fucking way. Interesting. Which part offends you so much: Applescript or formatting? Opening new windows, rtf and hmtl. How about: print all the meesages at the very end of the whole install. That's how OpenBSD does it. That would be an improvement as long as users aren't left hanging on cancelled or failed installs. Display all the messages of all that has been installed, whether the port(1) job as a whole finished successfully or not. Of course. An install that't left hanging does nothing either way. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
Back way before I expected to be able to return. Strange.
On Mon, Feb 25, 2013 at 08:13:39PM +0100, Jan Stary wrote:
On Feb 25 07:42:04, spooky1...@gmail.com wrote:
On Mon, Feb 25, 2013 at 02:05:07PM +0100, Jan Stary wrote:
On Feb 24 20:50:52, ctrelea...@cogeco.ca wrote:
3) Deliver the messages in another manner: eg, cause them to open
in TextEdit or a browser window.
That needs the capability to open a window.
No way.
There may be something I'm missing here, but why No way ?
Because it wants to open new windows.
Yeah, you said that, and someone else asked about using it in a non-GUI
environment. Ok, but it doesn't HAVE to be a GUI version. Switching
it from using a text widget and scrollbars would mean changing a few
lines of code (e.g., instead of $w.t insert end $message\n d
just use puts $message). If the idea is to add it at the end, so it
doesn't scroll right past whatever the user's scrollback buffer is set
to, that's just a few more lines:
for each text sent:
lappend mlist $message
and later, when it's all finished (or crashes):
foreach line $mlist { puts $line }
Yeah, very difficult. :-)
I've already written a command-line pair of Tcl/Tk scripts
that should work fine, and last night, e-mailed them to
Craig (off-list) in a response to the post you're responding
to.
Are you trolling or just high?
I won't dignify that last bit with an answer. As for trolling, while I
do love fishing:
A) Wrong time of year for mackeral here (they're further south right now)
B) With the severe t-storms we had all night and well into this
morning, even the charter boat captains who were the most
desperately in need of cash wouldn't even THINK about going through
the East Pass to get out onto the Gulf
C) If I WAS out on the Gulf trolling last night, I wouldn't have been
here typing away at my computer, now would I?
So no, I was not out trolling. I was here. And WTF does whether or not
I was out fishing last night or this morning have to do with anything
even remotely macports related, anyways?
Running a server application that opens new windows
just to _display_a_few_lines_of_text_ ??
First, I was told that it's often a lot more than a few lines of text.
But second, it seemed like the easiest way to do it. You start up the
server with a one-line command, which then accepts the text to display
via a simple Tcl socket command from the client (puts $chan $message)
and displays it. Wow...very difficult. Yeah, very tough to code. :-)
But there's another point here, and that is, with one app running to
display the text (whether in a text widget or just printing to a
terminal, perhaps using less as a pager, you'd have to keep some type
of interface to it open. A simple second app that sends it the text
to display, and is its own one-line (or longer for longer text) command,
seems, to me, to be the easiest way to implement it:
add_text.tcl normal you need to do something now to make this work
OR in a GUI, if you want larger, bold, red text to emphasize something,
add_text.tcl boldred you need to do something now to make this work
I could add more than just a bold/red/larger option if needed, but that's
what's in there right now.
(Using various fonts, for sure.
Yep. It's currently set up for Courier, but that's easy to change (two
lines---one for normal and one for larger, bold, red text) set in the
server app.
But where's the piechart?
What pie chart are you referring to? Nobody told me that was a
requirement.
Where is the XML, I ask.)
Same question for XML. Nobody said anything about that to me.
How's about you just display all the packages messages
after the port(1) job finishes, and the user, uh, I don't know,
reads them?
You mean something like others and I were discussing both on-list
and off-list earlier this morning, and also mentioned above?
Yeah, in a text-only version, that would be, in my opinion for
what it apparently is not worth crap here, would be the best
way to do that.
Whether you have ever heard about the Keep It Simple, Stupid
principle before or not, you are trying to fsck it in the ear.
You consider 75 lines of code for both the client and the server
(including all blank lines and comments---basically just
wc -l * output) NOT simple? Wow. That's pretty severe.
Not only that, but the idea was to also keep the IMPLEMENTATION
simple, too. I think my idea would have done that quite well.
Ok, so it's a bad idea. I did say, in my first mention of this, that if
nobody wanted to use it, oh well. It doesn't bother me a bit if nobody
liks this or any of my ideas...my rather insignificant ego doesn't give a
shit, and even then, I tell it to go fsck itself if it speaks up at all.
So I'll just scrap the idea and go back to what I was doing before.
Besides, I'd hate to have to make those [sarcasm mode on afterburners]
very complicated [sarcasm off] one or two line
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
On Mon, Feb 25, 2013 at 08:20:19PM +0100, Jan Stary wrote: On Feb 25 08:57:09, ctrelea...@cogeco.ca wrote: Um, OS X includes this graphical user interface thingy. We don't have to ignore it _all_ the time! Which clearly is a reason to _display_text_ with a GUI. Right. Hmmm, I wonder why Tk includes a text widget, labels, text for other widgets (buttons, radiobuttons, checkboxes, etc.), then. We also have the say(1) command. Ok, so what? Just use exec and a command like say bite me I'd like my install message in a southern Irish voice please. I seem to recall that the TTS programs I've seen lately, including the one (or ones) available on Mac OS X, do support languages other than English. Whatever. -- THE SCORE: ME: 2 CANCER: 0 73 DE N5IAL (/4) | Peter da Silva: No, try rm -rf / spooky1...@gmail.com | Dave Aronson:As your life flashes before Running Mac OS X Lion | your eyes, in the unit of time known as an ICBM / Hurricane: | ohnosecond (alt.sysadmin.recovery) 30.44406N 86. 59909W | ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
Hello from a fellow OM and MacPorts dev!
On 25/feb/2013, at 23:12, Jim Graham spooky1...@gmail.com wrote:
Back way before I expected to be able to return. Strange.
On Mon, Feb 25, 2013 at 08:13:39PM +0100, Jan Stary wrote:
On Feb 25 07:42:04, spooky1...@gmail.com wrote:
On Mon, Feb 25, 2013 at 02:05:07PM +0100, Jan Stary wrote:
There may be something I'm missing here, but why No way ?
Because it wants to open new windows.
Yeah, you said that, and someone else asked about using it in a non-GUI
environment. Ok, but it doesn't HAVE to be a GUI version. Switching
it from using a text widget and scrollbars would mean changing a few
lines of code (e.g., instead of $w.t insert end $message\n d
just use puts $message). If the idea is to add it at the end, so it
doesn't scroll right past whatever the user's scrollback buffer is set
to, that's just a few more lines:
for each text sent:
lappend mlist $message
and later, when it's all finished (or crashes):
foreach line $mlist { puts $line }
Yeah, very difficult. :-)
The point is not that it's difficult, but rather cumbersome and not needed by
all. Since we are OM, let's talk radio:
Say you do 150WPM CW on your trusty self made QRP transmitter. It's yours, you
know it in and out and you like it that way, it does exactly what you intend to
do, send out a wave when you press your key. Nothing more, nothing less.
Now say that someone takes your beloved transmitter and shoves a FT1000 in your
face. Bam! Thousand buttons, things blinking, SSB traffic blowing from the
speaker. What's your reaction?
I've already written a command-line pair of Tcl/Tk scripts
that should work fine, and last night, e-mailed them to
Craig (off-list) in a response to the post you're responding
to.
Are you trolling or just high?
I won't dignify that last bit with an answer. As for trolling, while I
do love fishing:
A) Wrong time of year for mackeral here (they're further south right now)
B) With the severe t-storms we had all night and well into this
morning, even the charter boat captains who were the most
desperately in need of cash wouldn't even THINK about going through
the East Pass to get out onto the Gulf
C) If I WAS out on the Gulf trolling last night, I wouldn't have been
here typing away at my computer, now would I?
So no, I was not out trolling. I was here. And WTF does whether or not
I was out fishing last night or this morning have to do with anything
even remotely macports related, anyways?
Oh, come on. I believe you wouldn't behave like that on the air. Jan clearly
meant something else.
Running a server application that opens new windows
just to _display_a_few_lines_of_text_ ??
First, I was told that it's often a lot more than a few lines of text.
But second, it seemed like the easiest way to do it. You start up the
server with a one-line command, which then accepts the text to display
via a simple Tcl socket command from the client (puts $chan $message)
and displays it. Wow...very difficult. Yeah, very tough to code. :-)
But there's another point here, and that is, with one app running to
display the text (whether in a text widget or just printing to a
terminal, perhaps using less as a pager, you'd have to keep some type
of interface to it open. A simple second app that sends it the text
to display, and is its own one-line (or longer for longer text) command,
seems, to me, to be the easiest way to implement it:
add_text.tcl normal you need to do something now to make this work
OR in a GUI, if you want larger, bold, red text to emphasize something,
add_text.tcl boldred you need to do something now to make this work
I could add more than just a bold/red/larger option if needed, but that's
what's in there right now.
(Using various fonts, for sure.
Yep. It's currently set up for Courier, but that's easy to change (two
lines---one for normal and one for larger, bold, red text) set in the
server app.
But where's the piechart?
What pie chart are you referring to? Nobody told me that was a
requirement.
Where is the XML, I ask.)
Same question for XML. Nobody said anything about that to me.
How's about you just display all the packages messages
after the port(1) job finishes, and the user, uh, I don't know,
reads them?
You mean something like others and I were discussing both on-list
and off-list earlier this morning, and also mentioned above?
Yeah, in a text-only version, that would be, in my opinion for
what it apparently is not worth crap here, would be the best
way to do that.
Whether you have ever heard about the Keep It Simple, Stupid
principle before or not, you are trying to fsck it in the ear.
You consider 75 lines of code for both the client and the server
(including all blank lines and comments---basically just
wc -l * output) NOT simple? Wow. That's pretty severe.
Not
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
On 2013-02-25 23:12, Jim Graham wrote:
Yeah, you said that, and someone else asked about using it in a non-GUI
environment. Ok, but it doesn't HAVE to be a GUI version. Switching
it from using a text widget and scrollbars would mean changing a few
lines of code (e.g., instead of $w.t insert end $message\n d
just use puts $message). If the idea is to add it at the end, so it
doesn't scroll right past whatever the user's scrollback buffer is set
to, that's just a few more lines:
for each text sent:
lappend mlist $message
and later, when it's all finished (or crashes):
foreach line $mlist { puts $line }
Yeah, very difficult. :-)
Well, I think this discussion already left the scope of the
macports-users mailing list. Collecting notes of a port installation run
and displaying them at the end again is definitely possible (maybe even
write them to a separate persistent log file, send emails, display Growl
messages, ...)
Implementing a feature like this does not have to be difficult, it just
needs someone to take it up and actually write code for it.
If anyone still reading this thread is actually serious about
implementing this feature I would recommend to take the discussion to
the macports-dev list.
Rainer
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
On Mon, Feb 25, 2013 at 11:29:58PM +0100, Alja?? Srebrni?? wrote: Hello from a fellow OM and MacPorts dev! Just to be clear, I'm not a macports dev On 25/feb/2013, at 23:12, Jim Graham spooky1...@gmail.com wrote: Since we are OM, let's talk radio Ok. :-) Say you do 150WPM CW on your trusty 150??? The highest I ever got was 28 (sometimes 29) wpm. Never could cross that barrier to 30 wpm for the straight shot to 58 wpm When I tested fromo Tech to General, I was 1 char short of passing the Extra code at 20, and when I took the General 13 wpm test, I almost fell asleep (literally). The VE had seen me all relaxed, confidently reading 20 wpm with no difficulty, and difficulty staying awake at 13, and didn't even want to SEE my 13 wpm test...he just passed me on the spot. Not long after that, I was working a QSO at 28 wpm, and a friend arrived at my door. I kept copying while going to answer the door, told my friend to follow me on back, because the other guy was just turning it over to me, and my friend and I were chatting while I was also sending and receiving at 28 wpm Now, however, I doubt I could handle 5 without spenging some time in the Novice bands. Now say that someone takes your beloved transmitter and shoves a FT1000 in your face. Bam! Thousand buttons, things blinking, SSB traffic blowing from the speaker. What's your reaction? I have a Kenwood TS-130. At AM, in our amateur radio club (W5AC), at that time we had a Kenwood TS-930, an equally modern Icon rig, a 1.5 kW amp, and a 60' tower on top of the bell tower (roughly 100' total, with a 7-element tri-bander (15m, 20m, and 10m), a 2-element 40m beam, a 30m sloper (I added that one myself) and a full VHF satellite setup with circular polarized (can't remember if it was L or R circular) set on top. Favorite QSO was with 5H3GB (Dan in Tanzania) on an otherwise dead 15m, for an hour or so, barefoot (125 W) until the last minutes as we were saying 73, and we both had to kick in our kW amps. Ok, let's get back on-topic now Are you trolling or just high? I won't dignify that last bit with an answer. As for trolling, while I do love fishing: A) Wrong time of year for mackeral here (they're further south right now) B) With the severe t-storms we had all night and well into this morning, even the charter boat captains who were the most desperately in need of cash wouldn't even THINK about going through the East Pass to get out onto the Gulf C) If I WAS out on the Gulf trolling last night, I wouldn't have been here typing away at my computer, now would I? So no, I was not out trolling. I was here. And WTF does whether or not I was out fishing last night or this morning have to do with anything even remotely macports related, anyways? Oh, come on. I believe you wouldn't behave like that on the air. Jan clearly meant something else. Actually, when I saw trolling, fishing is exactly what came to my mind. We're only a couple weeks until, at least around docks and bridges, the season opens up, so fishing is very much on my mind right now. Anyways, nerves in my right hand and arm just went dead again, so I'm out of here. 73. -- THE SCORE: ME: 2 CANCER: 0 73 DE N5IAL (/4) | Remember your spelling rules, including: spooky1...@gmail.com | I before E except after C Running Mac OS X Lion | ICBM / Hurricane: | BEING a native-born American, I don't 30.44406N 86.59909W| always notice our WEIRD spelling ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
On Feb 25 16:12:12, spooky1...@gmail.com wrote:
Back way before I expected to be able to return. Strange.
On Mon, Feb 25, 2013 at 08:13:39PM +0100, Jan Stary wrote:
On Feb 25 07:42:04, spooky1...@gmail.com wrote:
On Mon, Feb 25, 2013 at 02:05:07PM +0100, Jan Stary wrote:
On Feb 24 20:50:52, ctrelea...@cogeco.ca wrote:
3) Deliver the messages in another manner: eg, cause them to open
in TextEdit or a browser window.
That needs the capability to open a window.
No way.
There may be something I'm missing here, but why No way ?
Because it wants to open new windows.
Yeah, you said that, and someone else asked about using it in a non-GUI
environment. Ok, but it doesn't HAVE to be a GUI version. Switching
it from using a text widget and scrollbars would mean changing a few
lines of code (e.g., instead of $w.t insert end $message\n d
just use puts $message). If the idea is to add it at the end, so it
doesn't scroll right past whatever the user's scrollback buffer is set
to, that's just a few more lines:
for each text sent:
lappend mlist $message
and later, when it's all finished (or crashes):
foreach line $mlist { puts $line }
You still don't get it, do you.
Running a server application that opens new windows
just to _display_a_few_lines_of_text_ ??
First, I was told that it's often a lot more than a few lines of text.
But second, it seemed like the easiest way to do it. You start up the
server with a one-line command, which then accepts the text to display
via a simple Tcl socket command from the client (puts $chan $message)
and displays it. Wow...very difficult. Yeah, very tough to code. :-)
Repaet after me:
if you want to display some text in a port(1) job,
do not start up a server for it.
But there's another point here, and that is, with one app running to
display the text (whether in a text widget or just printing to a
terminal, perhaps using less as a pager, you'd have to keep some type
of interface to it open. A simple second app that sends it the text
to display, and is its own one-line (or longer for longer text) command,
seems, to me, to be the easiest way to implement it:
add_text.tcl normal you need to do something now to make this work
OR in a GUI, if you want larger, bold, red text to emphasize something,
add_text.tcl boldred you need to do something now to make this work
I could add more than just a bold/red/larger option if needed, but that's
what's in there right now.
(Using various fonts, for sure.
Yep. It's currently set up for Courier, but that's easy to change (two
lines---one for normal and one for larger, bold, red text) set in the
server app.
But where's the piechart?
What pie chart are you referring to? Nobody told me that was a
requirement.
Where is the XML, I ask.)
Same question for XML. Nobody said anything about that to me.
I am genuinely not sure now whether you are trying
to be funny or actually are that thick.
How's about you just display all the packages messages
after the port(1) job finishes, and the user, uh, I don't know,
reads them?
You mean something like others and I were discussing both on-list
and off-list earlier this morning, and also mentioned above?
Yeah, in a text-only version, that would be, in my opinion for
what it apparently is not worth crap here, would be the best
way to do that.
Yes. Displaying a message would probably be
best done in text. Yes. With a printf. Yes.
Whether you have ever heard about the Keep It Simple, Stupid
principle before or not, you are trying to fsck it in the ear.
You consider 75 lines of code for both the client and the server
(including all blank lines and comments---basically just
wc -l * output) NOT simple?
No. I consider launching two totally unneeded
client-server processes not simple.
Not only that, but the idea was to also keep the IMPLEMENTATION
simple, too. I think my idea would have done that quite well.
Your idea is stupid.
The modification IMHO belongs to port(1) itself:
remember what was installed in this run, then
print out all the messages (as opposed to printing
every message just after the given port is installed),
so that they are in one place and the user doesn't
have to watch for it or scan the output.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
The modification IMHO belongs to port(1) itself: remember what was installed in this run, then print out all the messages (as opposed to printing every message just after the given port is installed), so that they are in one place and the user doesn't have to watch for it or scan the output. Not only do I agree, but I think that an option to suppress normal output, leaving only the important stuff, would be nice -- so that under normal operations, only those notes would be output. --- This is coming from Mail.app. I hate the new Gmail web look, and dislike Mail only slightly less. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
There are issues on all fronts: crown job updates, distributed installs, etc. No one size fits all :-) Craig Treleaven ctrelea...@cogeco.ca wrote: At 5:23 PM -0600 2/24/13, Jim Graham wrote: On Sun, Feb 24, 2013 at 11:03:54PM +, Chris Jones wrote: On 24 Feb 2013, at 10:59pm, Jim Graham spooky1...@gmail.com wrote: There is nothing wrong with KDE, as long as you properly install the dependencies it requires. My reading of this rather long thread is all of the problems would have been avoided if the OP had followed the instructions as presented to them. You cannot blame KDE for the problems that arose because they didn't. But as the OP in question, I didn't KNOW about any of the KDE stuff AT ALL. I didn't know that I needed this, that, and the other bit. I didn't know that I needed to run other stuff first, or that macports does not actually install aoo of the dependent stuff for KDE as I'd assumed it did. The errors I saw were completely alien to me. I'd never run into stuff like that before. So excuse me if I can't read minds. Oh, and I didn't install KDE. It was installed by something else (maybe it was kdenlive, maybe something a long time ago...I don't know). 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. 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 ___ 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
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
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
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
Crown was a lovely autocorrect for cron 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
Re: Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)
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
