AltME groups: search

BTW, the GUI project will be coming back to life soon... and I'll 
only be one of several people working on it.

Begun detailing the implementations here:

http://rebol.net/wiki/R3_GUI_Implementation

My original DISABLED allows the face to still be rendered in a disabled 
fashion, which is good for forms. I'm not sure how useful it is to 
have your DISABLED after initial rendering, because you would actively 
have to remove the face.... although that presents some interesting 
possibilities for altering the face topology. There are already styles 
in R3 that don't render and that's handled differently.


The idea for FROZEN was that it would be a first step toward using 
the same styles with altered behavior for a GUI editor. FROZEN was 
selected, because of the simple FREEZE-FACE/THAW-FACE names.


READONLY seems the same as SELECT, but READONLY is probably a better 
name.


HIDDEN seems like a cop-out to me. :-) If you want a security measure, 
elements that a user should not see should not be included at all.


With my DISABLED, FROZEN/INACTIVE and READONLY, would that cover 
it?

No. And that's after LOAD-GUI.

I use hidden panels and buttons all the time .. to reduce GUI clutter. 
 When the user does something that satisfies some condition, I then 
show these hidden buttons, panels.

Framework design can shape app design. For a new GUI framework, it's 
best to support a variety of interaction models. There are a lot 
of apps written on legacy frameworks that are having trouble adapting 
to the current interaction models. For instance, we better assume 
that there can be more than one simultaneous input - multitouch is 
here already.

for scripting purposes, having a script that works on all supported 
platforms is a reasonable aim.
I just don't see that it works for GUI based applications

Say you want to write a multiplatform gui app, well, then you make 
sure that what you do is supported.

I thought that the whole point of Carl's GUI was to allow app developers 
ignore all of the little details about how the app looks and acts 
at runtime and just focus on the semantics. Let the stylist worry 
about the appearance, and let the infrastructre people worry about 
whether the input came from multitouch, mouse and keyboard, whatever. 
Separation of form and function.

people are so used to R2 VID, that it's hard to get out of that thought 
process that the GUI must be completely hackable. :-)

And I think it should be, by the GUI hackers. But those hacks should 
be able to be used by others who don't want to have to worry about 
that stuff (like me).

The challenge is to provide a GUI that you don't need to hack to 
make it do what you want. We can go much further with that in R3 
than we ever would be able to with R2.

The challenge is to make a GUI that ordinary users can hack :)

No, the challenge is to make a GUI that ordinary users won't have 
to hack. Ordinary users are terrible at making GUIs, and their attemps 
to hack them look terrible.

Hello everyone.... Robert has invited me to be involved in the GUI 
project.


I thought about it for a few weeks, and decided that I would like 
to do so (become involved)... because Robert is not the only one 
asking for this.  There seems to be other interested persons, no? 


(And, just a note, I am not ignoring the other comments posted above, 
but my desire is to stay on topic here.)

I believe we are talking about keyboard navigation of the gui so 
that's good

Right, so to continue my comment from above...  


I went to review the main documents... however, the GUI docs on DocBase 
seem pretty "messed up" to me.  Am I the only one who thinks that?

One question I have that I did not see in reading all the docs .. 
how does one generate a GUI event ( to be used inside network code 
) ... since one can't use a wait to allow the gui to update?

Carl - I hope that joining the GUI effort will not distract you much 
from HostKit/Extensions work :-)

Robert, what needs to be done to the GUI from Carl's side?

Carl should imo write down notes about how he envisioned GUI 3.4 
to work, especially non finished things like events (still from Gab's 
VID), layers, guides, resizing, etc.

H: I'll take a look around. Probably in R3-GUI world, no?

We need a good enough solution, that is open enough that we can drive 
it forward. At the end of the day, the GUI must fit the developer 
needs. I'm not seeking for perfection (Ok, I do) but for time-to-market 
(because I learned/know that it's more critical these days).

Is that a GUI or a core issue?

Probably the best way for us GUI noobs to be able to help is for 
Carl to provide coherent docs for us to read and to start writing 
scripts ....

Carl, good to see you back in the GUI fray :)

