AltME groups: search

That's the old (Carl's) GUI version which is causing confusion now 
as it does not work anymore.

Shadwolf: {If I had better relation with Robert and RM-Asset I could 
have updated MDP-GUI the only browser of MakeDoc Pro documentation 
made  in rebol/vid 2. :)} - interesting, what exactly it is you announced, 
then?

This one
http://www.rm-asset.com/code/level1/r3-gui/gui-panels/

Also consider changing the page heirarchy: Clicking "Code" then "Level-1" 
then "R3-GUI Library" then "GUI Panels" is not very intuitive.

Thank you all for providing the r3 gui code. Pretty nice stuff.

Jocko .. load-gui works I think

Yes, it works with the RMA build, but my tests are to check the level 
of compatibility with the standard r3 build, and, to that respect, 
I need to replace the load-gui by a do %r3-gui.r3. (At least, I suppose, 
I have not checked)

Only our version of R3 loads our version of R3-GUI

About disreb: Sorry to be unclear originally. At the moment, it's 
R2 only (I'm currently sticking with the latest version of R2 because 
I understand that it has a more stable GUI), however I am very willing 
to incorporate changes for R3. I'm not yet sure what the best fashion 
of collaboration with the Google code site is, but hopefully I'll 
have some time to investigate tomorrow. Sorry for the late reply, 
but I have imperfect access to AltMe (it's firewalled at work and 
I forgot my password (ha!) so I don't have it working on the computer 
I'm programming disreb with). @Oldes, I hope you find it useful should 
you chance to use it! Thanks!

Moving to REBOL3 GUI...

Robert, code, including gui's,  created by other code and then executed, 
is a great feature of Rebol.

Robert - thanks a lot, I really enjoyed run-tests.r3 demo, watching 
how GUI moves around in an automated fashion :-)

For discussion of the R3 GUI (which doesn't have a name yet).

The current non-host-kit builds of R3 can use the current GUI, with 
some bugs. Carl has a new resize model that he hasn't implemented 
yet. The GUI has been put on hold until after the first full R3 release. 
The R3 beta won't support or require a GUI.

BrianH: there are more changes planned, no? Like adding layers, etc. 
Henrik summed it up somewhere, maybe he can repost. And as far as 
I remember - the changes might influence your code, so I am not sure 
if it is good to do any GUI related work in recent VID state ...

Is there a tutorial on using the ??? gui ?

BrianH: I will not argue, I just don't know ... we need Henrik to 
post conscise list - he has it somewhere. If GUI would be useable, 
Henrik would not stop his work :-)

Top link for R3 Gui is for Syllable!

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

Something will happen here possibly in February to April, but I need 
to finish another project first. Things will be slightly different 
than originally, because I want to take advantage of some techniques 
used in the VID Extension Kit for face navigation, keyboard navigation, 
etc. Not doing work on the GUI has largely been because of announced 
changes not yet implemented, and also having lots of work elsewhere, 
fortunately almost all REBOL related.

I just found Henrik's summary. I think it is the post I had in mind:
---------------------------------------------

Indeed VID3.4 is far from done. You can probably use it for a few 
things, like getting a name from a user in a text field or submit 
a very simple form, but not much more than that. To reiterate the 
state of the UI:

- No unicode yet in graphics (when Cyphre gets around to it).
- Resizing acts like a drunken sailor. (Carl)
- Skin is not published. (Me)
- Style tagging is not implemented. (Carl)
- Reasonable requesters are not yet implemented. (Carl or me)
- Layers are not yet implemented. (Carl)
- Guides are not yet implemented. (Carl)

- Better font rendering. We are not taking advantage of what AGG 
can do. (Cyphre again)
- Event system is from Gabriele's VID3. (Carl)
- Many features are untested, like drag&drop. (Me, I guess)
- Proper material management for skin. (Me).
- Many styles are not implemented, especially lists (Me).
- More elaborate animation engine (Carl or Me).
- Form dialect (Carl talked about this).
- More/better icon artwork (Me).


Plus, Maxim has some ideas for DRAW, to greatly speed up rendering, 
but I don't know if they can be implemented.


The overall design of the GUI engine is very good. Whenever a change 
or addition is made, you alter 3-5 lines of code in one place, and 
it works. I doubt the entire engine will be rewritten.


