Text on HUDs

It's not a matter of "forcing compliance", it's a matter of only exposing in the interface those details that are relevant to the abstraction that the interface is a reflection of, and the environment that the interface is explosed to.

That's a separate issue. If the environment on the "outside" of the interface has a mechanism for presenting multiple kinds of objects at the interface, then the interface exposed to that environment must of course be able to identify and verify each of those kinds of objects before accepting them. Where the environment doesn't have multiple kinds of objects, then there's no advantage to creating the illusion that they exist.

Not at all. The interface I'm talking about is completely driven by the abstraction. The only relationship between the structures on the "inside" of the interface and the "outside" of the interface is that they both model the same abstraction.

But the new parameters aren't, and LSL functions and parameters to ll*PrimitiveParams are the same thing. They're in the same name space, the same table, there's virtually no difference between adding one or the other, except it becomes possible to do better error checking if it's a function. That's it.

That's the point you're missing... you seem to think that ll*PrimitiveParams is somehow more abstract because it looks like what you think of as an abstraction. The difference in appearance is purely cosmetic. The presence or absence of a functional interface doesn't change whether it's an abstraction or not.

No they're not. None of the features you're proposing alre already implemented in the UI.

That is true regardless of whether llRenderText is implemented. There's no difference between llRenderText and PRIMITIVE_OVERLAY_TEXT except syntax.

This is the thing that I keep trying to get across to you. The things that you're worried about have nothing to do with the implementation.

LSL does not implement nested lists. It has no mechanism for creating them or manipulating them. You can encode a list as a string, and put it in a list. You can embed a reference to part of a second list or the same list in a list, by establishing a convention that (for example) a vector with certain values should be trested as a reference. You can embed a count or a terminator in a list. But none of these things are "nested lists".

Where have I said that text on HUDS should be restricted to scripted text? What I'm saying is that non-scripted text on HUDs is not relevant to this thread.

Who's relying on them? I'm pointing this out as an advantage.

Er, no. And you're missing the point.

Sure.. if you had a PDP-11 or a PC running Xenix-86 available to run it on. I suppose I could fire up an emulator, but you're missing the point.

The point is that if an abstraction is going to be useful over multiple platforms (for example, LSL, and LSL with Mono) you have to expose an interface that doesn't depend on the details of the underlying implementation if it doesn't actually need to.

I am not demanding that LSL scripts be recompiled. In fact I'm recommending an interface that allows existing scripts to use SVG content without recompilation. There is NOTHING in ANYTHING I have written that even implies that ANY script ANYWHERE would need to be recompiled. Nothing.

Absolutely. I've said that myself, when I've talked about isolating the interface from the implementation... the best way to make sure that the run-time can handle the differences is by not having any part of them exposed to the "outside" environment, unless they are (a) required by that environment, or (b) required by the abstraction.

The interface to such an environment would be different from the interface to LSL, obviously. But that's ALSO something that I've already brought up.

You're exposing in the API the implementation detail that the character set of LSL is currently Unicode.

Notecards don't display in the HUD now, they display in the UI layer over[/i[ the HUD.

From: someone

An LSL script can't change the contents of a notecard, however.

So? You were complaining that LSL had to be involved at all. Now I've presented a mechanism for removing that from the equation, and you're demanding that LSL be in the loop after all?

From: someone

... Maybe if people cared a little more about how much time and work goes into design to give people that option they would understand how it feels to be treated and rudely called some "poor programmer" or likewise. ...

I don't know what you're going on about here. You asked me what I was doing to help Mono. I answered that I don't care about Mono. I don't have infinite time, and any time I spend on things I don't care about takes time away from things I do care about. That doesn't mean I'm dissing Mono or you, it just means that Mono is not something that interests me.

LSL lists allow different types. It is not fixed like a strictly type method call. The type value is stored in the list also, which can be retrieved for use.

It would be easy to change from a "string" type to another type when contained within a list. There is no need to change the interface with each different type contained within a list.



No; it is not just about appearance.

The encode type doesn't need to be exposed at all. I stated it could be automatically done in the parser. In fact, it is done that way now.

