AltME groups: search

Henrik, scroll-wheel: yes there is. See my scroll-wheel-handler:

do http://anton.wildit.net.au/rebol/gui/demo-scroll-wheel-handler.r

as for me - simple CGI stuff, some automatition tasks, few GUI utils 
....

VID was a revolution at the time of its invention .. but we hope 
that it will be soon superceded by R3 GUI  and we won't have to worry 
anymore :)

No, the dialect is simply a tool for building a face tree and it 
can be as complex as we want. Same in the R3 GUI.


How that face tree is otherwise managed during runtime (resizing, 
events, etc.) is up to other functions that exist elsewhere in VID, 
long after the role of the dialect is gone. What the VID Extension 
Kit does is add keywords for resizing and a few other elements, so 
the face tree holds a bit more information.


The resizing system is then used later to perform adjustments to 
the face tree, when you resize the window. That's just one example 
of doing only minor modifications to the dialect itself.

Presumably in a completed GUI we wouldn't need to generate anything 
on the fly

Even now I see that having a true rich text we can type with is not 
possible in R3 gui

I'm getting tired of hearing that if something is currently not there 
in the R3 GUI, it's completely impossible to do. Sorry.

While you process files you could check a global variable stop-me 
if it's true and if so, stop processing files. Then all you have 
to do is add a button to your GUI that sets stop-me to true when 
clicked, which will stop the file processing.

if you want your GUI to respond to events while you are processing 
within a loop,

here is a trick to allow the application to work asynchronously... 
add :

wait 0


within your loop.  this way, the event mechanism has the chance to 
do its thing.  if the gui sets a global called Interrupt, you can 
then inspect that within your loop and exit.

ex:

forever [
	wait 0
	if interrupt [
		break
	]
]

that was one reason the Amiga felt so fast... the gui wasn't managed 
by the application's task, but by the os... independently of the 
application's business.    For example, even if the application was 
processing, the menu would pop up in real time... cause intuition 
(the gui manager) was at a higher priority than most applications.

hehe, but its funny that windows 1.0.3 actually didn't have windows, 
it was a row/column/grid gui engine.

GET gives you the value of a word.  


the detail being that the word may or not be bound.  when it isn't 
bound explicitely, it will search for it in the global context (explicitely 
if you give it a lit-word).


which is why its always a good idea to use GUI code within a context, 
so you can be sure any un-explicit binding is local to that context. 
 note that you must explicitely create them within the context (at 
the root level of the context) for that binding to occur.


(note to Lad & Brian..I know I'm over-simplifying the whole concept, 
but that is how basically it works for "mere mortal"  ;-)

ex: 
here .... danger!   [a b c] use isn't bound within the context.

context [
	layout [a: field b: field c: field]

	fields: [a b c]
	foreach field fields [
		set-face get field to-string now
	]
]





while this will be (and protect your global context from being clobbered 
by the field names), plus you are sure that GET will try to use the 
field names locally.

context [
	a: b: c: none

	layout [a: field b: field c: field]

	fields: [a b c]
	foreach field fields [
		set-face get field to-string now
	]
]



if you really wanted to be funky, you could put words in the [a b 
c] block which are bound to other contexts using 'IN.

append fields [] IN other-context 'd


then when the loop runs, the field specified by d in that OTHER context 
will also be set.

using the above tricks you can make system-wide intialisation functions:


here is a cool previous login detection system which fills up your 
whole gui based on stored data in a database.

	

; supply contexts, view controls set into them and the data to set 
into.
setup-all-gui: func [
	spec 
	/local ctx control controls data i
][
	foreach [ctx controls data] spec [
		repeat i length? controls [
			control: get in ctx controls/:i
			set-face control data/:i
		]
	]		
]
	
; reload previous session
either all [

 main-data: get-sql-last-main-data  ; returns [ "project" "module"]

 login-data: get-sql-last-login    ; returns ["user" "encrypted" "server.com"]
][
	setup-all-gui reduce [
		main-gui [proj-fld mod-fld] main-data  
		login-gui [login-fld passwd-fld server-fld] login-data
	]
][

 print "This is the first time you use application, user-setup will 
 now be called."
	setup-user
]

don't you have the R3 GUI source code?

I would like to use and re-use vid "panel" gui elements. Something 
like: view layout [style gint panel [text "label:" field 100 "0"] 
 x: gint (x) y: gint (y)]