You won't see GUI bug reports in Curecode for a while. There could 
easily be 2-300 reports, once we get to that point.


My work regarding skins is rather big: I need to work out the basic 
styles first, so we have a reasonable way to build compound styles. 
These are being done using a very simple, but pixel accurate GUI 
using plain colored surfaces. This is easier for testing out, as 
draw blocks are small, but as Pekr likes to complain: They are not 
pretty to look at. Once the real skin goes into place, the draw blocks 
will grow a lot.


I would love to see a low-level GOB management dialect, like Gabriele's 
MakeGOB.

Can't wait for when we get back to GUI :-) Hopefully Carl is back 
to Host Kit soon, so that View will be adapted to command! interface, 
and its source released, in order for Cyphre to proceed ...

Pekr, you forgot animated effects on every place of the GUI and 3D 
GUI ;-)

I realize the GUI is still a WIP ... but is the underlying [native] 
gob! system settled? (i.e. is it likely that the details of http://www.rebol.net/wiki/GOB
will change?).

Good. That means the building blocks are in place for those who want 
to experiment with Gob-based GUI's ;)

The way I see it, there are at least four ways to build an R3 GUI 
[based on gobs]:


1) Heirarchical, where gobs are grouped into faces, which are in 
turn grouped into windows

2) Flat, where a DOM-like object maps all gobs (i.e. removes the 
need for intermediate faces/windows)

3) Draw-based, where each window consists of a single gob with the 
entire window rendered in a draw block

4) Image-based, similar, but the draw block is pre-rendered into 
an image.

Getting a window plus event handler up and running only using View 
(no load-gui) is pretty simple. The code, for those interested, is:

	system/view/event-port: open [scheme: 'event]

 system/view/event-port/awake: make function! [[event][print event/type]]
	f: make system/standard/font [size: 36]

 d: make gob! [text: "Title" offset: 50x50 size: 300x200 flags: [resize]]
	append d make gob! [text: [font f "Text"]]
	append system/view/screen-gob d
	show system/view/screen-gob
	wait system/view/event-port

What sort of widgets do we actually have so far in the GUI ?

graham, if you have an account to the r3-gui world, there is a list 
in there

R3 gui is supposed to be easier to code for than VID isn't it ?

I don't know anything about the intricasies of GUI programming ....

I have noticed some instability.  If you halt from a GUI script and 
then try and close it ... r3alpha crashes

Hmm.. no messages in GUI in R3 chat for this year

My first gui script http://rebol.wik.is/Rebol3/R3_GUI/Sendfax.r


I'd like to have the output from net-log appearing in the area .. 
but I can only get it do that once  and then nothing ...

I wrote this to try and update the area with network trace

			set 'net-log funct [  txt /c /s][
				data: rejoin [ get-face a1 newline txt ]
				if c [ data: join "c: " data ]
				if s [ data: join "s: " data ]
				set-face a1 data
				set-face/field a1 tail get-face a1 'locate 
				wait .1 ; update gui
				txt
			]

As we still have the chance to make some changes to R3 GUI, I would 
like to get the opinion of the community for this idea: R3 is designed 
for development-in-the-large, this means modularity is key.


IMO a GUI system where widgets just send messages and where I can 
register handlers for a widget-name/mesage combination would help 
a lot.


Such a system could call several handlers in a chain, it could be 
re-configured at run-time, etc. Further I think a concept like a 
(virtual-) finite-state-machine can help a lot here.

I have used such an approach in one of our apps.For example I have 
three tables, that depending on the app state, show different columns 
and data. So, when app state switches this will trigger the change 
of the tables.


And other example is changing the language just where you are. No 
need to re-enter the current GUI etc. There will be just a change-lang 
XY event send.

Wasn't Max proposing a message passing gui in one of his various 
liquid thingies?

I think we just need to finish R3 GUI as Carl started it (VID 3.4). 
We might think about some by Max proposed enhancements to Draw, making 
GUI kernel more powefull, and let's see, where it leads us, before 
we start to think about another overhaul. Msg passing concept is 
surely interesting, but it imo creates another layer to implement, 
understand, to work with, so I am just not sure, unless I see the 
currently implemented solution does not allow us to easily work/extend 
the GUI.