Nice to see the events evolving...
The community needs a GUI system and creates a team

Reichart wars Carl that something is moving on on this front and 
needs his attention

Carl pop up in the group and catches the wave hoping the GUI sysytem 
does not take the wrong direction (I suppose).
Everyone is happy about this ! :-)

Good. Kr Bacon really messed things up, and this is a source of much 
of the confusion about R3's GUI.

good to hear Carl is documenting his ideas for the GUI. Is Cyphre 
already doing some low-level work? :-) Is there actually any priority 
for low level work? E.g. unicode display, better cross-platform font 
handling, draw improvements, transparent top windows, etc.?

no, just 5 minutes of work to get rid of Carl's fancy colors, while 
we do various GUI testing.

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

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

Henrik, a question: currently I see a trend to adopt animated background, 
animated gui elements, animated transitions and sometime 3D ebjects/effects 
in the interfaces. Do you think they could be possible in the next 
R3 GUI ?

Henrik - have you received any docs on GUI from Carl yet?

there was actually something in Gabriele's GUI, but it was very complicated 
to work with.

Thanks henrik, it is obvius those are not meant to be included in 
the first instance. However I keep in mind the multi-year target: 
have a modern GUI suitable for all computing platforms.

Another issue is that while this should be simple to do in the dialect, 
it should also be possible to create and destroy connections during 
runtime and make it abstracted enough to be possible to do with a 
GUI editor.

could you have gui for other os (linux and osx) now ?

Liquid is the perfect engine to add to R3 GUI.


After years of use in many different situations, I am now very confidents 
in its capabilities.


Liquid is a generic engine, allowing you to tell DATA to message 
DATA.  


This means you can use the same system that you'd use for the GUI, 
for the data itself, and then just plug it together.


Because Liquid was designed to allow very advanced procedural computation 
at a fraction of the complexity of other systems I've used I'd say 
its the best system we'll ever be able to build for R3.


Wrapping liquids within faces and the view dialect is rarely more 
than 5-10 lines of extra code, but then, you don't need to write 
"action" code afterwards.

liquid even has data filtering mechanism built-in... so you can patch 
type conversion right in you data, for example, and connect any other 
compatible datatype without needing to build ANY extra code.


Did you notice the detail... I didn't say type conversion in your 
GUI... 


so If your age is supposed to be an integer... pluging it into a 
field can actually make the field an integer field, without the field 
knowing anything about integers.   :-)

We should be shown some liquid usage example, the simple one, to 
understand the concept. Then we should be shown more complex working 
app. If liquid is general flow engine (usefull also to non GUI parts), 
it could be added to rebol as a concept, and maybe even made native, 
but I am not sure if it fits the language or not. Maybe it should 
be available in the form of module/extension, dunno ...

AdrianS: I asked Carl to resurface and provide development team with 
promissed GUI related docs. I hope Carl will be back soon, he worked 
on moving Altme services to new servers (as can be seen in his latest 
blog post)

I'm having a stupid day where nothing works, so I can't do any work 
right now. I'm not sure it's a good idea to just wrap any flow engine 
on top of the GUI. The idea is simply to . We have to remember that 
it's about the idea

Steeve, how's progress on the r3 gui chat client?

A lot more world experience is needed before something unknown is 
added to the GUI

Graham, i try some idea on my own GUI currently

and i don't like the need of  a phase to construct graphical objects 
from read-only specs.
All the GUI we had so far, act such.
It's an bad...

Are you Guys using wait , instead of time events in your GUI ?

BTW, the relevant code is host-device.c, line 406 and below.

