World: r3wp
[!REBOL3 GUI]
older newer | first last |
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. |
older newer | first last |