Carl's original goal for the GUI was to make it so a child could 
use it. We should not deviate from that goal. That's part of what 
Rebrowse is meant to do. I don't want to risk a forking of the GUI 
work.

I don't mind advanced features at all, but we must be careful not 
to make the GUI difficult to use from the outset or having to place 
the user into a specific mindset, when starting to learn it.

I think it's possible to make it strong for industrial strength applications, 
without making the usability a hindrance. I also wouldn't want to 
lose the ability to write a GUI in 2 minutes for your boss to use.

It's important to lift the UI out of the domain of appearance and 
into the domain of meaning. When your UI intelligently finds the 
default window close button or the first field in a form automatically, 
and automatically assigns correct keyboard navigation shortcuts, 
because of the underlying architecture's emphasis on meaning, there's 
no need to write any code to handle that at all. It's just there. 
You build your styles to adhere to the meaning that was setup by 
the GUI system. In the VID extension kit, this is done through flags 
and powerful face handling features. You don't need to add any code 
for that in the dialect.

I've spent a bit of time going over R3/View and believe it now has 
all the "building blocks" required to build a modern/fast gob! based 
GUI. The amazing thing is that these building blocks are the 10 natives 
that View adds [to Core]. They are:

	gob!
	caret-to-offset
	cursor
	draw
	effect
	map-event
	map-gob-offset
	offset-to-caret
	show
	size-text


With these 10 natives (gob! is actually a type!) we should be able 
to construct simple but powerfull gob!-based GUIs with a smaller 
mezz footprint than R2. My preliminary conversion of RebGUI to R3 
seems to take about 50% the code to do the same thing [compared to 
R2] ... very promising at first glance.


To get a feeling for how tight the code can be the next post is the 
entire [skeleton] source of a working gob!-based GUI.

