• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

AltME groups: search

Help · search scripts · search articles · search mailing list

results summary

worldhits
r4wp235
r3wp2632
total:2867

results window for this page: [start: 2001 end: 2100]

world-name: r3wp

Group: !REBOL3 GUI ... [web-public]
BrianH:
13-May-2010
Persistent GUI state will allow an application to save its state, 
be suspended or shut down, and be restored later, all automatically 
in response to system events. Windows 7, Androis and iPhone OS 4.0 
all have facilities for triggering this kind of event in applications 
in response to power management or (for Windows 7) reboots. This 
will make it possible for us to write REBOL apps that will resume 
after an intentional shutdown by the system.
BrianH:
13-May-2010
But I'm not assuming that the R3 GUI will do that immediately, just 
that it will be possible.
Robert:
13-May-2010
Brian, yep, exactly. And it's not only about suspension. Think about 
logging of at one system and again on at an other while taking over 
your app session and GUI state on this system to continue your work.
shadwolf:
13-May-2010
rebol GUI is light weight gob are enought well done to be considered 
as a stand alone entity... So why not trying to get the best of rebol 
doing things like that...
Gregg:
3-Jun-2010
Screenshots are here: http://rebol.hmkdesign.dk/files/r3/gui/

Thanks for doing that Henrik.
james_nak:
5-Jun-2010
Get getting around to checking r3 gui. Does anyone else get the char-size 
needs a value error upon load-gui?
Henrik:
5-Jun-2010
james, it may be that you are running a98 or a99. the GUI will currently 
only run on a97 and below.
Henrik:
5-Jun-2010
Yes, well, currently I need to finish another project, so GUI development 
could be faster, but Cyphre and Rebolek are working on it. At least 
it's moving. Proper resizing is the topic now.
Pekr:
7-Jun-2010
Well, AGG is good enough imo. Our problems imo lay elsewhere - GUI 
incompletness, GUI look (skin).
Pekr:
7-Jun-2010
... and even more deeply ... the world goes HTML5, what do we do 
about it? :-) (I know there is still place where R3/GUI will be usefull)
BrianH:
7-Jun-2010
Hosting Webkit wouldn't help here: The whole point to HTML5 etc. 
acceptance is that people don't have to install another program - 
they can just use their existing web browser. Hosting Webkit would 
only help us if we want to display existing web browser code; it 
wouldn't be necessary for generating code to run in Webkit, because 
the copy of Webkit that people would be displaying your GUI in would 
usually be a separate program, often on a separate computer. And 
HTML/JS/CSS is just text - we can generate text already.
AdrianS:
7-Jun-2010
Brian, my point with the embedded WebKit would be to have an alternative 
gui framework that has the capabilities people are used to from a 
browser. With a non-hosted WebKit (or any old browser), you couldn't 
have very close integration with the REBOL runtime.
BrianH:
7-Jun-2010
Embedding REBOL *in* Webkit would work well. The other way around 
wouldn't help as much, because we'd be stuck with the browser GUI 
model when we don't have to be. People don't use the HTML/CSS/JS 
model because it's good (it's not), they use it because it's there 
already.
BrianH:
7-Jun-2010
Maxim, I don't doubt that it using Webkit in R3 would be useful. 
But it would be useful for other reasons than providing a GUI for 
R3 (the topic of this group) - more for displaying the GUIs of other 
code within R3, other code (un?)fortunate enough to have been written 
in HTML/CSS/JS.
Henrik:
15-Jun-2010
http://rebol.hmkdesign.dk/files/r3/gui/210.png

Demo of pixel accurate resizing.

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


