r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3 GUI]

PeterWood
3-Apr-2011
[6967]
I was going to suggest a couple of alternatives but it is hard to 
find something that fits in with the VIEW/VID/GUI metaphors.
Ladislav
3-Apr-2011
[6968x2]
Two notes:

- update is not resize, but can provoke a resize as well

- if I call UPDATE-FACE/CONTENTS on a hpanel, then the hpanel is 
updated (row and column sizes are recalculated, the total panel size 
is recalculated), but the panels contained are not
As opposed to that, when I call UPDATE-FACE on the same hpanel, the 
row and column sizes are not recalculated, since there is no reason 
for that
PeterWood
3-Apr-2011
[6970x2]
Thanks for the explanation. You could consider:

 UPDATE-FACE/RECURSIVE (or R) which is common with cl utilities but 
 most un-REBOL like
	UPDATE-FACE/ALL - based on LOAD and SAVE metaphor
	UPDATE-FACE/CHILDREN
I'm not sure if the parent/child metaphor is appropriate in REBOL3 
GUI.
Ladislav
3-Apr-2011
[6972x3]
UPDATE-FACE/RECURSIVE
- this is a misunderstanding, as I said.


- UPDATE-FACE if always recursive, i.e. the it updates all the parents 
as well.
- UPDATE-FACE does not "recurse to children"
UPDATE-FACE/CHILDREN
 - a misunderstanding again, see above
UPDATE-FACE/ALL
 - a misunderstanding as well
PeterWood
3-Apr-2011
[6975]
I'm afraid that I'm a little lost - You said that UPDATE-FACE/CONTENTS 
called e.g. for a vpanel is equivalent to the behaviour of UPDATE-FACE 
for a face contained in the same vpanel.


To me the faces contained in vpanel can be considered children of 
the vpanel.
Ladislav
3-Apr-2011
[6976x3]
Yes, but that does not mean any children recursion, that is a parent 
recursion.
UPDATE-FACE recurses to parents.
Parent recursion means, that when I start with you, I continue with 
your parents, grandparents, etc. As opposed to that, when I do a 
child recursion, when I start with you, I continue with your children, 
grandchildren,...
PeterWood
3-Apr-2011
[6979]
That I understand. But I don't understand why you think UPDATE-FACE/CHILDREN 
would imply child recursion. For me, UPDATE-FACE/DESCENDANTS would 
imply child recursion.
Ladislav
3-Apr-2011
[6980]
aha, I was misled by the word. Now the question is, whether it will 
not confuse other people as well.
Gregg
3-Apr-2011
[6981]
I'm confused. :-)


I agree that /SIZE is a better name, and now see the problem with 
it.


What does the docstring say for the function? That is, can we approach 
it from the documentation side and see if the functionality is clear.
Ladislav
3-Apr-2011
[6982x2]
I intendedly did not want to be too much function-specific, since 
the "CONTENTS issue" is present in other function/refinement names 
as well.
and, you got me, it currently does not have a docstring (maybe it 
is too low-level, but I will definitely write something)
PeterWood
3-Apr-2011
[6984]
Personally, I think that ANCESTORS, PARENT, CHILDREN  and DESCENDANTS 
are very useful words for precisely defining relative positions in 
a heirarchy.