I'm just about done... the current gui, has a victorian house in 
the backdrop and tree branches in the foreground which add to give 
a sense of depth

Can anyone confirm this is a bug in View (VID), so I will post it 
to RAMBO:

gui: layout [f: h1 100 "test"]
f/text: does [probe "testing"]
view gui


;click on the text, drag --> crash rebol.exe. Tested on XP Pro SP3. 
View 2.7.8.3.1.1

;function get called when the text clicked, crash happens when dragging.

I of course use other programming laguages for my work. REBOL is 
mostly useful as a helper for me.

I use it to generate data, parse big files to extract something, 
automated FTP/HTTP/EMAIL jobs, small GUI applications.

Kaj, I think Carl is still thinking about that. The R3 GUI will provide 
some documentation.

but it would be fun to do a low-color, low-res VID3 GUI. :-)

I think it's because the changes are very large, yes. It's rather 
impossible to do any real GUI work as long as VID3 is sitting in 
this current state, where we're trying to figure out how VID3 should 
work and that things might change from week to week.

Perhaps we need a "rebgui" for R3 as well ... ie. a simplified gui

though should a simple gui scale to a complex one?

Gabriele, I like the ideas behind your VID3 and think that with only 
minor cleanups would be a GUI to brag about.

In fact both. I worked on a multi-user contact management application 
that connects to a SQL database (mysql and sql-server). There are 
some main areas I want to investigate into : DB access (Trebase could 
be a sexy alternative to other db engine), GUI and business logic 
processing. In the last area, I think that rewrite some code in R3 
can produce more elegant and more efficient program. I'm one of the 
guy who used hash! datatype ;-)

Karim, then I think it is a bit preliminary to consider porting:


- mysql, postgress - while those schemes are built upon raw TCP R2 
stack as a schemes, someone would have to port them to async R3 networking 
kernel

- sqlite - requires mostly DLL access. There is no DLL access in 
R3 and maybe there will not be one like we know it in R2. Carl is 
not decided yet, if we go via DLL layer like in R2, or via standardised 
plug-in interface, which is not ready though, as it needs modules, 
which are not ready either

- GUI - Gabriele was working on new VID. It is now called VID 3.3 
(third prototype). It is still not complete. But - Carl is trying 
to follow slightly different obectives, so he decided to rewrite 
it and bring us VID 3.4 prototype (probably called GIDI)

- View, unless Cyphre fixes some harsh bugs in its kernel, is pretty 
much buggy and makes VID3.3 crash in few secs to minutes.

We do have some very specific things that need to be done, such as 
FTP and making other protocols and REBOL/Services (which has been 
ported now). I need to get VID3.4 done, so I can work on GUI and 
graphics.

I recall someone (don't recall who) made a REBOL gui that wasn't 
square but oval shaped and based solely on faces (no layout use).

in the mean time, it looks like VID for REBOL/View 2.7.7 might contain 
considerable additions, such as GUI resizing and proper error parsing 
of layouts.

although I'm not really that worried. if VID3.4 will be very different 
and inferior to VID3, it's important to have Gabriele finishing VID3 
to have a viable alternative as soon as possible for proper GUI development.

I had proposed a system to abstract input from the GUI a while ago, 
but it was mostly ignored. it's probably not that easy to implement.

but what it would do, would be to let you use very different devices 
for regular input, such as a Wii controller. there would be no changes 
to the UI itself. if you need additional graphical controls like 
an on screen keyboard, it would be part of the abstraction rather 
than a part of your GUI.

but I think it makes sense. I've studied the problem a bit. Everyone 
else makes special cases out of it, rather than a generic system 
for strange input devices. I had hoped that VID3 could be the first 
GUI ever to do this. It would mean that you can write a GUI and a 
handicapped person or a person using handwriting recognition would 
be able to use it without modifications.

Carl mentioned that he liked the dialect and didn't want to change 
what it would be capable of, but that was before the announcement 
of the new networking scheme, which apparently is somehow integrated 
with VID3.4. There is for example a SEND command in the new dialect, 
so I guess he wants to make it extremely simple to build networking 
code into a GUI. I just hope he does it right. :-)

Henrik .. I did a GUI mock up and the released the mock up.  Then 
I took suggestions after that :)

that remembers me how we started rebGUI with rebol community ashley 
and me. First ashley and me  were working on MakeDoc and MakeDoc 
Pro dialect to VID renderer we emulate each other alot and from this 
exange born the constatation that common VID face set was not adapated 
to usual GUI  or big amount of face handling. And from that constatation 
Ashley proposed to make rebGUI  wich we presented as a major enhancement 
to VID layer keeping the main idea alive "KEEP IT SIMPLE". Ashley 
proposed the community to share idea or suggestion and on every single 
widget the community proposed we got a discution and code proposition 
to achieve this goal.

I love working in Rebol for GUI apps.  Development is fast and I 
can do most of the things I want with the raw view.  Sure, I could 
go back to grinding out interfaces in C++/C#/VB/<insert lang here> 
but it would lack the simplicity and flexibility I am used to with 
Rebol.  Unfortunately, most of the time i am now using Rebol for 
'what if' and concept work because of many underlying issues with 
the draw subsystem preclude serious development work.

rebol wlll loos in originality .... and therefor ppl will say why 
to do GUI application in rebol since i can do them in desktop google 
or opera widgets with more functionalities

but quite franckly i'm doing rebol to not have to spend weeks in 
GUI design ...

that's lot of code for less efficiency but that's my point of view 
i prefere spend little time on the GUI and more time on what does 
the GUI ...

well that's my personal taste the only way to get me spend hours 
on a GUI  is when I write a brand new widget  ^^

other while I like the short GUI code provided in VID2

but anyway that's another way to organise the code maybe the most 
of ppl will like it and I still can do a  bridge dialect VID2-> VID3 
 to keep my habits  in GUI  coding  hihihihi

I did notice that you have to create new widgets in VID2 a lot more 
than seemed necessary to me. I hope that most people can get away 
with just using widgets in their code, and leave the widget creation 
to the GUI designers (which I am not).

Henrik thanks for posting.  That sounds a bit like how I currently 
dev my gui apps.  They behave like webpages for the most part.

He says he's building a new gui system ... don't really know what 
that means.

even financial software needs a decent gui

for example opera webbrowser functionnalities: It render HTML content 
(some times with some strange bug), you have voice speech sinthesis 
to read the content of a page for blind people for example  you have 
voice command system  to operate it, you have widgets (external kind 
of mini GUI  sofware pieces to show you web information on an extend 
way) you have a plugin system with lot of plugings you can use P2P 
bitorrent to download you can connect to IRC read your mails ... 
 So yes now in day web browser are not only web browser and that's 
a matter of  fact  this evolution took 10  years of constent apports 
I don't see rebol going this way in only a couple of month ...

well with vID2 we done a MDP Makedoc  renderer so doing HTML  one 
is not so hard with actual VID but the fact is MD GUI  and MDP GUI 
 gots a big lack of widgets for the none document rendering part 
wich I will call the IHM (menu bars, tab-panels, ability to resize 
easyly the whole content  or part of it   and that what lead us to 
do rebGUI ... to enhance that aspect.)

VID was already simple  in comparasion to what are the other libraries 
I don't know if you ever tryed to deal with transparencies with raw 
X llibrary that pain in the head number 1  ^^.   Well i'm not against 
simplifying the system but first how does the industry shape their 
GUI 99.9 percent of the time the GUI  is build using a GUI designer 
and the only thing you have to do is set thru the GUI designer interface 
the settings for the widgets you graphically picked and organised 
then you have to write the call back code... Then to take your example 
back with the hyperlink people then don't code they only format text 
en even then most of now in days forum like PHP BB  use javascripted/pugined 
rich text area  to format their  text you push a button it insert 
the text the way you want. and some of them on the php engine level 
are able to recognize http:// footage to build on the fly the hyperlink 
without requiering any tag adding by the user .... I'm not sure separating 
the way you organise the widget to the way you configure them will 
lead us to more easy way

So to answer Louis' question: Not yet, as far as we know. The data 
structures for Unicode strings are there, as are UTF-8 word! values, 
but binary encoding and decoding is not yet there, and there are 
some limts to Unicode input and output (mostly due to the Windows 
console). The encoding/decoding work seems likely to get done as 
a part of Carl's GUI work, as that will probably include text display. 
The console IO limits are likely to remain until the written-in-REBOL 
GUI console is adopted.

Carl "Yes, I have had the GUI running for some time..."

I reaaaaaaaaaaaally appreciate if carl find us a better way to deal 
with selections (I remember when I developed MDP-GUI  that to add 
the flag around a selected bounch of text that was all a pain  in 
my poor brain...)

He has stated that he wants REBOL's GUI to be more declarative, with 
structural and presentation cleanly seperated, and network access 
and services fully integrated. Sort of like HTML/CSS/HTTP done right: 
A REBOL browser. That is what he has been working on these last few 
months, what we have all been waiting for.

This is why Carl's work lately has been worth waiting for. I mean, 
if it was just a GUI framework that would be silly, right? :)

well, sure, but I imagine there would be a degree of control of how 
you want it to layout, either in a GUI oriented fashion or a document 
oriented fashion.

maybe JR (REBOL for JavaScript) could help a bit ... it would be 
kind of your next javascript library .... no installation .... VID 
way of defining gui, translated to JS ...

Agree here also, I want cross platform GUI where the rebol browser 
provides UI and other services to applications not just content. 
 The value in the Google applications is not their quality (which 
is okay) but in the access from anywhere feature.  The HTML/Browser 
is trying to grow into the application space but is really at a disadvantage 
because of the technology.

I don't think the design of the browser GUI is as difficult as its 
underlying concepts, like security and basic page display mechanisms. 
He'll want to get those right first.

Terry - why would not anyone use VID like fluent description of GUI 
instead of crap js code? Then tell me, why JAVA guys came with declarative 
JAVAFX aproach, if they had JAVA itself already ....

There are finally a couple of signs of life with R3 GUI; 2 new pages 
in DocBase.

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

Let's hope the behaviour of the GUI is as good as the syntax.

There is not a public link to the internal releases for the development 
group of REBOL 3, and that includes the Unicode releases. There isn't 
much point in posting one either, since Carl's GUI changes are just 
as extensive as the Unicode changes, and we haven't seen them yet.

Fun fact: Compressed size of the new R3 GUI is 13.8 kB.

I never got the chance to try out make-gobs, but it did seem to solve 
a complexity problem on the DRAW level by giving it for example an 
internal resizing model, which is very important for properly made 
GUI graphics..

I'm now able to study the R3 GUI source code.

Running the GUI now. It's... colorful :-)

there are animations in the GUI and I can resize the entire window 
while they play.

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

Skin is for testing purposes.

The GUI feels fairly quick, but Carl says there is still a lot of 
optimization and caching to be done. This won't happen until he feels 
the entire system works correctly.

the source is divided in two parts, with files beginning with g-* 
being the GUI system and s-* being style files.

REBOL [
	Title: "REBOL 3 GUI - Development Module Loader"
]

files: [
	%x-funcs.r
	%g-defs.r
	%g-debug.r
	%g-funcs.r
	%g-styles.r
	%g-faces.r
	%g-panels.r
	%g-events.r
	%g-text.r
	%g-effects.r

	%s-fonts.r

	%s-panel.r
	%s-button.r
	%s-bars.r
	%s-text.r
	%s-image.r
	%s-lists.r
]

code: collect [foreach file files [keep load file]]

len-kb?: func [s] [round/to divide length? s 1024 .1]

src: mold/flat code
gui-cmp: compress src
gui-size: len-kb? gui-cmp 

print ["GUI Size:" gui-size "KB /" len-kb? src "KB"]

do code

That's the GUI loader.

New doc posted to DocBase, including some screenshots: http://www.rebol.net/wiki/GUI_howto_styles

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

More screenshots: http://www.rebol.net/wiki/GUI_Basics


Carl write, it's a prototype skin, and he uses jpeg (with artefacs), 
so those are probably just to feed the hungry ones.

Shouldn't AREA-SIZE read SIZE in the circle style example on the 
GUI-Styles Wiki page?

http://rebol.hmkdesign.dk/files/r3/gui/001.mov

Framerate is about half of what it really is.

In GUI_Basics chapter, in Opinion survey example, there is 'group 
used without explicitly stating number of columns. How does such 
group know, how to layout its elements? Is it simply laying all elements 
in one row by default?

http://rebol.hmkdesign.dk/files/r3/gui/index.rsp

Easier access to images.

http://www.rebol.net/r3blogs/0151.html-GUI: Colored buttons - Attributes 
vs Styles

Making the GUI more skinnable without much programming knowledge 
would be advertisement for R3. Every new skin put on one of the skinning 
sites gets the R3 name out there - viral marketing.

In the DocBase page for GUI_Panels, Carl wrote


A group has no backdrop or border and arranges horizontally by default.


I feel this is ambiguous; do groups have no backdrop or border ever 
or only by default?