Same as 210, except border sizes for each individual GOB is randomized.
Pekr:
22-Jun-2010
Henrik - any new screenshots to R3 GUI in the pipeline? :-)
Pekr:
22-Jun-2010
Also - with the change to the "box model" and introduction of "material" 
system, will it be any easier to adapt the overall GUI look?
Pekr:
22-Jun-2010
hmm, it seems like Carl is finally cooperating even in the GUI area? 
:-) So, is he liking new RebGUI like resizing model, or not? :-) 
I remember even some discussions in the past, and Carl had his own 
opinion on that. I hope that max-size need is eliminated ... or still 
it is not? :-)
Henrik:
24-Jun-2010
if you can reference strings from outside the GUI, that shouldn't 
be a problem to do on your own. I don't find it generally to be a 
good idea to provide language support inside a GUI engine.
BrianH:
24-Jun-2010
Good, because I've been waiting for the R3 GUI resizing model to 
be finalized before I retrofit the R2 VID resizing patch with its 
algorithm.
Claude:
24-Jun-2010
carl say => With the above renewed effort on the GUI, the priority 
of moving the graphics library to the Host-Kit has jumped up a few 
notches. This is a non-trivial project; however, the next sprint 
is expected to arrive in two weeks
Henrik:
24-Jun-2010
Posted 5 shots:

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


from 212 to 216. I think they need some explanation from either Ladislav 
or Cyphre.
Ladislav:
24-Jun-2010
http://rebol.hmkdesign.dk/files/r3/gui/212.png- this is a layout 
using a PANEL style, elements are layed vertically, (in columns), 
center-aligned, having different (randomly adjusted) sizes
Pekr:
24-Jun-2010
what I don't understand for the gui is, what panel and group are 
layered in different directions - vertical vs horizontal :-) (unrelated 
to resizing)
Rebolek:
24-Jun-2010
I don't like max-size, but the way it's done now, I think, that it 
can be omited from style-writing and R3/GUI can take care of it. 
But that's just a guess right now. There's now code to support my 
guess.
Graham:
24-Jun-2010
Anyone know if one can update the GUI from a network event?
Pekr:
25-Jun-2010
Henrik - so what happens next? Resizing model is incorporated into 
GUI, and then we can see some beta? Or is it still too early?
Cyphre:
25-Jun-2010
Pekr: the new resizing model is not yet integrated to R3 GUI. We 
are finalizing the prototype so it is fine-tuned.  The integration 
to R3GUI part will start from the next week.
Pekr:
25-Jun-2010
as for why min-max size totally sucks. Who tries to predict, what 
is the correct max-size? I linked my notebook to my LCD TV, and instantly 
the gui looked totally wrong, as the resolution went up to 1920x1080 
(FullHD), but field was set to max 900. Carl told me, that fields 
should not be so long. But - I don't want to discuss it with the 
style author. In such a case, I had to adapt the style to "fix" the 
case ...
AdrianS:
25-Jun-2010
Cyphre, is the layout framework pluggable in any way? Could it be 
replaced with a different model? I'm just thinking how layouts are 
done in Java where there are quite a few different layout managers 
available and one size doesn't have to fit all. Here are some options:


http://leepoint.net/notes-java/GUI/layouts/90independent-managers.html
AdrianS:
25-Jun-2010
well, this is what I was asking about - should the GUI elements be 
tied that closely to how they're laid out?
Pekr:
25-Jun-2010
I am not sure I understand what you mean :-) GUI elements in our 
case are not something which is easily encapsulated in its source 
code and hence can be used with different engine, at least I think. 
But maybe I just don't sufficiently undersand, what "layout manager" 
means, so I will let the question to be answered by others ...
AdrianS:
25-Jun-2010
Does the declaration of REBOL GUI elements need to be so different 
from how other toolkits handle them? It just seems that needing to 
have only one way (one layout engine) of laying things out is a lot 
to ask of both the layout framework designers and the users of that 
layout engine.
Pekr:
25-Jun-2010
The only thing I can do right now is to point you to new GUI docs, 
maybe by reading the docs you will understand, how things are layered 
....

http://www.rebol.com/r3/docs/gui/gui.html
AdrianS:
25-Jun-2010
It seems from reading:

http://www.rebol.com/r3/docs/gui/faces.html


that you might be able to define a new "layout" function implementing 
a different layout description dialect to achieve a new layout. Am 
I understanding it correctly? Is this layout description dialect 
specifically what the gang is working on?
Pekr:
25-Jun-2010
Apart from the fact that I can't properly answer your question, my 
understanding is, that the team is working on all aspects of GUI, 
in following areas:


- low-level (in C) - new GUI is based mostly on AGG, some fixes and 
enhancements are going to be done. Carl, and Cyphre probably too, 
is also working on HostKit GUI isolation, so that the GUI can be 
fully open-sourced, becomes part of Host environment, and can be 
eventually replaced


