Notes...that flash by and are gone...(was Re: any good audio/video editing apps in macports?)

[Jan Stary]

On Feb 25 16:12:12, spooky130u at 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, spooky130u at gmail.com wrote:
> > > On Mon, Feb 25, 2013 at 02:05:07PM +0100, Jan Stary wrote:
> > > > On Feb 24 20:50:52, ctreleaven at 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.