ctx-rebgui3: make object! [

	cursors: make object! [
		app-start: 32650
		hand: 32649
		help: 32651
		hourglass: 32650
		arrow: 32512
		cross: 32515
		i-shape: 32513
		no: 32648
		size-all: 32646
		size-nesw: 32643
		size-ns: 32645
		size-nwse: 32642
		size-we: 32644
		up-arrow: 32516
		wait: 32514
	]

	colors: make object! [
		page: white
		edit: white
		text: black
		true: leaf
		false: red
		link: blue
		theme: [165.217.246 0.105.207 0.55.155]
		outline: [207.207.207 160.160.160 112.112.112]
	]

	metrics: make object! [
		cell: 4
		gap: cell * 2
		line: cell * 5
		margin: cell * 4
		margin-size: as-pair margin margin
		radius: 2
	]

	;	Private functions

	set 'make-gob make function! [[

  spec [block!] ; offset, size and one or more attribute/value pairs
		/data object
		/local size text gob axis
	][
		size: spec/2
		if any [negative? size/x negative? size/y] [
			text: select spec 'text
			all [block? text text: first find text string!]

   size: 8x4 + size-text make gob! compose [size: 9999x9999 text: (text)]
			all [negative? spec/2/x spec/2/x: size/x]
			all [negative? spec/2/y spec/2/y: size/y]
		]
		gob: copy []
		;	attributes are (text, color, effect, image and draw)
		foreach [attribute value] spec [
			switch attribute [
				box [
					attribute: 'draw
					value: compose [
						pen (get value/1)
						line-width 1
						fill-pen (get value/2)
						box 0x0 (spec/2 - 1x1) (metrics/radius)
					]
				]
				pill [
					attribute: 'draw
					axis: either spec/2/x >= spec/2/y [2] [1]
					value: compose/deep [
						pen (colors/outline/3)
						line-width 1

      grad-pen linear (spec/2/:axis * .1) (spec/2/:axis * .9) (all [axis 
      = 2 90]) [(colors/outline/1) (white) (colors/outline/1)]
						box 0x0 (spec/2 - 1x1) (metrics/radius)
					]
				]
			]
			append gob reduce [attribute value]
		]
		spec: gob

  gob: make gob! compose [offset: spec/1 size: spec/2 (to set-word! 
  spec/3) spec/4 data: (make object! any [object copy []])]
		foreach [attribute value] skip spec 2 [

   append gob make gob! compose [offset: 0x0 size: spec/2 (to set-word! 
   attribute) value]
		]
		gob
	]]

	;	Public functions

	set 'display make function! [[
		title spec

  /local gob xy max-x max-y left-to-right? after-count after-limit 
  here arg append-widget widget last-widget word
		action
		handler
		size
		text
		color
	][
		xy: metrics/margin-size
		max-x: xy/x
		max-y: xy/y
		left-to-right?: true
		after-count: 1
		after-limit: 9999
		
		gob: make gob! compose [text: (title) data: (make object! [])]

		append-widget: make function! [[][
			unless widget [exit]
			unless handler [

    handler: compose/deep [on-down: make function! [[event][(action)]]]
			]
			append gob switch widget [
				bar [

     make-gob compose [(xy) (as-pair max-x - metrics/margin 1) color (colors/outline/3)]
				]
				button [
					all [none? size size: 15x5]

     make-gob/data compose/deep [(xy) (size * metrics/cell) pill none 
     text [center (text)]] handler
				]
				text [
					all [none? size size: 15x5]

     make-gob/data compose/only [(xy) (size * metrics/cell) color (white) 
     text (text)] handler
				]
			]
			last-widget: last gob/pane
			;	1st reverse item?
			unless left-to-right? [

    last-widget/offset/x: last-widget/offset/x - last-widget/size/x
			]
			xy: last-widget/offset
			;	max vertical size
			max-y: max max-y xy/y + last-widget/size/y
			;	horizontal pos adjustments
			all [
				left-to-right?
				xy/x: xy/x + last-widget/size/x
				max-x: max max-x xy/x
			]
			;	after limit reached?
			either after-count < after-limit [
				;	spacing

    xy/x: xy/x + either left-to-right? [metrics/gap] [negate metrics/gap]
				++ after-count
			] [
				xy: as-pair metrics/margin max-y + metrics/gap
				after-count: 1
			]
			all [:word set :word last-widget]
			word: widget: action: handler: size: text: color: none
		]]


  parse reduce/only spec [after bar button handler return reverse rich 
  text] [
			any [
				opt [here: set arg paren! (here/1: do arg) :here] [
					'return (
						append-widget
						xy: as-pair metrics/margin max-y + metrics/gap
						left-to-right?: true
						after-limit: 9999
					)
					| 'reverse (
						append-widget
						xy: as-pair max-x max-y + metrics/gap
						left-to-right?: false
						after-limit: 9999
					)
					| 'after set arg integer! (
						;	return unless this is first widget
						if widget [
							append-widget
							xy: as-pair metrics/margin max-y + metrics/gap
						]
						after-count: 1
						after-limit: arg
					)
					| 'handler set arg block! (handler: arg)
					| 'rich set arg block! (text: arg)
					| [set arg integer! | set arg pair!] (size: arg)
					| set arg string! (text: arg)
					| [set arg tuple! | set arg none!] (color: arg)
					| set arg block! (action: arg)
					| set arg set-word! (append-widget word: :arg)
					| set arg word! (append-widget widget: arg)
				]
			]
		]

		append-widget
		gob/size: metrics/margin-size + as-pair max-x max-y
		gob/offset: system/view/metrics/work-size - gob/size / 2
		append system/view/screen-gob gob
		show system/view/screen-gob
	]]

	set 'undisplay make function! [[gob][
		remove find system/view/screen-gob gob
		show system/view/screen-gob
	]]

	;	Start global GUI event handler

	active-gob: none
	system/view/event-port: open [scheme: 'event]

 system/view/event-port/awake: make function! [[event /local evt gob][
		evt: map-event event
		gob: evt/gob
		while [not object? gob/data] [gob: gob/parent]
		if all [event/type = 'move gob <> active-gob] [
			attempt [active-gob/data/on-away event]
			active-gob: gob
			attempt [active-gob/data/on-over event]
		]
		evt: to word! ajoin ['on- event/type]
		attempt [gob/data/:evt event]
	]]
]

add a closing ']'. An example app is:

blk: copy []
foreach word words-of ctx-rebgui3/cursors [
	append blk compose/deep [
		text (form word) handler [

   on-over: make function! [[event][cursor (ctx-rebgui3/cursors/:word)]]

   on-away: make function! [[event][cursor ctx-rebgui3/cursors/arrow]]
		]
	]
]

display "Test Window" compose [
	text 83x10 rich [size 36 center red "Reb" black "GUI" leaf "3"]
	after 5
	(blk)
	return
	bar
	reverse
	button "Close" [undisplay event/gob]
	button "Open" [
		display "Alert" [
			after 1
			text 50x5 "Some more text."
			bar
			reverse
			button "Close" [undisplay event/gob]
		]
	]
]

do http://www.dobeash.com/gui.r

this group is imo ok, no? Or - REBOL 3 View, if we want to separate 
low-level engine from the GUI one ... but I see no reason for it 
...

Gabriele, maybe you should upload your old GUI to R3 chat for reference.

I think R3-alpha is still alive as well, so Gab's GUI should be there 
too. It was many files IIRC. The question also is, if it will work 
with new R3 releases. So maybe it is easier for ppl to just get to 
r3-alpha ... I think each of us has access there :-) (note: I understand 
your message, why you want it in R3 chat, I just tried to point out, 
it is already available)