This now seems more controversial than what it should be.



The Texture dialog tab has orthogonal features with llxxxPrimitiveParams() and its implementation. An Overlay dialog tab could contain a duplicate of the Texture tab minus a few items.




Of course, there is nothing really nested within a linear memory of bits. There are ways make it appear nested, however.

You missed the point... I revised the implementation without an appearance of a nested list.

It doesn't matter - no need to get off topic about this.



If there is a need to totally seperate the two issues, then there could be seperate threads. Besides how this original thread started, I believe we all want to be able to control text on HUDS rather it is done with or without a script.

That is like the primitive editor. Nobody needs to do it only from script because the UI exists. You have a choice to do it either way.

We can continue in the the theme of the primitive editor as text on a prim focuses on similar properties.



An option for either preference is the advantage point.



This is known. I use systems that don't even expose "string" type or any other encode, which you have argued that I do. The parser is smart enough to figure it out if needed. Otherwise, the run-time figures out the rest. The objects are smart enough to figure out what other type of objects exsist as part of the same operation. However, even the instruction set underneath what the parser compiles to is quite abstracted from any useable object. LSL is no where near that abstraction level. Mono is no where near that abstraction level.

It's like you try to get me to agree to older ways of abstraction - like going back in time - when improved methods already exist. I'm not sure if you worked with a dynamic compiler. Well, if you programed at the assembly level then you have work with one that is a small finite instruction set. Some extra software completes the dynamic compiler on top of the assembly level to give a dynamic range of instructions.



You have mixed up the issues. Does it matter if it was called CONTENT_UCS or CONTENT_STRING? Right now, no. Consider how I have seen some languages envolve, the best choice is CONTENT_UCS in the long run. However, LSL might not last that long except for just backwards compatibility.



This is perception issue. It is still a 2D screen. The same appearance to attachments on the screen uses the same appearance of the rest of the user interface with the menus. You can click in your inventory and make a notecard appear. What is the difference with that being text on a prim? Its already orthogonal.

What is really wanted as discussed earlier in this thread is control of those dialogs, the textboxes and the overlay attachments sit on. It's happening. We have discussed many ways to do it.

In practice this doesn't provide the benefit you're looking for.
If you change the type to a compatible one, you don't need to change the type in the function call either. If you change the type to an incompatible one, then old code will break at runtime. If you change the type so that the list can *sometimes* have one type and *sometimes* have another type, then existing code that reads the parameters will break.

Which is precisely why the distinction you're making is irrelevant. If it's not exposed, then all your arguments about "what if you want to use something other than Unicode" are meaningless.

The Overlay dialog tab still doesn't exist. So there's no reason to wedge "SVG" and "HTML" into the same interface as plain text because "it already exists".

Also, let's get one thing straight here. I'm not saying "this shouldn't be exposed via llSetPrimitiveParams". I'm saying "llSetPrimitiveParams doesn't provide you with an interface that's semantically distinct from a separate function". You brought in the list interface because it was "more abstract", then in a later message proposed llSetPrimitiveParams. REGARDLESS of the advantages and disadvantages of the latter, it doesn't give you any more ability to change the semantics of the interface than the functional interface does.

Because, and this is what I'm trying to stay on track with, it's important that you don't mix up abstractions for unrelated concepts, and it's important that you don't expose implementation details in the abstraction, and it's important that the abstraction not limit possible implementations.

The abstraction I'm talking about is not "this function in LSL", it's "this set of parameters applied to the primitive".

This thread started (and the thread starter has confirmed this) with a request for scripted control of text on HUDs. THAT is what the thread is about.

Regardless of whether in addition a UI is provided for this (like llSetTexture) or not (like llSetTextureAnim), the abstraction has to provide the scripted control that was originally requested. NOBODY has said "this must only be done from a script".

I'm not trying to get you to "agree to older ways of abstraction". That was an example. I was providing an example of the difference between "abstraction" and the technical jargon "abstract interface". You can use an "abstract interface" to implement an abstraction, but you can also use an "abstract interface" to implement an indirect interface that exposes all the implementation details and completely fails to be anything *like* an abstraction. Things like AWT and Java Beans are full of this kind of "not an abstraction" abstract interface.

