Bug in Area
[1/24] from: ptretter::charter::net at: 20-Oct-2001 8:10
I think I found a bug when using 'area. The problem seems to be when you clear text
from the 'area and you get some garbage that remains. Any ideas of a workaround?
Paul Tretter
[2/24] from: hijim:pronet at: 20-Oct-2001 8:05
my-area/text: ""
my-area/line-list: none
show my-area
Paul Tretter wrote:
[3/24] from: ptretter:charter at: 20-Oct-2001 10:18
What is that refinement controlling?
Paul Tretter
----- Original Message -----
From: "Jim Clatfelter" <[hijim--pronet--net]>
To: <[rebol-list--rebol--com]>
Sent: Saturday, October 20, 2001 10:05 AM
Subject: [REBOL] Re: Bug in Area
> my-area/text: ""
> my-area/line-list: none
> show my-area
>
> Paul Tretter wrote:
>
> > I think I found a bug when using 'area. The problem seems to be when
you clear text from the 'area and you get some garbage that remains. Any
ideas of a workaround?
[4/24] from: greggirwin:mindspring at: 20-Oct-2001 12:14
Hi Paul,
<< I think I found a bug when using 'area. The problem seems to be when
you clear text from the 'area and you get some garbage that remains. Any
ideas of a workaround? >>
I've seen that behavior in something I'm working on, but I thought it was me
getting back some wierd data or something. I haven't investigated it yet
though.
--Gregg
[5/24] from: greggirwin:mindspring at: 20-Oct-2001 12:10
Hi Paul,
<< What is that refinement controlling? >>
line-list isn't a refinement. Here's what the View docs say about it:
line-list A BLOCK that is used to track the offsets of text lines when text
is being displayed. When more than 200 characters of text are being
displayed, this list should be set to NONE when large changes are made to
the text. This allows REBOL to recalculate the locations of all TEXT lines.
--Gregg
[6/24] from: ptretter:charter at: 20-Oct-2001 13:37
Here is another issue that sometimes when pasting data into an 'area, the
data doesn't display until you arrow your way to the top of the data.
Paul Tretter
[7/24] from: ptretter:charter at: 20-Oct-2001 13:40
I can recreate the problem very easily in my application by pasting a large
amount of data and then clearing the data - doing a 'show and pasting again
etc... Eventually, you can see it if you arrow your way to the top of the
'area view. However, when checking for the text in 'area/text, it doesn't
exist after its been cleared but still remains on the area view window.
Paul Tretter
[8/24] from: ammonjohnson:yah:oo at: 22-Oct-2001 22:32
No, it seems to be a bug. It has been discussed on the list several times.
Enjoy!!
Ammon
[9/24] from: greggirwin:mindspring at: 1-Nov-2001 16:30
Hi Paul,
RE: garbage in area.
I found my problem, though I don't know if it will solve yours. I was not
updating the line-list property of my area (i.e. line-list: none) in a
ceratin execution path. Adding that cleared it up for me.
--Gregg
[10/24] from: ammonjohnson::yahoo at: 1-Nov-2001 18:07
Aha! There's the culprit!
Thanks!!
Ammon
[11/24] from: ptretter:charter at: 1-Nov-2001 18:42
Actually, what I noticed is that if I put a substantial amount of data in
the 'area field then clear the data and probe the "/line-list", I get a
block with the word none several times such as [none none none none none
none ....] but if the data is not very large that is pasted, I just get
none
. So what is getting pasted and why?
Paul Tretter
[12/24] from: ptretter:charter at: 1-Nov-2001 18:46
I forgot to add that the line-list: none does fix the problem however. I
just wanted to know more about it.
Paul Tretter
[13/24] from: greggirwin:mindspring at: 1-Nov-2001 18:14
Hi Paul,
<< Actually, what I noticed is that if I put a substantial amount of data in
the 'area field then clear the data and probe the "/line-list", I get a
block with the word none several times such as [none none none none none
none ....] but if the data is not very large that is pasted, I just get
none
. So what is getting pasted and why? >>
That's a good question. I think there is a bug in there (i.e. we shouldn't
have to manually clear the line-list when we update the text). Someone from
RT will have to speak to what it's returning. It stores offsets to line
breaks in the text, but if it's returning other stuff, when the text is
no longer valid, that's a big problem.
--Gregg
[14/24] from: brett:codeconscious at: 2-Nov-2001 15:51
Excuse the butt in on this thread. I was drawn by the "big problem" phrase
;-)
No major disagreements from me, but I don't think it is a bug. Perhaps just
a design issue or choice.
I performed the following
write clipboard:// mold get in ctx-text 'edit-text
I believe edit-text is the function that handles quite a bit of the text
manipulationbehaviour of VID.
Here's an except from that:
paste-text [
delete-selected-text
face/line-list: none
face/dirty?: true
view*/caret: insert view*/caret read clipboard://
]
This is obviously the bit of code that handles a paste operation. As you can
see, the line-list is deliberately cleared. Also a dirty flag is set. I've
no idea what parts of View or Vid use these two variables, but if VID is
doing it perhaps you should too.
For me, reflecting on this little bit of code, I'd say that VID does not
have some support for programmers to update VID elements programmatically.
An example of support might be an "update" function on the face that when
called by a programmer would do all the necessary housekeeping for the VID
element. VID has focus. It targets a specific need. VID I think is meant as
a simple yet expressive way to create graphical interfaces quickly and as a
showoff for dialects. Not as a complete programmer level framework. The
needs of some programmers goes beyond what VID provides.
You could create your own type of GUI dialect instead of using VID (haven't
seen one yet ;-) ).
However, VID does so damn well, why would a programmer ignore all that
wonderful functionality?
The good news is you can drop to a lower level when needed.
I think that at the moment, if a programmer needs to do more than VID gives
then the onus is on the programmer to learn how VID has been created using
the view machinery and to work within that system. Knowing that it may
change especially if these sorts of issues are pointed out as being
important for using Rebol (a good thing).
No doubt, if necessary VID's target could be readjusted by RT and I believe
they intend more work on it too.
Sorry about the ramble. Just wanted to put out a possible context for these
types of discussions.
BTW,
My road to edit-text started with these two lines at the console:
layout [a: area "test"]
print mold get in a/feel 'engage
Brett.
[15/24] from: james:mustard at: 2-Nov-2001 18:55
> I believe edit-text is the function that handles quite a bit of the text
> manipulationbehaviour of VID.
I discovered the wonders of dumping VID out to text - re-writing edit-text
to do what i wanted then just calling it back in with a do %edit-text.r
This enabled me to add context sensitive popups, ctrl+insert/copy, shift +
insert/paste, shift + delete/cut - i never got into the habit of using
microsoft's little ctrl + x c v buttons), tab without that evil focus change
for areas etc.
James
[16/24] from: nitsch-lists:netcologne at: 2-Nov-2001 7:19
RE: [REBOL] Re: Bug in Area
[brett--codeconscious--com] wrote:
> Excuse the butt in on this thread. I was drawn by the "big problem" phrase
> ;-)
<<quoted lines omitted: 15>>
> no idea what parts of View or Vid use these two variables, but if VID is
> doing it perhaps you should too.
i think face/line-list is a cache.
if /view has to redraw the screen, it wants to know the part that is visible.
if text is very long, calculating that can took time.
think for example of using the scrollbar, redrawing occurs often.
so the last calculation is stored, and the next drawings rely on this.
if you change the text, recalculation is needed and view informed
by [line-list: none].
with short texts recalculation is fast, so there is no need to
use line-list.
once i have read, its used > 200 chars.
face/dirty? is set if you change the text.
so you can check
if face/dirty?[confirm "really exiting without saving?"]
inbuild editor uses that for example.
> For me, reflecting on this little bit of code, I'd say that VID does not
> have some support for programmers to update VID elements programmatically.
<<quoted lines omitted: 4>>
> showoff for dialects. Not as a complete programmer level framework. The
> needs of some programmers goes beyond what VID provides.
opposition! ;-)
view has your update in a way, but not that obvious.
with view one sets some state-variables,
which are then evaluated by show.
this is from button/feel:
redraw: func [face act pos /local state][
face/edge/effect: pick [ibevel bevel] face/state
if face/texts [face/text: face/texts/1]
all [face/state face/texts face/text: any [face/texts/2 face/texts/1]]
state: either not face/state [face/blinker] [true]
if face/colors [face/color: pick face/colors not state]
if face/effects [face/effect: pick face/effects not state]
]
'redraw is called by show, just before painting.
you see that it updates the show-related stuff based on
other variables, like
face/edge/effect: pick [ibevel bevel] face/state
where effect is set based on face/state.
the usual "update" triggers a lot of action
by each change of a face-property.
in rebol one can change various properties
and action starts in the last possible moment, only one.
more efficient and easier to track,
but sometimes more code.
i like it more :-)
-Volker
[17/24] from: media:quazart at: 2-Nov-2001 8:26
----- Original Message -----
From: "Brett Handley" <[brett--codeconscious--com]>
To: <[rebol-list--rebol--com]>
Sent: Thursday, November 01, 2001 11:51 PM
Subject: [REBOL] Re: Bug in Area
[snip]
> VID I think is meant as
> a simple yet expressive way to create graphical interfaces quickly and as
a
> showoff for dialects. Not as a complete programmer level framework. The
> needs of some programmers goes beyond what VID provides.
yep, I hit the wall trying to do interactive stuff... VID and view are
pretty hard to integrate without knowing how view really works... once you
do, though, you realize that's its sometimes less work using just view! but
I still do use VID for the general layout and then insert direct view faces
in the panes of that layout...
> You could create your own type of GUI dialect instead of using VID
(haven't
> seen one yet ;-) ).
just wait and see :-)
Glass is on its way... I have kept it secret so far, but I just had to butt
in... Its so hard to keep exciting things secret... It will use a different
dialect than VID (although somewhat similar) and will also be an exciting
thing to use for those of us who wish to do custom gadgets... some features
include :
-parameter inheritance and re-defineable dialect templates. So each type of
gadget can have its own customized interface within the same layout block.
Although this might sound like a problem it makes the usage of the dialect a
little easier... for example you can change what a string type! does by
default ... the string data might only be used for a dynamic attribute, so
you don't really want it to be put in the /text field... this allows you to
store that string where you want and use it like you want afterwards.
-The parameters are also counted so that you may supply several arguments of
the same type and detect if you wish to use the second one (or nth one), for
example, for a different thing...
-parameter context switching within the dialect parser (similar to saying
origin
in a VID layout so that the next pair be evaluated not as a size
but as an offset...).
-dynamic ui: once the layout is built, it is also running dynamically so
that the whole interface can be resized / changed in run-time and everything
compensates...
-row-column: paradigm, with differing levels of "elasticity" (static, follow
or initiate).
-eventual support for VID layouts... via a special static vid class...
-on-the-fly styling in dialect.
-dynamic toolboxes (define once, re-use at will, link at run-time!)
-on-the-fly support for an external (end-user-buildable) skin file.
-and other even more powerfull features...(I have to limit expectations a
bit ;-)
I hope everything will find its way in the release although some of these
are already planned for the second version of glass.
Its still alpha (of course) but its moving along smoothly. :-) the
inheriting dialect parser is finished. the dynamic layout engine works in
one direction already (once the algorithm is fully functional, I'll just
need to copy/paste it to handle vertical alignment)... and I already have
one beta tester who thinks my work is worth the effort I'm putting into it
:-).
> However, VID does so damn well, why would a programmer ignore all that
> wonderful functionality?
VID IS good. and even with glass I will still use it.
> The good news is you can drop to a lower level when needed.
> I think that at the moment, if a programmer needs to do more than VID
gives
> then the onus is on the programmer to learn how VID has been created using
> the view machinery and to work within that system.
And its pretty easy to learn... it took me about a week to figure out the
grand scheme of things... but I'm still finding out new details all the
time...
source and probe are my best friends... especially the "probe first face"
line which I still put here and there when trying out new stuff ;-)
hope I've sparked interest :-)
salut!
-MAx
[18/24] from: brett:codeconscious at: 3-Nov-2001 0:43
Hi Volker,
> i think face/line-list is a cache.
Yes I think that is most likely, and for the reasons you give.
> face/dirty? is set if you change the text.
Remember, the Rebol/View Develop Guide says of VID:
RVDG> VID is implemented as a layer that rides on top of the REBOL/View
graphical compositing system.
I could be wrong but I think the dirty? flag is part of the VID layer not
the lower level View faces. I figure that if I'm using the VID layer and I
do something it doesn't know about, then I should work to ensure that VID is
in a consitent state when I'm finished. For ordinary uses of VID there is no
issue.
> if face/dirty?[confirm "really exiting without saving?"]
> inbuild editor uses that for example.
Mostly true, but I've documented a minor case where it fails. This happens
to be a case where the VID layer doesn't pick up a situation that sometimes
can be classed as being a dirty state. [Gee this language is bizarre :) ]
> opposition! ;-)
> view has your update in a way, but not that obvious.
Maybe you misunderstand me :)
My "update" suggestion refers to keeping the state variables consistent -
not changing the lean behaviour of the compositing engine or anything more.
Gregg, Paul and Ammon I think have shown that it is fairly easy to cause an
area to go a bit haywire. Remember Gregg said:
GI> I think there is a bug in there (i.e. we shouldn't
GI> have to manually clear the line-list when we update the text).
I must admit I thought that the line-list was part of the VID layer. Now I'm
not so sure. I have to agree with Gregg that manually clearning the
line-list seems odd. Though I think for performance the programmer should
have some way to tell the engine to recalculate the cache when he/she has
finished manipulating the text. For example you might be inserting text all
over the place in a large body of text - calculating on each modification
may be expensive. Calling a function rather than clearing the field seemed
more natural to me.
<snip redraw description>
> in rebol one can change various properties
> and action starts in the last possible moment, only one.
> more efficient and easier to track,
> but sometimes more code.
> i like it more :-)
I like the View compositing engine and VID too, though some tweaking might
be useful to make them more programmer friendly. :-)
Brett.
[19/24] from: brett:codeconscious at: 3-Nov-2001 0:54
Hi Max,
Wow! Looks ambitious.
I'm glad I accidently provoked you to give up your exciting secret. :)
I'm sure you're going to generate a lot of interest with that - I can't
wait!
Good luck with your project.
Brett.
[20/24] from: media:quazart at: 2-Nov-2001 9:31
----- Original Message -----
From: "Brett Handley" <[brett--codeconscious--com]>
To: <[rebol-list--rebol--com]>
Sent: Friday, November 02, 2001 8:43 AM
Subject: [REBOL] Re: Bug in Area
Hi Brett,
> I must admit I thought that the line-list was part of the VID layer. Now
I'm
> not so sure. I have to agree with Gregg that manually clearning the
> line-list seems odd.
this strangely resembles a cache-coherency thing... when multiple different
things access the same information and there have been changes to that
cached information... its better to clear the cache and not rely on it.
because the others might not be aware of it. This is why the system only
uses the cached information if its still there...
on another note... cache improves speed only when the data remains pretty
static. If you expect to change the lines and recalculate the line list
with every redraw iteration, you'll actually be slowing down refresh A LOT!
my view is that all of this is ok (a part for the bug). There isn't much of
another way to do it... without heavily affecting performance...
> Though I think for performance the programmer should
> have some way to tell the engine to recalculate the cache when he/she has
> finished manipulating the text. For example you might be inserting text
all
> over the place in a large body of text - calculating on each modification
> may be expensive. Calling a function rather than clearing the field
seemed
> more natural to me.
But doesn't it redraws/recalculates only once for all modifications which
you AND others might have performed within the last redraw by re-calculating
it just before drawing?
-MAx
[21/24] from: media:quazart at: 2-Nov-2001 9:35
Hi Brett,
thanks,
Yes, its going to be a lot of work ( it already is actually ;-) ... But
then, I've doing this kind of ui stuff for 10 years now, so I'm pretty keen
on where I'm going.
the current part of the system took me two 8-hours days to code... I'm
pretty sure a first (un-featured) beta should go on-line within two weeks...
just to give you guys (and gals?) an idea of how it will all work!
hoping everything goes smoothly,
-MAx
[22/24] from: greggirwin:mindspring at: 2-Nov-2001 13:01
Hi Brett,
<< Though I think for performance the programmer should have some way to
tell the engine to recalculate the cache when he/she has finished
manipulating the text. >>
There are always lots of ways to look at things. I'm all for performance,
but I'm even more in favor of correctness. :)
In this case, you would see garbage in the area when you set the text to "".
That should be a pretty easy case to handle but I haven't seen how you would
trap
the changing of a value in an object. I.e. if I'm an area object, I
don't get an "event" when someone changes my text value. So, you have to
write a function (set-text) that is used for this.
Another example can be seen in text-lists. If I load a list with data, then
select an item, it is highlighted. Now, I clear the list so it is empty. Now
I load it again. If it now contains an item which matches the *original*
selected item, it gets highlighted. I.e. it didn't clear the picked value
when I cleared the list. Bug or feature? :) Where I see it right now, in my
app, it's actually kind of a neat feature but it wasn't intended that way.
Scroll bars are also problematic at times. Is there a *definitive* example
for how to set the thumb size, link them to another control, and reset them
to their default/minimum value? Lots of examples, lots of different
approaches. Should /redrag do it all for us? Does it currently?
I don't mean to gripe. These are really niggling little things that we *can*
solve because of the way REBOL, View, and VID are built. Hopefully RT will
make note of the issues that crop up for us and either address them
internally or write a definitive FAQ for them.
--Gregg
[23/24] from: brett:codeconscious at: 3-Nov-2001 10:31
Ugh... Yes probably. Just ignore my comment - I should have been in bed :)
Note to self: "Beware the email sent after 10pm"....
Brett.
[24/24] from: nitsch-lists:netcologne at: 3-Nov-2001 3:46
RE: [REBOL] Re: Bug in Area
Hi Brett
[brett--codeconscious--com] wrote:
> Hi Volker,
> > i think face/line-list is a cache.
<<quoted lines omitted: 18>>
> My "update" suggestion refers to keeping the state variables consistent -
> not changing the lean behaviour of the compositing engine or anything more.
i hope i had understand you ;-)
if i want to change a face, i call its update with appropriate parameters.
in other systems, this parameters are given the usual way: update x y z .
in rebol we set parameters in the face. then call show.
so state-variables are the parameters.
> Gregg, Paul and Ammon I think have shown that it is fairly easy to cause an
> area to go a bit haywire. Remember Gregg said:
>
> GI> I think there is a bug in there (i.e. we shouldn't
> GI> have to manually clear the line-list when we update the text).
>
it may be automatic in some releases.
Not by a function, but because of 'query .
that would allow 'redraw to check if the text has changed.
unfortunally only one function should clear this flag,
but show/redraw would be a good place for it?
today, for fields (one line, <200chars) i can avoid it
and for areas i do it allways. simple rule.
maybe the name could be more obvious,
face/text-analysed: none or that?
> I must admit I thought that the line-list was part of the VID layer. Now I'm
> not so sure. I have to agree with Gregg that manually clearning the
<<quoted lines omitted: 4>>
> may be expensive. Calling a function rather than clearing the field seemed
> more natural to me.
me to first. after a while i got the view-way:
tell all you want and then call a function to process
that (like show).
> <snip redraw description>
> > in rebol one can change various properties
<<quoted lines omitted: 5>>
> be useful to make them more programmer friendly. :-)
> Brett.
-Volker
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted