r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3 GUI]

shadwolf
20-Oct-2010
[4017x4]
I think in graphic application the overall look is very important 
 ...
i like the gem like display  of elixir
on you screen what puzzles me is that it seems to have 2 groups of 
gems in relation but without any relation or execution order/depency 
betwin those 2 groups...
i understand this pic can represent an ongoing work ;)
Maxim
20-Oct-2010
[4021x2]
its to program a completely new OS design which was tought of 15 
years before terms like "the cloud" became buzzwords.  In this system, 
there is no concept of cloud as a difference in your day to day work 
and play.


in elixir, you are not on or in *a* cloud, the idea is that everything 
we relate to *is* a cloud.  from the button which you click on (which 
is part of the application's cloud) to the current definition of 
servers that process services.  in fact, in elixir, the button state 
of your application can become input data for ANY other node. be 
it in the app, or within a single integer variable sitting in a process 
queue on a server... its the same interface to link them than to 
create a new thread.  there are basically no differences.
yes, you can have several unrelated sets, just like you have unrelated 
apps or files on your current computer  :-)
shadwolf
20-Oct-2010
[4023]
ok and here i'm lost ;)
Maxim
20-Oct-2010
[4024]
the line between data, process and structure is blurred into one 
and the same system.
shadwolf
20-Oct-2010
[4025x2]
yeah
that like the rebol.org in a potential 10 ... some step forward the 
rebol/desktop concept ... those idea of distributing or lets say 
shared code repository is just facinating ... so much more can be 
done in that scope
Maxim
20-Oct-2010
[4027]
glass v2 already proves the interface can be a cloud of nodes... 
I just shipped my first 400kb glass based app to a client two hours 
ago.


it can scale to 200mb of nodes and data editing people softs' incredily 
lame SQLserver DB setup.
shadwolf
20-Oct-2010
[4028]
nice
Maxim
20-Oct-2010
[4029x2]
although at some point it gets really slow because of the limits 
of R2... it just chugs along never *EVER* breaking about even though 
at some point I've got about 50000 nodes talking to each other.


actually, the only thing that does constantly break a part is everything 
which isn't representable as nodes... like events, and input data 
files which I must read and convert into nodes, which get connected 
directly to the interface.
anyhow... back to OpenGL in R3  ;-)
shadwolf
20-Oct-2010
[4031x5]
ok
i saw your first teapot picture any improvements since then ?
i will try to think this  more  i like the idea of  having a fast 
view uppon rebol script as a view boxed/noded in realation one to 
another. I like the idea of behing able to "enter" those box/nodes 
to adapt them enhance them or simply redefine them. I like the idea 
of sharing pre-sets box and having a synchronised / shared tool box 
.If i design a tool and make it available then in a short time that 
tool becomes part of the hudge collective tool box and then is shared 
to every one.
i like the idea of a splendid scenarised grphical overview ..
boxes aren't tools but they can become tools and tools can become 
boxes to be edited / modified
Maxim
20-Oct-2010
[4036]
wrt teapot progress ...  in many ways its regressed  ;-)


The teapot was a test of how to integrate something into R3's view 
engine safely and without any side-effects.  hopefully some of that 
research will allow us to better hook into R3 with an eventual tiny 
expansion of the gob structure.


now I'm actually building the engine which interprets user data and 
sends that data to the integration I did earlier. 

though its pretty much empty right now.  I'm *just* about to add 
reading of a user built block of data which I convert to low-level 
C structs and then render in HW.
shadwolf
20-Oct-2010
[4037]
then can a recusiv process be the base of the tool creation/collection 
can then those basic bricks be assembled on more sofisticated tools 
 those sofisticated tools being then short cuts to create your own 
