Hi Pascal,

On Thu, Nov 07, 2002 at 03:07:08PM +0100, Pascal Bauermeister wrote:
> Hello Chuck,
> 
> I investigated a bit on correcting the tab bug by modifying
> textedit_str_size() as follows:
> 
>         void textedit_str_size ( struct widget *self,
>                          TEXTEDIT_UCHAR * txt,
>                          size_t len,
>   ==>                    s16 xpos,
>                          s16 * w,
>                          s16 * h ) {
>         ...
>         if (ch == '\t') {
>             p.x = 0;
>             DATA->fd->lib->measure_char(DATA->fd,&p,' ',0);
>   ==>       *w += p.x;
>   ==>       *w += ( *w + xpos ) % ( p.x * 8 );
>         } else if (ch != '\n') {
>         ...
> 
> where xpos is the starting horizontal absolute position of the text.
> There are a few other places to modify, in order to transmit xpos. I did
> not have time to get it completely working.

Just to clarify the problem for other people on the list -- the question
is how to allow tab to be a fixed location (e.g. every 25 pixels from
left edge) rather than a fixed width (e.g. tab = 4 spaces), preferably
as a user option.

The str size method could report tabs to be whatever width was correct
for the string position, provided the string draw method also correctly
deal with tabs. The problem is that the textedit design assumes that
string widths don't change unless there is an
insert/delete/concat/split operation on an atom; if the size of a tab
varies by the actual position of a string in the line, you will have to 
recalculate atom widths for each atom after a changed atom in the same
line. Not that hard, but does add a little expense to basic operations. 
By letting tab handling be done at the string size/draw level, we
address (1) and (2) below, I think.

I don't think (3) is a problem; if a string were "my text\tnext line",
and the screen cut off at the right edge of the "t", we would wrap it as:

"my text\t" <- wrap here; at right edge
"next line"

...and we wouldn't worry about displaying the tab character whitespace
anyways (rule: if single char of whitespace extends beyond right edge of
wrapping line, do not draw whitespace. Draw cursor at start of next
line).

if the string were "my text \t next line", we would wrap it as:
"my text " <- wrap here
"\tnext line"

Hope that helps,

Chuck

>      1. xpos must be transmitted to several other functions
>      2. I sometimes found difficult to determine the absolute position,
>         since calculation of text lengths are mostly done in a relative
>         way
>      3. If the tab is near to the widget border, it could lead to an
>         incorrect wrapping of the following word and/or the preceding
>         word
> 
> Micah, I haven't yet examined the in detail the textbox widget, but
> AFAIK it just replaces tab by a space. Is the horizontal text position
> easily available when measure_char() is used ?
> 
> 
> Greetings,
> 
>   Pascal
> 


-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/pgui-devel

Reply via email to