The point is not that printf is *good*, it's that defining an abstraction in terms of your (presumably) CIL-derived syntax doesn't serve any useful purpose.

Yes.
No.

If it's CONTENT_STRING, and LSL evolves "UCS string" and "ISO10646 string" types, then all programs that used CONTENT_UCS will need to be changed to use CONTENT_ISO10646. If they *don't* need to be changed, then CONTENT_UCS doesn't actually mean CONTENT_UCS.

If it's CONTENT_STRING, and LSL evolves to expose this distinction, then since as you pointed out the compiler and runtime can handle both types equivalently nothing needs to be changed.

This is why it's a bad idea to expose implementation details prematurely. They tend to lock you in to the implementation, or you later on have to say "pay no attention to the UCS bit, we didn't really mean it".

Text on a prim exists in-world. It's visible to scripts in-world, it's save as part of the attachment when you disconnect, it doesn't show up on screen shots that show HUDs. It's always in the same relative position on the screen. If you log out and log in on another computer, it's still there. If the prim is moved, the object detached, or otherwis manipulated, your scripts can tell that and react. If you click on it, your in-world focus changes, but if you click on a notecard it doesn't... but your user-interface focus changes. You can move prims around with the object editor, you can't do that with UI objects. UI objects disappear in mouselook.

Improving the ability to control UI objects is *also* worth doing, but it's not the same thing.

Sorry, it's been done and put in use. Its benifits work very well.



Not true. That would only be true in implementation that expect a predefined type from a given. If you use a new type that all implementations don't have in their known set, it'll break. However, if you implement it so that none of the implementations have a predefined set and to have a dynamic set in place of it, it continuously works just fine.



It's not meaningless. I needed you to see it from the other side, as you have started. That isn't the only point of it.



Text on a prim will basically use an overlay of some sort or another. What I presented is an abstraction for your text on a prim.

Content of the overlay shouldn't matter in the case to implement these features of Text on a HUD or whatever.

The overlay is the abstraction. Not your function.



The way I see it here, you have barely made any difference or revision in the semantics of llRenderText() to allow for other options available to give more features that every user can take advantage of to their hearts desire.

I created the abstraction - the idea of the overlay. I presented some methods to access it - some abstract and some not. You presented a method interface. I presented a way to use the overlay from your method interface. I don't understand why you still argue about it when you can have llRenderText() and a proper abstraction.



Your right. That's why I needed you to argue the other side of it, so maybe you understand this more.



The parameters of the a 3D primitive have nothing to do with LSL script. This is why I don't understand why you or anybody that has followed this thread has been so hard pressed about details strictly within LSL. You said it best, "it's important that you don't mix up abstractions for unrelated concepts."



If prims are involved, you have step outside the concept of LSL itself. It is no longer just about scripted control of LSL.

We'll have to first implement the abstraction, like the overlay, on the primitive. Then later come back and allow scripted access to those abstractions.



Agreed.



I provided many examples and used the technical jargon "abstraction" so you would understand.

OMG LOL that's silly

The words are useful but by now means are they set in stone as "the only way to speak" or the "the only way to call xyz an xyz." This I must persuade you to let loose on the terms and understand some more direct or specific terminology usage helps. Abstract words are just that... quite abstract!



Completely wrong presumption. What I work with has existed way before Java or CIL. I published some code of it about 5 years before Java ever become known about. Which was a *maybe* a mistake since I found some of my ideas assimulated into Java.



Again, I need you to see the other side of it. With an abstraction like the overlay... it doesn't really matter what content there is or how you specify it.

We can use "string" or "CONTENT_STRING" or whatever. However, just remember that the use of "string" in interfaces has been *THE MOST* vunerable cause to all major viruses or other such disasters like the e-mail virus that knocked out half the Internet in 1988.



To me, the semantics of llRenderText() or other funtion calls proposed is this kind of lock-in implementation. I'm glad you understand this point.



Um... ok