*/	REBINT OS_Wait(REBCNT millisec, REBCNT res)
/*
**		Check if devices need attention, and if not, then wait.
**		The wait can be interrupted by a GUI event, otherwise
**		the timeout will wake it.

Robert and I are discussing field persistence, i.e. tieing fields 
directly to database tables in a layout. Going to be a bit about 
our conclusions in the R3 GUI specs soon.

The question is: How to get from GUI to a DB and back without cluttering 
the VID code, or having to code to much. The idea is to collect the 
GUI elements belonging to one record and than auto-create tables 
and columns. So, people can concentrate on the app code and get the 
75% always necessary database code for free.

Well, if you show us something it will be easier to propose ideas.
I'm working on my own GUI aswell currently :)

Not perfect as is, and perhaps simplistic, but I could imagine finding 
a way to add more semantic hooks to a layout and have a somewhat 
automated way to set/retrieve data from parts or all of the gui...

i think the syntax of the data block to get/set the GUI and get/set 
the DB should be the same.
>>get-face pan
== [foo: "foo" bar: "bar"]
>>set-face pan [foo: "bar" bar: "foo" ]

>> get-db [foo: "bar" bar: "foo"]

== [foo: "bar" bar: "babar"]   ;the DB can decipher the data block 
and knows well what is the requested key and what is only attribute.

>>set-db [foo: "foofoo" bar: "..."] ; update the record or create 
a new one.


Having exactling the same syntax allow to pass data between the GUI 
and the DB without pain.

specs:

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

Henrik - is there any progress on more important GUI parts, like 
keyboard navigation, etc.? :-)

This http://www.rebol.net/wiki/Template:GUI_TOC leads to this http://www.rebol.com/r3/docs/gui/gui.html
and this message


So, you found this page from the sitemap? Sneaky.

This GUI section 
is under construction (on a different server). It's not meant for 
publication yet. To be transferred here as they move into final draft 
stage.

Many of these links don't yet exist. They are being filled 
in at this time. Also, the image links are not yet setup.

So, no I didn't.

BrianH, yes, that would be a work around, so I'm not using triggers.


I've written a GET-DB-PANEL function now that fulfill the specs, 
including SKIP, TABLE, _DATA, scoping, etc. This function is custom 
to RM-Asset, so I'm not sure we want it in the R3 GUI other than 
as an extension package.


Also, I've written an EMIT reactor that emits the panel in GET-DB-PANEL's 
object format as an SQLite record (predefined object).

I'm using options for now along with GET-DB-PANEL.

What this shows:

- Writing reactores is easy peasy.
- Using reactors is even easier.

- Doesn't break anything in the R3 GUI, if you GET-PANEL instead 
of GET-DB-PANEL.

An example of how this is used:

rec: make object! [] ; the SQLite database record object

view [
	form-panel: panel 1 [
		id: field options [skip: true]		; write-only field
		name: field				; stored in the object as 'name
		age: field				; stored in the object as 'age

  note: field options [_data: true]	; both these will be stored in 
  the _data map!
		bytheway: field options [_data: true]
	] options [record: 'rec]
	button "Emit" emit 'form-panel
	button "Submit" submit 'form-panel %form.txt
	button "Acquire" acquire 'form-panel %form.txt
]

So when you press Emit, 'rec will be set to:

make object! [
	name: ""
	age: ""
	_data: make map! [
		note: ""
		bytheway: ""
	]
]

If you press Submit, this object is made:

make object! [
	id: ""
	name: ""
	age: ""
	note: ""
	bytheway: ""
]

and is stored on disk with the name %form.txt


If you press Acquire, the above mentioned object is automatically 
loaded from disk and into the form.


Still need a one-liner for loading SQLite data into the form. Going 
to work on that now.

I know that you guys are doing some stuff for real apps, but those 
concepts really seem very preliminary, and kind of high-level in 
relation to GUI itself. Maybe this does not even belong to GUI itself. 
I alway hated, when GUI dictated me, how should I work with my data 
.... it is always like that - you come up with just one method, of 
possible tonnes of other methods of data to form relation handling. 


We don't have tabbing, focusing, accelerator keys support, unicode 
support, layers, transition effect, rich-text and draw probably still 
need some improvements,  etc., we don't have any more complex style 
to prove our GUI allows to be extended flexibly, so I think that 
solving how to handle data from SQL at this stage is very very preliminary 
:-)

This is just my opinion :-)

Anyhow, a form like this:

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

can be set in one line of code and retrieved in one line of code.

This is quite this kind of nonsense I thought we could avoid :-) 
You simply often might find the case, where it will not fit your 
situation, and then docs say - you can't do everything, using the 
concept. So then you are left with some usefull, but not-in-100%-cases 
usefull case, and between the raw solution. IIRC Chis has similar 
solution with his system? I don't remember the name .... however 
- this does not belong in the GUI group, and this is exactly where 
I thought your form  abstraction aproach will lead you :-)

hmm... when writing a reactor, you can specify any-type! as an argument, 
but GUI parsing halts when encountering a path! for that argument. 
Does anyone know if this is a DELECT thing?

So we can start using R3-GUI and expect minor changes to use and 
implimentation?


I thought there was going to be some major changes yet to come and 
present functionality might change significantly...

I wonder what would be needed for transition effects, as e.g. PowerPoint 
has ... to slide away screen or its elements in various ways. There 
is some basic effect -fly-out - in recent R3 gui demo, but dunno 
if it is interchangeable

those gui elements are live and functioning ...

That's OK, no? Noone said there should be just only one GUI. But 
we could exchange some ideas, of course if it is not fundamentally 
different :-)

A small question: I am reading the GUI documentation. Are concepts 
exposed going to change since the resuming of developments ?

I get an error with this example from the docs:

button "View" view [button "Close" close]

** GUI ERROR: Cannot parse the GUI dialect at: button Close close
** Throw error: halted by user or script

Any progress on R3-GUI side? Has the work already started? :-)

I've been working on docs (a dialect for image annotation in docs, 
actually) for a program, so not much here. Some things are actually 
very difficult to do in DRAW. I could use a pure alpha overwrite 
mode. I've posted a report in the AGG group about a bug in TRANSLATE.


I might add something to specs, which I've been working with as part 
of writing docs: A way to use a layer to provide editing tools, i.e. 
box handles, rotate handles, swipe selections, moving and resizing, 
like you have in many graphics editors. I think this can be done 
in a generic way and would make it easy to build any kind of graphics 
or GUI editor.


This is not something that we want to add now, but it's nice to think 
into the design, so that it's simple to do later (and to remove, 
when Carl announces that he doesn't like it).

But generally said - we are still waiting for Carl to move View to 
command! interface and releasing the sources? Carl almost finished 
GUI docs, which is nice, but I still miss one doc - his pov on - 
where to go next - still some concept descriptions missing, e.g. 
his plan for layers, etc.

Playing with R3 GUI...I see panels and groups resize horizontally 
but is there a way to get it to resize vertically...or does that 
involve playing with the style code?

Well, the keyboard navigation in the VID Extension Kit is a much 
bigger hack than in the R3 GUI. That's thanks to a good design and 
treating the window itself as a style. There are still some issues 
with Carl's method of tab navigation colliding with mine. Carl has 
a tendency to work functionality that should be generic into a few 
specific styles. I don't really get why he does that, because it 
scales like crap.

http://rebol.net/wiki/R3_GUI_Specs

I haven't read the GUI source in a while, but remember it to be kinda 
disorganized. That is what prompted Carl to make a module system.

Pekr, from specs: "This might be a problem for VID, because we use 
only simple text for UI styles. Will we have to switch to rich-text 
instead, to fulfill the needs?" - it should not be a problem since 
all text in R3 GUI is rich text.

What happened to the dedicated R3 gui team that was going to finish 
R3 GUI ?  Did they get side tracked or are they still working on 
it?

the next project must use R3 and the GUI, so the work starts there 
again

this looks like an interesting GUI http://10gui.com/video/

Maybe Lotus notes is looking good now, Maybe.... 

But I had so many bad experiences with that crappy app, in the past.
No respect of the GUI santards. (F5 to quit).
No drag and drop.
Lof of useless confirmation boxes.
Useful actions hidden in deepest menus I ever seen.
etc...
It was a pain in the ass just to write a simple e-mail.

GUI status discussion moving here.

Screenshots will be available when there is something to show. Worked 
out a few bugs regarding tab navigation yesterday and there is work 
being done on the basis for a grid system that will be used for tables, 
dropdowns, menus, etc. Someone has been added to the list of developers, 
as I don't have much time right now to do GUI work. He may speak 
up if he wants to. :-)

Depending on what will be worked on next, we might delve into testing 
schemes. We want the R3 GUI to be easily testable: Fire random events 
at a GUI window and collect errors and crashes and also generally 
record and playback UI events to tell what a user did.

I volunteer to test, even preliminary versions. It helps me to understand 
gui, to study sources, etc.

we're getting many ideas from the app I'm building now. Automated 
GUI testing is badly needed.

Complexity: As far as possible, we want to add things in a way so 
you can simply omit them for inclusion when building the GUI. It 
won't be possible for everything, like tags, but testing framework 
would work that way.

welcome Rebolek! :-) You should be put onto Sound, not GUI, no? :-)

but if you look at pm-101, I think I can do some GUI work too :)

Overall we start with the basic concepts we want to have in a GUI 
framework, as we think these needs to be taken into account very 
early. Building up a broad widget-set on a good base shouldn't be 
that hard than.

Is it by any chance planned to add HTML rendering to R3, maybe as 
an extension? (probably not but I'm going to ask anyhow because I'm 
horribly rude) There are some cool apps that mix native GUI widgets 
with HTML content, gitx for example. Would be neat to do this with 
Rebol too. And I'm sure, often enough an app you write is going to 
offer export as HTML, being able to show a preview of the output 
while you are editing the data adds a nice touch to an app.

With recent alphas, Is there a way to run GUI scripts with no console 
window open? I guess not ...

Any news from our fellow GUI team? :-)

Pekr about you gui library 2 comments yes it has all the widgets 
i expect and so much blue are you sure ?

Shadwold - I don't understand what are you asking, but if you are 
asking if I like mild bleu gui, then I have to say - yes. I am bored 
by old Amiga and NeXTStep grey look - Fedora, Vista, Windows 7, FaceBook 
login-page, all got it right ...

From rm-asset.com website - "# R3-GUI Library: Our internal extended 
and enhanced VID. We add a persistent layer so that GUI elements 
can be stored into a database backend. Further we added element-tree 
traversal code to simplify accessing GUI elements. Beside this we 
develop a bunch of GUI styles like TABLE, DROP-LIST, DROP-TREE etc." 


What's persistent state for GUI good for? And also - why the element 
traversal code, if we can use path in gobs and their "panes"?

isn't it a bit of an overhead for a GUI itself? I mean - those are 
application (higher) level issues, although usefull ...

No, because every GUI style can load/save itself. Such emitters just 
need to be done once. Every gui element belongs to a record. So, 
it's easy to say: save customer and that's it.

Yes, we are doing the first basic styles to create our internal apps 
we need. As soon as this is stable and proofed to be useable, we 
will release the GUI lib.

isn't it a bit of an overhead for a GUI itself? I mean - those are 
application (higher) level issue

 - actually no, they should not be that, and this is quite a misconception 
 that you want this level of control in most apps.


It's what prevents us from creating complex forms in minutes, where 
you don't have to think much about how the form interacts with a 
database.


When you think of it, most of the code you write, when writing boring 
business apps, and beyond writing styles, is writing, and worse: 
debugging and testing such code. Wouldn't it be nice to have this 
built into the GUI, all debugged and tested for you?

pekr, if we have 10 GUI frameworks its a good thing.   each one adapted 
to different needs.


its also a good way to attrack new developpers.  look, this language 
has several complete GUI layers.

I'd even like someone to build a native OS GUI extension.   some 
people *require* that for their work.


RT has one it advocates directly, but any others are a boon to the 
language.