Is the lack of a table face ( or whatever the new jargon is ), a 
reflection of the difficulty of building it, or some other issues 
with the gui engine?

the resize engine is still the main issue for troubles and so the 
best result looks something like this:

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

Gabriele, were you going to upload your GUI system as well?

I see R3-gui has a gob called 'code-area which uses a monospaced 
font.

Also, I've read thru the docs ( but not the sources ) and it's not 
documented on how to create a GUI event

Make sure the word is not used anywhere else in the R3 GUI. Font 
changing, AFAIR is a little cumbersome. In the R3 GUI, fonts are 
a resource, similar to colors, certain draw blocks or materials.

Pekr, I'm the last person to make GUi contributions!

Luckily there is very little GUI code out there so it's easy to change 
:)

exactly ... I think, that what we are aiming at, is natural understanding 
of written GUI code. When reading the code, strange words should 
not disrupt my flow of thoughts ...

I see Graham is already submitting GUI reports to Curecode. I think 
we need a separate project for that. There could be hundreds of issues 
and they shouldn't be mixed with Core bugs.

>> stylize [ bt: button [] comment { }]

** GUI ERROR: Invalid style syntax: comment

Is that a GUI or core error ?  :)

r3 gui

Better to be prepared for a flood of reports. I suspect the GUI might 
be a bit popular.

:-) So when the work on GUI is supposed to be restarted? Do we wait 
for its inclusion into HostKit section?

face - 2nd level gui object with gobs, like a scheme
facet - part of a face
faced - local variables for a widget instance

I don't know about "faced" though - it's been a while since I looked 
at the GUI code, so I don't remrmber what it means.

However, I don't remember enough of the GUI model to know what the 
right word would be to use instead of "faced".

Attribute is too generic a term. There are many things in the GUI 
that have attributes.

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

Yes, but currently there isn't any, is it?  (I am aware of the fact 
that the GUI is barely alpha)

You're too generous. The GUI is pre-alpha, and wouldn't be considered 
alpha without the layout model changes Carl has said he has planned 
(but then had to take a break to work on lower-level stuff for a 
year).

It might not be a good idea to access these faces outside of the 
GUI code. There might be synchonization or multitasking issues.

that's going to make separation of gui from code more difficult

http://rebol.net/wiki/R3_GUI_Specs

This is not the list Carl made.

My take on naming - I will probably learn anything we come-up with. 
My english is pretty weak, so I am not a good measure, but I never 
ever used word FACET. I might have old brain already, but I always 
forget what it means. And I can assure you, there will be many such 
users as me. So more general naming would not hurt. It is really 
laughable, like we use special word (FACET), and then in its docced 
description to explain its meaning we use words like attributes, 
properties. So - why use FACET at all then? 


Quite contrary though, I was able to remember FACED. It sounded for 
me like sticked to the face instance :-) Anyway - I think that we 
have much more important things for the GUI to work on. And good 
docs with some diagram might be worth a thousands words ...