software
Maxim
20-Oct-2010
[4038x2]
I'm also beginning to feel like a real C programmer... which is a 
welcome change...
pools become nodes.  so anything that can connect to a node can also 
connect to a pool (which means everything per the philosophy of elixir).
shadwolf
20-Oct-2010
[4040]
hahahaahaha  .... i hate to be forced to C program to do rebol i'm 
interrested in rebol the other languages juste bore me to the infinite 
point ...
Maxim
20-Oct-2010
[4041]
yeah... but its nice to be able to count loops in millions rather 
than thousands  :-)
shadwolf
20-Oct-2010
[4042x4]
maxim the idea is that i don't want to do the box in the box in the 
box in the box  effect ... i want 2 kind of boxes tools and box mainly 
tools are scripted set of rebol function or rebol functions from 
teh rebol standard dictionary
to each of those tools there is a auto generated form that you will 
feel to set up your function arguments
and then you have the boxes with are "user function"  you put tools 
in them and you related them one to another to make them  cooperate
that's basically what i have in mind
Maxim
20-Oct-2010
[4046]
this is known as a "process" in elixir... scripts which build up 
nodes and link them up in a specific way.


tools are processes which have a persisten interface (cli or graphical)
shadwolf
20-Oct-2010
[4047x2]
ok . It's interresting talk but it's been really late i need to go 
to bed ;)
have a good and smooth progression then maxim
Maxim
20-Oct-2010
[4049x3]
in many ways elixir models the semantics of nature better than all 
this pseudo desktop and CS ideology.
yeah... there's still a long ahead of me... though I'm now running 
instead of crawling towards it.
long *road*
shadwolf
20-Oct-2010
[4052]
yeah but i'm a drunken idiot so most of it is too polished for my 
grasp ;)
Henrik
25-Oct-2010
[4053]
now discussing undo/redo management. There is a small spec available 
here:

http://rebol.net/wiki/R3_GUI_Specs#Undo.2FRedo_Management

any input is welcome.
Maxim
25-Oct-2010
[4054x2]
undo-redo must not be window based but application-wide.  it will 
be almost useless otherwise.
though it could have different undo/redo threads which are selected.
Henrik
25-Oct-2010
[4056]
undo-threads, that was the thought, but perhaps coupling it to per 
window is wrong, if you have multi-window actions occuring.
Maxim
25-Oct-2010
[4057]
forcing a 1:1 undo thread to window   relationship breaks up quickly 
when you consider that some windows operate on many threads and some 
threads will require many windows .
Henrik
25-Oct-2010
[4058]
ok, then we would need a different method for coupling an undo context 
rather than in the face.
Maxim
25-Oct-2010
[4059]
best is to have a simple block with named threads... and you force 
people to supply the thread name when using any of the undo/redo 
functionality.


also, undo/redo is best done when its not directly part of the gui. 
  


though its nice when the undo engine is able to speak to the gui 
directly.  the gui must not be the "brain" of the undo..
Henrik
25-Oct-2010
[4060]
then perhaps this could be done:

undoer: make-undoer

view [panel [...bunch of fields...] options [undo: 'undoer]]
Maxim
25-Oct-2010
[4061]
having written  a few, I recommend making it an external api which 
is fully "gui enabled"   this way, undo events can automatically 
call face accessors,  and you can put the undo stuff in the logic 
rather than the gui.   many times, the logic might generate a few 
undo, or none, based on things which the gui can't properly be aware.
Henrik
25-Oct-2010
[4062]
although that specifically implies that you actively need to do some 
specific work to activate undo. I don't like that.
Maxim
25-Oct-2010
[4063]
undo/redo is a pretty complex thing and unless you've got a non-destructive 
dataset, its almost imposible to make it a generic tool that is actually 
stable.
Henrik
25-Oct-2010
[4064x2]
yes, the idea is also that it can be entirely decoupled from the 
GUI, so if you don't want it or want to use a different way to undo, 
that should be possible. the task for undo as I see it is to read 
actions and allow playing them back by taking control of the GUI.
non-destructive datasets: this also implies that the undo engine 
really stores all temporary data. it could be an issue with larger 
data sets, unless it's possible to compress them into changes.
Maxim
25-Oct-2010
[4066]
take the case of a system where the undo crosses the lifespan of 
a window (or a few) how do you undo that?  re-open a new window which 
isn't connected to anything?

it basically has to be built with undo actions at the center.


each action has to be able to handle any gui issues gracefully... 
the gui itself cannot manage that unless its an uber simple gui.