I'd like to edit the wiki to make this more clear but I can't tell 
 from the rest of the page whether a panel can have backdrops and 
borders. Can anybody with access to R3 clarify this?

Carl's now describing a bit sizin model in following chapter - http://www.rebol.net/wiki/GUI_Panels

New VID related blog posted - http://www.rebol.net/r3blogs/0152.html
- GUI: Thin skins, thick skins, and in-between

It kind of made point, when Carl posted once in two months. But now 
it is almost daily, so maybe I will stop it, to not flood here. Surprised 
a bit by low number of reactions. I thought ppl will be more interested 
in new GUI and how it starts to turn out ....

I hope the subject of the example, a colour picker, isn't an indication 
that the new Rebol GUI isn't going to native dialogs. Windows, Gnome, 
KDE and Mac OS X all have native colour pickers don't they?

Status:


- Asset management is a big question. There are design questions 
to solve with regards to loading and unloading assets to make it 
easy to switch skins. Carl has mentioned the three skinning layers 
in his blog post.

- I proposed a method to specify lists of materials in a very simple 
way like FONTIZE and Carl liked it, but it's not yet implemented. 
This is inspired by what 3D modeler software does to manage materials, 
rather than what other GUI engines do. It's much more formal.

- I proposed a method to generate materials for gradients in styles 
in a very simple way. Carl liked it. This is halfway implemented.

- There's a function to generate a gradient from a description in 
a compact way and then apply a function to it to create a real adjustable 
specular highlight. This means you don't have to work with a big 
set of tuples in a block to create a good gradient. You can see that 
in action here: http://rebol.hmkdesign.dk/files/r3/gui/026.png

- Carl is working on panels and groups. We're building small apps 
to try to reveal bugs in the layout engine.

- Panels has a bug that cause cells to overlap when resizing. This 
is not evident in my screenshots though. 

- Resizing with refresh bug has not yet been fixed and you may see 
it sneaking in, in some of my screenshots.

- Text handling (cursor movement, selecting, etc.) is still pretty 
basic. I think it's due to the event system being grabbed directly 
from VID3, as it behaves the same way. There needs to be a person 
capable of writing this code, as it can be done as an isolated project. 
Gabriele is a prime suspect here, but he's probably too busy at the 
moment. If not possible to do now, then it will have to wait a bit.

- Carl talks about getting more people working with VID3.4 this month 
to get them to write real apps to reveal bugs in the layout engine. 
Needs lots of testing.

- Text fields allow text to be painted right out to the edge of the 
area-size, which looks a little silly. Carl wants Cyphre to look 
at DRAW clipping.
- Accelerator keys - no work done yet.
- Disabled or focused items - no work done yet.

- I have skinned button, toggle, slider, text, area and progress. 
I hope to skin scroller and panel today.
- Constantly working towards simplifying styles.

Code example:

do %load-gui.r

files: read %*.r

view/options [
	tight [
		text-list files do [set-face ca read-string pick files value]
		scroller
	]
	ca: code-area
][
	title: "REBOL Scripts"
	columns: 0
]

Produces

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

it seems that Carl is trying to build really strong foundation to 
make development, debugging/testing and using the gui an easy enough 
task ...

Part of the fun is when code patterns in the UI suggest possible 
improvements to the core REBOL semantics. Carl's GUI work is coming 
with lots of goodies for the rest of us, whether you are doing GUIs 
or not.

A new DevBase is still intended to be a testbed for REBOL technologies, 
including the new GUI and LNS.

A more modern GUI for devbase would be nice

I sometimes wonder about the inherent limitations to a dialected 
GUI vs an object oriented one

Henrik:  from the docs - "The GUI module object (currently called 
GUIE, but soon to be just a module variable) " - does it mean VID 
3.4 will use real modules, or just reading too much into it on my 
side?

AFAIK the GUI system will be a module.

the GUIE almost looks like new name for the GUI :-)

Graham, drag support is already in the new GUI. All that would be 
needed for full drag-and-drop is some idea of what dropping is supposed 
to mean, which varies depending on the situation.

Pekr, R3 will use real modules. The initial public development releases 
of the GUI will not. The module system (and even spec) are not finished. 
We will be able to resume work on the module system soon, and the 
design of the new GUI's code is being done with a module system in 
mind. It's helping to do the GUI first because it serves as a use 
case and inspiration for low-level semantic fixes like a module system.