Only the text language displayed in the GUI.   If there is no position 
on GUI text language or user input  then I suggest that a statement 
 of same  belongs in R3_GUI_Specs so that it continues to be addressed 
or specifically ignored ... but will not be a surprise to new readers.

A frozen face does not respond to input, but is otherwise normally 
visible. A disabled face is visibly disabled. Frozen faces may not 
be necessary, but they are a first step toward creating a GUI layout 
editor.

Some of the global functions could be limited to the scope of the 
gui module and not exported.

It's good to see someone going over the gui docs - the existing ones 
got a bit scrambled when someone reorganized the wiki with no understanding 
of the gui model. Docs for Gabriele's and Carl's guis were mixed 
together and the result made no sense.

For now, I'm ignoring the docs and sticking with the source. As the 
GUI system develops, we'll write new docs.

Who is able to go over the GUI docs to fix the mess?

I'm also kind of expecting that the R3 GUI no longer uses objects 
for panes. That simplifies the code a little bit.

Got basic face traversal working: LOCATE-FACE, NEXT-FACE, BACK-FACE, 
TRAVERSE-FACE, INSIDE-FACE?, FIND-RELATIVE-FACE, GET-TIP-FACE are 
now ported from the VID Extension Kit.

Requires no modification to VID3.4.

It can be tested here:

do http://rebol.hmkdesign.dk/files/r3/gui/traversal.r

I wish I had the time to review the GUI code right now, but I'm working 
on LOAD of compressed scripts/modules.

There are a few changes in this, from the VID Extension Kit: All 
error generation is removed and replaced with NONEs. This was due 
to how VID is not pure enough a structure to work in. Consistency 
in the face tree for R3 GUI seems much better, but also because only 
a few styles exist and they all adhere to structure.

I've really been wanting to review the GUI code again. The R3 language 
is really quite different from when the GUI code was written.

Henrik said he was starting working on the GUI this month .... is 
anything public happening?

ok, the basics are here:

http://rebol.net/wiki/R3_GUI_Specs#Style_and_Face_tag_principle

for rebol3 GUI what ever you put in it really it has to work the 
same way every where it exists .... the differencies between R2 windows 
and R2 linux are so big that advanced projects are a pain to make

Shadwolf, those are low level things, so Cyphre is the one to bash, 
if it doesn't work everywhere. :-) With any luck the R3 GUI shouldn't 
have any need for adapting to various OSes and hardware.

@Shadwolf: If Carl doesn't agree with what we do or wants to position 
VID34 different than it will be a fork. Overall I still think we 
should avoid creating to much GUI forks and fragment our little community 
forces but instead pool forces to faster move forward.

But our mission is clear: We will get a R3-GUI up & working that 
will hold for big apps.

Carl seems to have some specific stuff in mind for vid direction 
but he is just not going to get to it anytime soon...I do not see 
a prob with you guys coming up with an alternate vid (rebgui for 
r3) in the mean time...each gui may be addressing different needs 
anyway. Carl's VID, when ready, can become the defacto and distributed 
with R3 but in the mean time we can use the alternate to push R use 
forward.

It would be preferable, yes. It depends how we can push it around, 
as I'm not sure Carl will want to go into GUI work now.

well, such claims sound very strange. One of the reasons why Carl 
forked GUI was, that he did not agree to some concepts. So it really 
surprises me, that you plan to continue to work on VID, without any 
coordination ... that once again asks for later fork. I think that 
for Carl to explain/document his ideas would not mean more than few 
hours of his work ...

so we really are talking fork here :-) Well, I will be glad for any 
GUI for R3, that is a fact. It is just that I thought managing Carl 
for some 1-2 hours chat on some isolated group here would not hurt, 
and you would simply know, what Carl's plan is. I can understand 
business driven decisions ... but anyway ...

Any working GUI is preferable to an official broken one.

Even if an official GUI is released tomorrow it will not be all things 
to all people and some will develop other gui's (rebgui, maxim's 
glass etc) why not start now as opposed to later. It need not be 
considered a folk of the offical vid...just an alternative choice. 
the official when released will be adopted if it works well enough 
so you won't be stepping on carl's toes.

Then we need a ticket for that. I would think that there would be 
some GUI reasons for doing SWAP, though more for doing MOVE.