They do not seem to sit well with the REBOL though as firstly they 
are comparative long (and many rebollers appear to worry about having 
to type one or two extra characters) and secondly they don't really 
fit in with the existing VIEW/VID/REBOL3 GUI metaphors (which are 
more facial - FACE, GOB etc.)
Pekr
5-Apr-2011
[6985]
Any new release around the corner? This friday perhaps?
Cyphre
5-Apr-2011
[6986]
Yes, we plan to make new release this Friday. We'll post at least 
update info in case the release date is postponed from some reason.
Cyphre
8-Apr-2011
[6987]
update info: the new R3GUI release has been postponed to Monday (we 
want to solve few remaining issues to deliver more stable version) 
so stay tuned..
Cyphre
11-Apr-2011
[6988]
update: we are still working on last changes for this release...should 
be released tommorow.
Pekr
13-Apr-2011
[6989x2]
Cyphre - detailed log is not updated as announced,the last items 
are dated 18.3.?
nice to see,that even View core gets updated.Thank you very much 
for improving keyboard handler!
Henrik
13-Apr-2011
[6991]
Posted change log privately to Pekr.
Pekr
13-Apr-2011
[6992]
ok, thanks ...
Henrik
13-Apr-2011
[6993]
it'll be up on the site, once Robert gets around to it. I just didn't 
want to spam this group with a list.
Pekr
13-Apr-2011
[6994x2]
report towards panel #32 - make the window so large, that on Y axis 
(vertical), the scroller is 100%. Then try to move the scroller (or 
press its arrow). The panel jumps in a strange way?
the same goes for horizontal axis. So the easiest way to reproduce 
it is to just maximize the window ...
Rebolek
13-Apr-2011
[6996]
It's known problem.
Pekr
13-Apr-2011
[6997]
ok
Henrik
13-Apr-2011
[6998]
Pekr, one thing you can check for me: Run all-styles.r3 and look 
at the FIELD style: When swiping (holding down the left button and 
dragging from left to right to mark up text) very slowly, start at 
the left 'F', the text is marked up ok, until reaching the last letter. 
Then the marking disappears momentarily and comes back when passing 
by the last letter. Can you replicate this?
Pekr
13-Apr-2011
[6999x2]
I just got crash, when clicking into the field, R3 vanished.I will 
try with new session.
Henrik, other than that, marking the text is really buggy. Here's 
few things RMA needs to look into:


- go to the area, type enough text, sot  that it scrolls, and then:

        - when you are at the bottom of the area, just press shift + up arrow, 
        to hilite the text - only one line is hilited -  the alghoritm is 
        buggy

        - go to the top. Try the reverse - shift + down arrow - it hilites 
        the text correctly, unless you hit bottom, then it starts to hilite 
        from the beginning, and cycles forever. It should just stop at the 
        bottom


- the most troublesome behaviour though is, that when you move out 
from the bounds of the style, it stops hilighting. Simply an event 
flow is bad here. We should treat it like pop-up menus - receiving 
events even if outside of the window, while in mouse-down mode. That 
is absolutly needed, or the experience is highly uncomfortable - 
just try to hilite the field - once your mose goes away, it stops 
the hilite. That might be the reason why you think it is slow ...
Henrik
13-Apr-2011
[7001]
OK, thanks. I think there will be one big session where general text 
handling is going to be fixed. Probably somewhere when rich text 
editing is going to be done.
Cyphre
13-Apr-2011
[7002]
yes, the current text editting/selection code is still from the old 
'carls version'. Review is planned.
Claude
13-Apr-2011
[7003]
henrik i confirm the bug on the text selection
Henrik
13-Apr-2011
[7004]
thanks, Claude
Pekr
15-Apr-2011
[7005]
I just want to ask - as you did some nice improvements in the View 
kernel, will it be "backported" (?) into RT's branch of source code? 
Is there any communication with Carl even for RMA's purposes?
Robert
15-Apr-2011
[7006x2]
backport: I don't know.
Carl: No, silence at the moment. We are waiting too.
Ladislav
15-Apr-2011
[7008x2]
'will it be "backported" (?) into RT's branch of source code?' - 
As was announced, the RT's branch of source code is currently managed 
by RMA, and ported to keep being compatible with the new hostkit 
updates. What exactly is "backport"?
Do you want us to spend any effort on trying to backport the code 
to be runnable in the older hostkit?
Henrik
15-Apr-2011
[7010]
perhaps the correct term is "merged into Carl's source tree".
Pekr
15-Apr-2011
[7011]
yes, merged, sorry. Simply put that when Carl reappears, and starts 
eventually to proceed with RT's releases, to not find ourselve in 
a situation, when Carl uses old and different hostkit View sources 
...
Ladislav
15-Apr-2011
[7012]
Carl *is* merging the hostkit changes
Pekr
15-Apr-2011
[7013]
ok, good to hear that ...
Ladislav
21-Apr-2011
[7014x2]
Please, check the http://www.rebol.net/wiki/R3_GUI_terminologyarticle. 
I hope, that is describes some of the terminological issues we are 
trying to solve.
User poll questions:


1) Do you find the 'a layout' and 'layout style' notions to improve 
the current 'a panel' ambiguous terminogy, or do you prefer something 
else?

2) Which of the three [[hpanel vpanel] [panel vpanel] [panel panel 
vertical]] alternatives do you prefer?
GrahamC
21-Apr-2011
[7016]
2-2