World: r3wp

(in that, there may be a different, but just as good a method to 
do it)

Can you do it, or not ?

but other than that, enabling debugging lets you see the inner workings 
of a face

http://rebol.net/wiki/GUI_howto_debug

So Ammon's example could be modified to:

	view [t: text "" debug]

yes

which dumps the face contents.

also:

view [t: text do [probe face]]

dumps the gob as well.

No, it doesn't (?)  The gob is usually returned by VIEW and molded 
by the console..

there is also whole instrumentation for debugging purposes, so ...

Anton, ah, it can't do that from a text label with nothing in it, 
of course. Try something like BUTTON instead.

Custom debugging print outs.

What if you just want to print the size of the TEXT face, for instance?

How would you do that? (Not dump the whole face.)

Say, on init.

Go to the style code and add the print there.

(note that more debug outputs can be added, if some are needed)

I have a style that displays its current size inside the View window 
at all times. Perhaps this can be added as a debugging feature.

http://rebol.hmkdesign.dk/files/r3/gui/061.png

debug: [style make] ?

http://rebol.net/wiki/GUI_howto_debug#Runtime_Debug

Modifying the style code could be quite uncomfortable, when you just 
want some information quickly. I don't want to have to mess with 
files just to print a bit of custom debug info.
More debug outputs could alleviate this discomfort somewhat.

I think it's possible to create a debug function that returns a facet 
for a given face when a given event happens, like:

get-debug 'my-face 'text-body 'on-make

Yes, you can use DO with BUTTON:

	view [t: text "hello" button do [dump-face t ]]

dumps the TEXT face when the button is clicked.

Henrik - why don't you release your DocBase resizing doc? :-)

Pekr, because I know Carl will ignore it. In fact he just posted 
something like that on rebdev.

I think that nothing is set in stone, ne? It all started with the 
lack of decomposition from gob to face, no? Maybe the system could 
keep the list of references somewhere, no? Or simply face could be 
extended with the list of gobs it is composed from?

Gobs that are the top gob for a face have a reference to the face 
in something like gob/data, as I recall.

I want to get to 't because I'm trying to hack together a GUI for 
DevBase because the console client is painful to use and I thought 
this might be a good way to introduce myself to some of the internal 
workings of the new GUI.  I want to redefine "say" in the chat.r 
to update ''t with the text it would normally print.


To have changed what VIEW returns such that I can't actually get 
to the face produced is unbelievably confusing.  There must be a 
good reason for it though, what is it? 


You do realize that if I have no way creating a pointer to a face 
then I can't use get-face, set-face, etc. on it don't you???

I'm familiar with the fact that set-words are being defined in parent-face/faces 
which is why I used window: view [...]  I thought I was going to 
be looking in window/faces to get to t but View is giving me a gob 
instead of the face that I need.

Will not it be more difficult to get to some internals anyway, once 
modules are implemented?

Yes, once modules are done certain internal things will be locked 
away but that has nothing to do with my question here.

I need a solution to a problem and that solution very well may be 
a paradigm shift on my side.  I just need to know how to interact 
with the GUI from outside the GUI code OR I need an explanation of 
why the ability to do has been removed in the latest release of R3's 
GUI.

Maybe we just were too much used to things popping up into global 
space? (I am not trying to find any excuses for possible defficiencies)

Have you looked into above pointed debug functions?

The truth is, I can hack this 1.6 billion different ways.  I DON"T 
WANT TO HACK IT!!!!!  I want to use the system how it was designed 
to be used.  Simply example hack...


view [t: text "this is a test" button "Mwahahaha!" do [set 'txt t]]

The fact I can use the set trick in a reactor means I could prolly 
do the same thing in an actor, on-make, for instance.  It's not an 
issue of not being able to hack it.  I'm not looking for a hack. 
 I can hack just fine.  I want to know how the system is SUPPOSED 
to be used.

Something I did in my code all the time with VID 2 is window: layout 
[ ... ]  then go ahead and connect/modify/abuse the window in any 
number of ways and then show it later.  I'd often set up panels this 
way so that I can have the faces built ready to switch out at the 
click of a button and this would allow me to easily keep different 
areas of the GUI in sync easily but now that Layout is gone I can't 
do it this way.  The real question here is why is view returning 
the gob instead of the face?  Seems on how I actually have the GUI 
source code sitting on my machine, I can hack this to give me what 
I want the problem is, it would be a hack which means that I can't 
hack it to give me what I want because what I want is not a hack. 
 Get it? ;-)

please post your comments to RebDev, or it will NOT get noticed by 
the author =  Carl

Noted.  I'll put together a shorter, sweeter post for RebDev.

Is there a place that teaches people how to post to RebDev in the 
first place?

Yes...

http://www.rebol.net/wiki/RebDev_Quick_Start

I would at least expect chained gob structure, so that one can traverse 
it via gob/pane, gob/parent .... it escapes my mind, why window/pane 
does not contain its subelements, but maybe the meaing is here quite 
different ...

I'm actually not seeing anything in the new GUI that allows you to 
find a given face's parent.  It's really very frustrating me...

Well...  WTF do you know?  

window: view/no-wait [t: text "this is a test"] 
set-face window/data/faces/1/names/t "Mwahahahah"
show window
do-events

I posted my reaction to rebdev chat too. I am missing some aproach 
to easily traverse gui:


- there is bog/pane, but not face/pane. There is face/faces e.g. 
for panel style. If it is the same concept, why name it differently?
- there is no face/parent-face to traverse backwards

- face/gob contains just one gob. It also seems to me, that it is 
not even a pointer to the gob, but not sure. Not sure if it would 
be usefull, but currently face can't be built from multiple unrelated 
gobs. You have to have one gob, and other ones in gob/pane

Hmm, but as you show, there is some way. But it is strange. Docs 
say, that gob/data point to face. So what is "face" actually here? 
Some special Window face? Ah, I might understand and I pointed out 
already the discrepancy. While for gobs, we use /pane, as we all 
know it from VID2, but the same concept for faces is /faces .... 
While the name is clear, I vote to rename it to /pane, to make it 
apparent it is the same thing ...

Yup. I read it.  You did a very good job of describing what's been 
annoying the hell out of me for the past 4 hours.  Hopefully we'll 
get some straight answrs to all of that.

I completely agree with you on the /faces vs. /pane issue!

Eh...  I got distracted and quit playing with the RebDev client but 
I've been making good progress on the text editor I'm writing. =D