- various GUI subsystems are being worked on - layout, resizing, 
keyboard navigation/tabbing/accelerator keys, skinning/themes/materials, 
GUI transition effects, etc.


- GUI styles - new VID is supposed to be released with some advanced 
styles, as e.g. tabs, grid, hopefully tree too, maybe a menu (dunno 
about that one) 


- some other things come to my mind - browser plugins, video codecs 
etc. - good times ahead once we are there, but first things first 
:-)
AdrianS:
25-Jun-2010
Ok, but does this mean that a new "layout specification dialect" 
would not be able to redefine sizing? It seems that it should be 
able to do so as the sizing of GUI elements is intimately part of 
laying things out.
AdrianS:
25-Jun-2010
I would think that a GUI element's size is relative to the layout 
model defined by a particular layout implementation - that is, GUI 
elements that are being managed by a grid/table-like layout manager 
would resize differently than those being laid out by a layout implementation 
that "flows" it's managed elements or fixes their positions to absolute 
coordinates.
AdrianS:
25-Jun-2010
Yes, the layout implementation is the code that is behind the function 
"layout" in a face, for example. See:

http://www.rebol.com/r3/docs/gui/faces.html


The dialect parsed by this code is specifically called "layout description 
dialect" in the docs. This is different, as I understand, than VID, 
is it not?
AdrianS:
25-Jun-2010
The way I understand it, VID is a superset of the layout description 
dialect. So, to reiterate, if there is such a thing as a "layut description 
dialect" and there could be more than one defined, how come you are 
saying that resizing of GUI elements managed by any number of layout 
implementations is independent of these implementations when, as 
I tried to describe above, the resizing that you should get for a 
GUI element should take into account the "bounds" set by a particular 
layout implementation.
AdrianS:
25-Jun-2010
Hmm, well words in VID that declare the GUI elements, button, text, 
for example, are not layout specific. If I were to change the layout 
dialect, would these not stay the same? Doesn't this mean that the 
VID is a superset of any layout dialect in that it includes words 
for defining layout and words for declaring GUI elements?
Ladislav:
25-Jun-2010
Hmm, well words in VID that declare the GUI elements, button, text, 
for example, are not layout specific. If I were to change the layout 
dialect, would these not stay the same? Doesn't this mean that the 
VID is a superset of any layout dialect in that it includes words 
for defining layout and words for declaring GUI elements?

 - no, this is REBOL, and you can define a totally different dialect 
 than VID, and such a dialect surely does not have to be a subset 
 of VID in any sense of the word
BrianH:
25-Jun-2010
AdrianS, I've worked with Swing and know what you are talking about. 
The equivalent to a Java swappable layout model in the R3 GUI (when 
last I worked on it) is a group style. The "group" and "panel" styles 
are two such grouping styles. More group styles and other composite 
styles can be added. What you request is built into the model already.
AdrianS:
25-Jun-2010
Brian, what you're saying though is that a containing GUI element 
is responsible for the layout of it's children as opposed to delegating 
that functionality to a layout manager. In Java, each GUI component 
that can be a parent can have a different layout manager added to 
it,but it doesn't manage the layout itself.
AdrianS:
28-Jun-2010
I suppose I just had the expectation that REBOL styles would only 
concern themselves with look and behaviour (group acting as a tab 
group, for example) and that layout would be handled by other types 
of constructs in the dialect, the way I'm used to. As for needing 
hierarchies in Java, these are there in the GUI component declaration 
to match the visual hierarchical arrangement and to make control 
of child visibility, event passing  and layout match what you would 
expect to see coming from such a visual arrangement. If similar control 
can be achieved by REBOL in a different way, so be it.
Henrik:
5-Jul-2010
http://rebol.hmkdesign.dk/files/r3/gui/219.gif


Carl's drawing of the R3 GUI/graphics pipeline (posted with his permission).
shadwolf:
6-Jul-2010
see you and i will keep watching the gui part
Henrik:
6-Jul-2010
http://rebol.hmkdesign.dk/files/r3/gui/220.png


