On Thu, Feb 15, 2007 at 06:25:41PM -0500, Mike Caron wrote:
> On 2/15/07, Bob the Hamster <[EMAIL PROTECTED]> wrote:
> > On Thu, Feb 15, 2007 at 06:11:01PM -0500, Mike Caron wrote:
> > > On 2/15/07, S'orlok Reaves <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > > Technically, this makes these features available
> > > > > to plotscripting strings, but to use them, you'd
> > > > > need to embed those characters directly into the
> > > > > plotscript file, which while doable, isn't very
> > > > > convenient. Or, you can use append ascii.... More
> > > > > thought on this is required.
> > > >
> > > > You could always invent your own markup. Like, "\n"
> > > > for newline, then "\c5{some string} some other string"
> > > > to make "some string" be the fifth color, and "some
> > > > other string" be the default.
> > >
> > > I have every intention to support codes like this, but not until I
> > > rewrite the textbox code :)
> > >
> > > The reason is this:
> > >
> > > Textboxes are, essentially, 8 strings displayed on top of eachother.
> > > Each string is limited to 40 characters by the very format they're
> > > stored in, since long before any type of code was possible. This means
> > > that any code embedded in the textbox takes up display character
> > > space. In other words, lets say you have a textbox in which Bob talks.
> > > Bob is, of course, customizable, so you use a code to sub in his name:
> > >
> > > "${H_}: Hello there, my friends and such!"
> > >
> > > That is exactly 40 characters. If the default name is "Bob", then this
> > > means that it will only take up 38 characters, leaving two wasted!
> > > Conversely, if the name is "Pedrovich" (shh), the string balloons to a
> > > massive 44 characters, and part of it is cut off.
> > >
> > > The solution is word wrapping, but this is not possible due to the
> > > "seprate strings" analogy. If you were to combine it into a single
> > > string (gluing it together with \n), then you get a different problem:
> > >
> > > "Pedrovich: Hello there, my friends and\n
> > > such!\n
> > > This is a fine day, is it not?"
> > >
> > > Obviously, if that hard line break after "such" was removed, this
> > > would work properly. But, we can't assume it isn't a hard break,
> > > because there are situations where it is (I assume you can think of
> > > one yourself).
> > >
> > > What to do? Well, first off, kill the 8-strings paradigm, and make a
> > > textbox one big string. Then, change the editor so that the user can
> > > just type, and it word wraps for them, and inserts hard line breaks
> > > when they hit enter, instead of after every physical line. Then,
> > > everything works nicely.
> >
> > Backcompat for old text boxes will not be that easy. We can't assume
> > that existing text-boxes will look the same when treated as a long
> > wrapping string.
>
> We can if we assume existing textboxes ARE glued together with \n. In
> other words, if we circumvent the wordwrapping by feeding it lines
> that are already 40-chars (or, disable it somehow for old boxes), then
> they will look the same.
Hmmm... so if we just insert a \n at the end of each line when
converting old text boxes to the new format, it will work as expected,
unless there is a ${} code in the line that would cause it to wrap.
The old behaviour for such lines is to let the string get cut off on the
right... but not supporting that behaviour doesn't seem like a
disaster...
What about box sizing? Would a line wrap trigger an increase in the box
height?
---
Bob the Hamster
_______________________________________________
ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
