Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

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:y:ahoo 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:yah:oo 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