220 to 225 shows the resize engine in use with globally set borders 
with quite good pixel accuracy. the border style should be possible 
to set globally according to cyphre in a similar way as in VID, of 
course without the artistic limitations of VID.
Gregg:
6-Jul-2010
base-url: http://rebol.hmkdesign.dk/files/r3/gui/
img-url: func [id] [rejoin [base-url id %.png]]
ids: [%220 %221 %222 %223 %224 %225]
imgs: copy []
foreach id ids [repend imgs [id load read/binary img-url id]]
cur-id: first ids
show-next-image: does [
    cur-id: select join ids first ids cur-id
    set-face f-img imgs/:cur-id
]
view layout [
    f-img: image (imgs/:cur-id)
    btn "Next" [show-next-image]
]
Henrik:
9-Jul-2010
http://rebol.hmkdesign.dk/files/r3/gui/225.png
http://rebol.hmkdesign.dk/files/r3/gui/226.png


First integration test of the new resizing scheme. It looks much 
more solid and accurate, but there are still a few bugs (the partially 
blanked button in 226).
shadwolf:
10-Jul-2010
WAHOUUUU !!!!!!! REBOL GUI START LOOKING LIKE SOMETHING A PRO COULD 
SELL !!!
Graham:
11-Jul-2010
the gui and parser ....
Pekr:
12-Jul-2010
any news on R3 GUI front? :-)
Henrik:
14-Jul-2010
transition shouldn't affect GUI development. it's not like all copies 
of A97 stopped working. :-)
shadwolf:
15-Jul-2010
the thing is draw and so agg can be used on any widget  componing 
VID and that's a hugde constraint

what really sux with opengl are those  half assed IHM interface i 
know glut, x and w32 extension that allows the opengl rendering engine 
to recive user

events and then display  on screen in the particular area set for 
it.


Those interfaces are not 1% as fun as VID... Vid is total flexibility. 
we never did that in vid be you can imagine heavy animation using 
draw dialect on any kind

of preset styled face. I think carl tryed to show that with the animated 
sliding widget when you open a window in his R3 GUI demo.
Graham:
15-Jul-2010
So, one could use AGG for somethings like a GUI and then use Cairo 
for display postscript
Henrik:
15-Jul-2010
http://rebol.hmkdesign.dk/files/r3/gui/228.png


This odd looking dialog marks a few milestones from two days of work:


- Successfully create and open an email dialog created from a single 
style, which represents the content area.

- Successfully validate the content area from the validation information 
stored in the style.

- Successfully display validation result in the content area (the 
letters to the right of the fields show INVALID)

- Successfully block closing it, when it's not correctly filled, 
when clicking "Send" using a new DISMISS reactor.

- Successfully store the content in a way so that it can be returned 
in an object, when the dialog is finished or store a NONE/FALSE when 
cancelled.


The dialog is called by: REQUEST-EMAIL. It doesn't send any email, 
that comes later. The reason it looks odd is because the new resizing 
scheme requires some changes in how sizes are handled in styles and 
I haven't quite figured out how to change them yet.


We'll probably need some more prototypes, but all in all, this is 
a fairly good method of creating complete-featured dialogs quickly.
Graham:
21-Jul-2010
Is this page deprecated? http://www.rebol.com/r3/docs/gui/reactors.html

My older r3 builds don't recognize 'make-reactor
Graham:
21-Jul-2010
>> load-gui
Fetching GUI...
GUI Version: 0.2.1
(Developer test GUI theme)
== 0.2.1

>> make-reactor
** Script error: make-reactor has no value
Henrik:
21-Jul-2010
besides, there will be a rather large extension to the GUI soon. 
it's not a good idea to work on docs now.
Carl:
21-Jul-2010
The lower-level graphics changes from host-kit and pair decimals 
will disrupt only the compositing layer of the GUI. The rest is as 
Henrik noted, unchanged.
Andreas:
21-Jul-2010
Just a quick question to further my understanding: is the Saphirion 
NLPP/Cost Analysis stuff already R3-based, or what GUI framwork is 
used for the Saphirion apps? (Henrik? Robert?)
Henrik:
22-Jul-2010
and yes it was started with RebGUI, mainly because that was the standard 
GUI system to use at the time.
Graham:
22-Jul-2010
Dunno if it's just me .. but often I will get RebGui crashes because 
part of the gui being referenced has not yet appeared.
Graham:
23-Jul-2010
All I can say then is that I do see a lot of rebgui errors if I use 
the gui too quickly
Graham:
23-Jul-2010
If I use the GUI in a sedate mode .. then no errors
Anton:
25-Jul-2010
Henrik, I haven't looked at it, but if I guess right, you mean you're 
considering adding a callback ability to the window close function. 
Surely it would be a gui programmer who would be able to use this 
callback, right? You haven't programmed the close button to pop open 
a dialog for the end-user asking for arbitrary rebol code to execute 
with security off, have you? ;-)
Anton:
25-Jul-2010
Hmm yes. If ever a dialog's close button does not simply close the 
dialog, I'm probably going to wish that the designer had found a 
better way to program the gui.
Pekr:
26-Jul-2010
Any news how implementing command wrappers for AGG goes? Or on GUI 
status in gerenal? :-)
Henrik:
26-Jul-2010
If it's not clear, the GROUP style produces this flow:

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


