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

World: r3wp

[!REBOL3 GUI]

shadwolf
20-Oct-2010
[3984]
sounds like i'm feuding ... lol well the idea is since GUI is planned 
to evolve then maybe we can start thinking toward that kind of extensiv 
graphical use to see how this can be meaningfull with rebol context 
of writing applications...
Maxim
20-Oct-2010
[3985x2]
even my current R3 Open GL work is to push forward this vision... 
(to make this back on topic  ;-
)
shadwolf
20-Oct-2010
[3987]
Maxim it looks great but it's too open ... in my idea what you show 
with elixir should be part of  it  the "free to add thing" part but 
the other part is we have a set of ready made boxes/items you just 
need to set an execution path and give them some related information 
like position size text etc...
Maxim
20-Oct-2010
[3988]
that's already limiting in my POV.   elixir actually allows you to 
build the system that you describe interactively  (In theory, not 
in practice, since its really not done yet(
shadwolf
20-Oct-2010
[3989]
i like the idea of having a really simple way to look at rebol app 
and then you can edit part of it add new boxes with crazy new stuff 
etc.... it's somehow what we do in text based coding 

but on heavy fragmented project it's hard to have an over view to 
it ...
Maxim
20-Oct-2010
[3990]
I just wanted to show you that there is someone already tackling 
the idea... thoug it will still be a few months before I have any 
R3 version of elixir (the move to R3 and the wait for extensions 
is the main reason I stopped working actively on elixir)... it was 
just tooo demanding for the R2 platform, in just about every way 
possible.
shadwolf
20-Oct-2010
[3991]
problem with this kind of representation as a former small talk extensive 
programer is deeper you go in the specifications more blurry is you 
view ... it's like a melt of lot of boxes everywhere with arrows 
linking them to any direction ... that's pretty hard to handle ...
Maxim
20-Oct-2010
[3992]
it can be.. with some compositing I've done I had hundreds of nodes 
in a single shelf... at some point we would do node art   ;-)
shadwolf
20-Oct-2010
[3993]
maxim it's noted ;) and i appreciate that we have somehow the same 
goal
Maxim
20-Oct-2010
[3994]
(compositing as in Motion Pictire Visual effects )
shadwolf
20-Oct-2010
[3995]
I know I want the basic repitive task to be handle faster... then 
the other probleme is in a function setting a hierachy of calls ....
GrahamC
20-Oct-2010
[3996]
to get the best result need async processes for each pipe in the 
graph
Maxim
20-Oct-2010
[3997]
it goes beyond that... at the purely language level R2 was really 
limiting many things I wanted to do.  view and AGG limitations where 
also very present in my tests.
shadwolf
20-Oct-2010
[3998x2]
this aspect is  not usefull on linear easy applicaitons very straight 
forwarded but on complexe application what comes first can be determining 
betwin a working application and a crashing application
maybe somthing like a popup note  when you passe your mouse over 
the node you have like an insight of the node contents and maybe 
a closer view to the links to arrows
Maxim
20-Oct-2010
[4000x2]
all I can say is that on a theoretical level it scales better than 
any other system out there... because using dynamically adapting 
networks of any kind, the structure has as much value as the rest. 
  the fact that its also visual is just icing.
also because these types of networks presents multiple concurrent 
states, you can do much more advanced problem solving than with objects 
and functions.
shadwolf
20-Oct-2010
[4002x4]
i like the ideal of rebol being able to gui draw iit's own gui ... 
in my opinion most of the interest using rebol hides there ...
then how can we graphically represents it maybe the tree or node 
based representation isn't the best way that's why i want to speak 
with others and get several point of view on this topic ...
one pretty rare feature on illumination software creator is the hability 
to create applications for HAiku OS desktop (fork projet from beOS)
one thing that should be cool to should be the capability to export 
new feature item. Let say i create a splash screen ready to use window 
you just have to provide an image to it so new in my tool box i have 
this new "piece" of ready to use code it would be pretty fun to be 
able to exchange it to others ...
Maxim
20-Oct-2010
[4006]
these are called pools in elixir. :-)
shadwolf
20-Oct-2010
[4007x2]
if those sharable items can be synchronised from a network source 
this should be really awsome... recently i saw google document was 
able to share document editions in live that's cool stuff too for 
an IDE to be able to discuss code and then co-write it ...
i do'nt know if that way is applicable on large script probably not 
...
Maxim
20-Oct-2010
[4009]
with elixir you can build google-wave like concurrent user apps with 
just a few nodes.  then you can wrap them in a pool and just provide 
the pool as the data to another node.


it is even project that we will be able to reverse-script a pool 
and provide its structure as an output, so that you can actually 
share the pool's structure in real time along with the data it is 
linked to.
shadwolf
20-Oct-2010
[4010x2]
sorry i'm trying to imagine using such a tool to write an area_TC 
...
ok maxim ;)
Maxim
20-Oct-2010
[4012]
the reason I am working hard on the R3 OpenGL engine is that I want 
to be able to display hundreds of thousands of things in real-time, 
smoothly.
shadwolf
20-Oct-2010
[4013]
yeah hardware acceleration is the only suitable way for that
GrahamC
20-Oct-2010
[4014]
so this is just to program your dataflow engine?
Maxim
20-Oct-2010
[4015]
people must understand that this effort is not just "for fun" I've 
been reading almost 4 hours a day on average on various topics so 
that the performance will be hard-core, at least the design will 
allow it to be sooner rather than after 15 rewrites.
shadwolf
20-Oct-2010
[4016x5]
maxim in a near futur the APU will lead and rebol should be able 
to adapt to that hardware change fast ... And benefit from it
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
[4031x3]
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.