If you turn that 90 degrees, you'll see that it's like how newspapers 
arrange columns, so I would want to find a familiar DTP term for 
it.
Ladislav:
26-Jul-2010
So, both http://rebol.hmkdesign.dk/files/r3/gui/214.pngand http://rebol.hmkdesign.dk/files/r3/gui/225.png
are examples of the Group style now.
Ladislav:
26-Jul-2010
The http://rebol.hmkdesign.dk/files/r3/gui/214.pnghas LAYOUT-MODE 
set to columns, while the http://rebol.hmkdesign.dk/files/r3/gui/225.png
has LAYOUT-MODE set to rows.
Ladislav:
26-Jul-2010
They are both groups, in the http://rebol.hmkdesign.dk/files/r3/gui/214.png
you can see the columns, in http://rebol.hmkdesign.dk/files/r3/gui/225.png
you can see rows, can't you?
Pekr:
26-Jul-2010
Henrik - by "lines" you mean probably rows, right? OK - what happens, 
if one GUI element in particular row is wider? The whole row becomes 
that wide, or it shrinks?
Ladislav:
26-Jul-2010
http://rebol.hmkdesign.dk/files/r3/gui/213.png
BrianH:
26-Jul-2010
Panel is a good name. All of these are pretty arbitrary when applied 
to a GUI system. Pick something traditional like Group and Panel, 
that sounds nice.
Anton:
26-Jul-2010
HTML refers to this as "inline" (and the line may wrap).
I used 
grid-face/LAYOUT-DIRECTION: 1x1  and  
grid-face/MOVE-FIRST: 'horizontal
in my old GRID style.
	do http://anton.wildit.net.au/rebol/gui/demo-grid.r

But the parameters needs to be clarified some more.

Academic papers published as PDFs often have two columns of text.

That means a single line of text wraps horizontally, vertically, 
and horizontally again.

Eg. The line of text first wraps (horizontal) when the right hand 
edge of the first column is reached,

then, after many rows are similarly wrapped, when the bottom of the 
first column is reached (vertical wrap).

All of that occurs again for the second column (and perhaps more 
columns) until there is no more room on the page,
so the final level of wrapping is horizontal. 

So I would have 
	face/WRAP: [horiz vert horiz]

which specifies three levels of wrapping, horizontal for chars, vertical 
for lines of text, horizontal again for columns (so that the next 
page is underneath the first one).

To put pages horizontally, you would just have 
	face/WRAP: [horiz vert vert]


Or you could specify an extra level of wrapping, eg. so that you 
could have groups of two pages shown horizontally
	face/WRAP: [horiz vert vert horiz]


The direction for each level of layout should be specified to correspond, 
eg.
	face/LAYOUT-DIRECTION: [1 1 1 1]
which would give left-to-right and top-to-bottom.
(Use -1 for right-to-left  and bottom-to-top directions.)
BrianH:
26-Jul-2010
If we see styles like 'red-button, we've failed in our design of 
the R3 GUI system.
Henrik:
26-Jul-2010
Anton, you are free to do that, but it will break the philosophy 
of how styles work together. I think this point is not properly understood, 
but it will move the GUI to the next level, where you spend zero 
time thinking about colors or theme, can properly divide UI design 
between a graphical designer and one producing programs.
Pekr:
26-Jul-2010
simply put - it is not that it would not be technically possible 
to pass any such argument to the style during the construction. It 
is about - we don't want to do that for some attributes, color being 
one of them, because it could ruin overall look of the GUI ...
Henrik:
26-Jul-2010
it's not just looks. deep semantics that are used to make the GUI 
function properly relies on functional styles rather than appearance 
of styles. if you have a red button, the GUI won't know of its importance. 
but if you have an OK-BUTTON, you can tell how important it is, when 
it should be focused and what you are allowed to do with it. automating 
this can cut off hundreds of hours of development and testing time, 
because you don't have to pay attention to those details. the UI 
system does that for you.
Henrik:
26-Jul-2010
proper usage of styles in the R3 GUI works exactly the same as in 
documents that are properly styled. there is no difference.
Henrik:
5-Aug-2010
the R3 GUI does something like that already with a RELAY option, 
but it's cumbersome to use and less flexible.
Pekr:
5-Aug-2010
for cross-linking GUI elements, it might be sufficient, but for overall 
app logic? There would have to be list of possible update actions 
for each element possible change. The system I used in DOS ere had 
it exactly like that. And it worked even with grid for e.g. You deleted 
an item, and the update action was able to update your stock DB item 
related amount. The mechanism would have to be universal enough, 
because if it will not cover enough cases, it will not be used by 
developers, and will bloat the GUI code, as everybody will replace 
it with own version ..
Maxim:
5-Aug-2010
Although I've implement 5 complete GUI frameworks, so far I've stayed 
relatively silent on the R3 GUI front cause I'm building my own framework 
and I don't want to interfere with the R3 system.


but I will pitch in here and say that what Henrik proposes is a good 
idea (I use the same name for a relatively similar feature), though 
it needs one thing if it is to be usable by newbies.


a way for do-face NOT to call attach.  the reason is that if you 
want several cooperating controls, they must not create feedback.
Pekr:
5-Aug-2010
Henrik - one field change might cause change in multiple other places, 
not necessarily GUI related.
Maxim:
5-Aug-2010
my old VALVE liquid system was similar to this and I could easily 
have 30 interconnected controls in realtime, all refreshing, some 
even generating data which where used in other parts of the gui (like 
backgrounds).  so you'd have a control control and the whole "stylesheet" 
would updated interactively.
Robert:
5-Aug-2010
Petr, the app logic shoudl just get a trigger from the GUI (subscriber 
pattern) and than do what ever makes sense.
Robert:
5-Aug-2010
State machine: Not to be meant to be part of the GUI. The reactor 
code would just trigger the state machine than.
Henrik:
6-Aug-2010
Regarding ATTACH, perhaps it's best for now to leave it working as 
it is, as I'd like to keep it. One big advantage of reactors is that 
you can write your own very quickly and not affect the GUI system.
shadwolf:
7-Aug-2010
is it possible to know who work on what in the GUI topic and have 
a slight idea of the steps done and the steps to be done ....
Henrik:
9-Aug-2010
http://rebol.hmkdesign.dk/files/r3/gui/229.png

Text now works in hostkit.
Henrik:
11-Aug-2010
Finally got some usable fields again:

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

Now for some deeper testing of the resizing system.
Henrik:
11-Aug-2010
http://rebol.hmkdesign.dk/files/r3/gui/231.png

:-)
Graham:
12-Aug-2010
did you ever figure out how to create GUI event from inside a network 
protocol?
Cyphre:
12-Aug-2010
Graham: regarding the 'updating GUI from network protocol' question

I have found some older scripts I did and quickly added the progressbar 
to it so you should see how it works.
You can download it from here:
http://www.rebol.cz/cyphre/scripts/r3/net/client.r3
and
http://www.rebol.cz/cyphre/scripts/r3/net/server.r3


just run server and client on localhost and press enter in the client 
console to see how the server shows the progress of upload.
Graham:
12-Aug-2010
Imagine a GUI based on polar coodinates
BrianH:
12-Aug-2010
Complexity is the enemy for the R3 GUI.
Maxim:
12-Aug-2010
R3 GUI would be top-down by default for everything.
Maxim:
12-Aug-2010
conceptually is solves a problem in just about GUI engines out there. 
 and its dead simple to use and understand.
2001 / 286712345...1920[21] 2223242526272829