AltME groups: search

I have to admit I don't get what borwser (you mean like IE FF?) has 
to do with xmlrpc in this case ... and I.. aha this is a GUI app 
you you don't mean that xmlrpc-exec returns imediately (without waiting 
for result -- thats why I ask how you get the resut then) .. but 
that GUI doesn't block while waiting for it

Yes, that's correct.  My gui doesn't block while I wait for FF to 
start up and load the page I want.

The R3 GUI is structured as a mix of objects, maps, blocks and gobs, 
but it is very consistent and not messy.

doesn't work well when your gui code is about 10k long

One of the reasons I don't like code being mixed with GUI display 
elements.

I've got some gui code which I am loading from a text string, and 
then running it.  I am binding it to some local words which I want 
to use and that works fine.

But I also want to invoke functions in the global context and it 
can't find them.  What to do?

this is user written gui code which is why I bind to the local context 
to prevent them doing stuff that I think might be dangerous.  But 
I want to allow some exceptions.

If I knew  how it would be I would prepare more light talk , with 
some cool stuff , only little code and more visual .. like doing 
a gui to post message on twitter all in few lines and typed in front 
of them . I had demo of this when I was preparing for talk

Talks often dont' go as planned Janko. I'm sure you did fine. 


For a less technical audience, I try to focus on how little code 
it takes to do useful things; and how readable that code can be. 
Having some simple GUI examples is important, because normal people 
don't want console apps. For programmers, I emphasize that REBOL 
isn't really a programming language; it's a messaging language. As 
Carl has said "It was designed for the semantic exchange of information 
between people and machines." So it's never REBOL compared to Python, 
or Ruby, but compared to those languages plus XML or JSON.

what about R3 status ? make uptodate  R2 is very fine but i would 
prefer a R3 version with GUI and ODBC or MYSQL ..................;

The R3 GUI is still in development. The database model hasn't even 
been designed yet. You can make wrappers for ODBC and MySQL if you 
want to write the extensions - Robert has already started doing so 
for SQLite. Once device extensions are supported, we can start to 
get to work on the database model.

R3 Status: The beta will come out without GUI, database or (unless 
there is some miracle) SSL.

i just want to see more info and screen on the new GUI  of  R3 (i 
am very curious :-) )

There will be no miracle that will bring the GUI or database to the 
first R3 release - they just aren't done yet, and can't be done with 
the level of community involvement that the alpha releases have engendered. 
Too many critical people are waiting for a beta or full release before 
they will even start to get involved. Fortunately we are on the rapid 
release model, so there is no such thing as a "final" or "full" feature 
set, just the feature set of a particular release.

If you are interested in the GUI, get involved. We *really need* 
non-gurus - the GUI is designed for them.

If non-gurus can't use the GUI, it's a design flaw that needs to 
be fixed.

we non gurus need to wait for the gui .. or is it out now??

There aren't many native changes in R3 except architectural: R3's 
main changes:

- Fixes the off-by-one error for PICK and POKE (and path indexes) 
of non-positive indexes

- Ordinal functions now return #[none] on out-of-bounds rather than 
throwing an error
- Expansion of capabilities of FOREACH, subjects of SELECT

- Datatype conversion changes, mostly minor except to/from binaries

- Removed "features" that were more trouble than they were worth, 
and have been replaced by new features (backported)

- Removed features that haven't been replaced yet (like [throw] function 
attributes)
- Major changes in the port and GUI models and PARSE

The monitor could be headless and run as a service, with a separate 
GUI process that runs in user space.

Right. A lot of software does the split process thing nowadays, sometimes 
with the GUI running in the tray (or whatever the OS version if that 
is).

So, how does that work?  the core service launches a gui app that 
sits in the tray?

the monitor don't necesseary have the need of a gui

the GUI could be another client process

No, the monitor doesn't need a gui

and the gui app communicates by tc to the service?

If you would not use GUI, what exactly would be holding you back? 
You created even basic networking schemes? As for me, I miss fixed 
'call - it is still hugely crippled and absolutly useless ...

I don't do any non gui apps

e.g. for me, RebGUI is a dead end. I talked to Bobik, and he is back 
to VID for simple stuff. There were many changes lately, and some 
things got broken, and it does not seem to be supported anymore. 
As for GUI, I believe that in 2-3 months, you will be able to talk 
otherwise, as Robert wants to move his tools to R3 definitely ...

This Git GUI is not very intuitive to use ...

Git-GUI by Shawn Pearce et al

and it doesn't solve the issue where the function you are rebinding 
actually calls a different function to update the gui

eg.  I had something like this 


button [ get-data ] ... and get-data called another function to update 
the GUI

No, wait a minute... that's what BIND-FUNCS is for. Currently it 
only affects HELLO, but you just need to add all the functions which 
need binding into the block:
foreach window-function [hello get-data update-gui etc.]  ...

About the /into refinement.

I don't bother if internaly, a copy is done or not, while it's faster 
and memory safe (the block must be freed immediatly not by the GC) 

The GC used to have some memory leaks and was reacting too late to 
be useful (especialy in apps with a GUI).
I now it's better now (thanks to recycle/ballast).

you have to do this:

insert clear head gui-table/data a-block
gui-table/redraw

as there is a reference to the data block elsewhere

Gabriele - why not? The chat system is more powerfull than that of 
AltME, and I find AltME usefull, although it has its limitations. 
Once we create GUI for it, it will allow for some nice simple IM 
stuff. Why do you think SlashDot ppl would have problem with it?

BrianH: maybe Carl here is visiting using new R3 based Altme GUI 
client? :-)

I think that we need - plugins, security, gfx, gui, few protocols 
(later some engine like cheyenne inside), well, we need many things. 
Also current implementation of codecs is absolutly useless, no concept, 
just a workaround ...

Two questions:
1.  is there a way to load-gui from local file ?
2. How is unicode in rebol3 working ?  (is it working ? ) :)

Carl - still working on plugins? We were discussin here some topics, 
as concurency (getting something like Uniserve engine into R3 for 
networking along with some good model of tasking), parse enhancements 
(parse and codecs being able to work upon streamed input), back-to-GUI 
topics, etc.

As for R3 and me, I can't wait when we get back to GUI. It was good 
period. And times flies by - it is one year you started to work on 
it. The model is good, we "just" need to finish it and allow it to 
display Unicode. Well, some kernel changes are needed too, but if 
gfx is going to be open-sourced, not a problem ...

Let me tell you... I also want to get back to the GUI, and it is 
not easy for me to work on plugin and related code (which is not 
as interesting or cool).

for example you and me works on the same file at the same time using 
viva-rebol ide and you fill a part of the file i fill another part 
of the file and we both see in real time what the other is doing. 

(for example you do the parse parse rules and i write the GUI  of 
an applicaton things like that)

Yeah, after we get the GUI so we can bettter distinguish the twitter-like 
feeds from the conversations.

I would prefer GUI version. We should also create priority list - 
what should happen after the plugins are released? Release first 
host code, examples? Then what? Move onto parse? Unicode? (still 
things like collation, sorting not supported)? GUI?

R3 could be kind of successfull on devices like my 4 days old HTC 
TouchPro2 :-) There is e.g. special GUI version for YouTube, wrapping 
the service, hence no need to go via browser. I think that we could 
wrap some such services, especially the ones having APIs, as Google 
ones. That would be good showcase for ReBrowser :-)

how much time to get a gui in rebol3 linux and other ?

rebol3 gui for windows is not yet finished !!!! could we have an 
upgrade of gui demo ?

I wouldn't rely on any kind of Gui expectations for a while in R3. 
 AFAIK, a lot to do still.

but i read in rebol.com that a gui for rebol chat will be proposed 
!!! normaly in february 2009 "Resume work on the R3 GUI. The primary 
focus needs to be on styles for lists and tables." (carryover)."

and for MARCH 20009 "The R3 GUI has been running for several months, 
but it needs a few more key components. For example, we can ask why 
the new DevBase (RebDev chat) runs in the console, not in the GUI. 
The reason is simple: the GUI does not yet have an efficient table 
display style. So, although it does have dozens of other widgets, 
a way to display and scroll large message lists is really the key 
here. I will be happy if this can be accomplished this month, and 
we can begin using the R3 GUI for an actual application."

in April Gui must wait for decode and encode for image support !!!!

now this done - that why i ask for an upgrade of gui-load and demo 
and to do it also for other version like linux.

I guess once the plugin architecture is done, the GUI will get priority 
again.

Next time the GUI will be touched, will be a redesign of the layout 
engine, which performs poorly right now.

Then style development will continue, hopefully sometime in July 
or August depending on the GUI situation.

yeah, I am really satisfied with last few months of developments, 
and I think that the community in overall is, as Carl is doing mostly 
Core stuff, and not GUI. R3 is getting more and more robust and consistent, 
although there is still some way to go. I can feel that we are getting 
more R3 fixes per month, than we get for R2 in last decade :-)

Well, if you agree, it is cool. Make a decision and move on - we 
have still tonnes of issues to solve :-) You know - half functional 
modules, no concurrency, no upper layer networking, still no plugins, 
no GUI (and Flash is going to be everywhere by the end of the year) 
... that seems like a really lot of catch-up we need to play ...

We imo need to quickly proceed to Beta. I want to start using R3 
as an R2 replacement soon. I need SQLite and then GUI, but I can 
wait with the GUI.

its just different allows different optimisation of conditionals. 
 neutral? can be very usefull, especially for GUI handling code... 
where you usually don't care for the type, but only if a value is 
meaningfull.

A70 released. GUI demo runs once again ...

Great to see GUI Demo back up...even "text view" demo works now...


I saw Carl made some more changes to GUI not yet included in build. 
Any ideas on what changed?

It should most definitely be an OS thing. It should work like generic 
keyboard input. There would, though, be two kinds of input: One for 
dictation and one for GUI control. The latter might be harder to 
do in REBOL without some OS friendly extensions.

Sunanda, the OBJECT function was one of the language usability tweaks 
we made while writing the R3 GUI code. It is likely that the functionality 
of OBJECT will be added to the MAKE object! handler, at which point 
OBJECT will just be another word for the CONTEXT function. In the 
meanwhile we have already seen the value of it in the GUI source.

The r3 GUI demo code at r3/demo.r offers a Halt when running the 
test but only a Quit in the Demo launcher itself - and, at least 
on Windows XP, it blows out your rebol session - whereas the Halt 
in the demo does not.  Rather annoying as a GUI demo feature ... 
 does anyone have a moment to throw another button onto the demo 
launcher?

http://www.rebol.com/article/0420.html


August plan. No GUI, which is to be expected. Too much work left 
before that happens.

August is short, we are almost at the middle of August. I expect 
some bugfixes, BrianH syncing his module related work, maybe new 
additions/fixes to extensions, I think GUI can wait a bit :-)

>> print "aaa"
Zaøízení PRN nelze zinicializovat.

c:\!rebol\altme\worlds\r3-gui\files\rebdev>dir c:\
** Script error: dir has no value


>> exit

>> call "cmd dir"
== none

>> Microsoft Windows [Verze 6.0.6001]

Copyright (c) 2006 Microsoft Corporation. Všechna práva vyhrazena.

c:\!rebol\altme\worlds\r3-gui\files\rebdev>

>> call "cmd dir"
== none

>> Microsoft Windows [Verze 6.0.6001]

Copyright (c) 2006 Microsoft Corporation. Všechna práva vyhrazena.

c:\!rebol\altme\worlds\r3-gui\files\rebdev>dir
** Script error: dir has no value


>> dir
 Svazek v jednotce C nemá žádnou jmenovku.
 Sériové èíslo svazku je 0054-60D0.

 Výpis adresáøe c:\!rebol\altme\worlds\r3-gui\files\rebdev

13.08.2009  12:12    <DIR>          .
13.08.2009  12:12    <DIR>          ..
02.07.2009  15:38    <DIR>          base

Nicolas, VIEW in its built in state doesn't work properly, so do 
something like this:

>> load-gui
>> a: load http://arkandis.com/images/blog/google.gif
>> b: make gob! [image: a]
>> view b

REBOL[]
load-gui
stylize [my-button: button [actors: [on-click: [probe face]]]]
view [my-button]

If the button is clicked:
** Script error: cannot access start in path drag/start:

** Where: if do-events do-events do-events either applier wake-up 
loop applier wait do-events if view
** Near: if object? event [
	drag: event
	drag/start: where

What do you mean by completness? IMO R3 is more advanced than R2 
already, and we are nearing beta stage =  system architecture is 
in-there, all slots in the right place. Now we need to finish few 
things, for user to be usable as R2 is:


- better console (not necessarily needed, but Windows one is total 
crap and makes experience 40% worse for me)
- fixed call
- network protocols (ftp, pop, smtp, proxy )
- ported DB drivers (done by community hopefully)

- improved parse (needed probably if we want to have DB drivers and 
network drivers done new way, but not necessarily)
- missing CGI mode
- GUI far from beta

I would wait 6-12 months at least with using R3 in production apps, 
particularly if you are betting on advanced high level things like 
GUI. Development could start now, but R3 is not near feature freeze 
yet. Many moving targets and bugs remain. Cyphre is supposed to give 
the graphics engine another overhaul. We are also missing many docs 
for painless porting of R3 to other OS'es.


BTW: Carl has mentioned before that some things are needed for beta. 
I'm not sure the recent blog post is a good indication that R3 is 
anywhere near beta. I read it more like "this is a necessary 3.0 
feature".

If so, it could be, because he wants to remove the GUI from 3.0. 
I know he is going a bit back and forth on that.

remove GUI from 3.0? Interesting - never heard of it ...

It's just my speculation. The GUI can be removed if desired. It's 
going to be a module.

Well, to my mind, the GUI is written with Rebol code (it can be exported 
in a module). The graphic engine (GOBs, draw dialect) will stay in 
the core.
It depends of what you call the GUI.

releasing a REBOL beta without GUI is a VERY good idea.

on my part, once Carl adds either one or both of my requirements 
for the next evolution of extensions, then I can proceed with a fully 
independent version of a GUI written in OpenGL... no need for any 
internal view stuff a part from the image! datatype... not even window 
manager.

the OpenGL GUI will not need view, and if someone wants to make a 
cocoa extension or a windows native gui extension... they should 
not be forced to include view in their binaries.

pekr, once you see what can be done with a 3D engine you won't call 
it crap... believe me.  Apple's GUI is based on a 3D engine, which 
I believe is based on OpenGL... can't remember precisely.  same thing 
for vista's aero which is based on DirectX which also uses 3D.

Max - unless my GUI looks precisely the same on all systems, I don't 
want to use it, easy as that. So - give a call to gfx card and driver 
makers, and try to standardise that :-)

Anyone is free to do anything. What I don't like is early split. 
I think that R3 without View has little sense. Who thinks that Core 
will make it, is imo mistaken. What would be browser plugin good 
for, if it would be Core only - there is no point in making such 
a plugin. And what GUI will we get? Multimegabyte SDL linked one? 
No VID?

OK then ... because VID like methodology of GUI creation is the correct 
answer to go simple GUIs. Remember that JavaFX has stolen some ideas 
from View - just look at the GUI syntax - so close ...

We have to have our own face. The custom GUI is not the problem. 
The problem always was in its behavioral area - we need system compatible 
behaviour and deployment.

for me, the GUI dialect should be completely separate from its implementation. 
 so that one can reuse the dialect in another engine he needs.

Python does very well and it has no native GUI.

I hope there is no underlying assumption that a gui for R3 will make 
it hugely successful.

IMHO Extensions will allow it to be much more successfull than any 
GUI we add to R3.

Just let Henrik build a GUI for both R2 and R3 ...

our killer app lays initially in plugin, and showing world few presentation, 
easy of gui creation, and some real service wrapping, doing a tour 
comparind sources. Wrap OSnews.com, when you post article there. 
Wrap gmail, or later on their Wave, and show the code difference, 
compare sizes, compare speed. And at the end of presentation do a 
bundle - show stand-alone app called gmail, not needing browser ...

I remember how we once tried to do similar stuff, just for the excercise 
purposes, wrapping SlashDot. There were 2-3 versions of GUI wrappers 
available.

I don't understand, what is the fear about - noone is distracting 
Carl from Core work, by View/VID requests. Carl will be back to gui, 
once he feels Core is stable ...

Remember - somewhere in April GUI development was postponed. One 
of the reasons being me asking Carl to listen to the majority, which 
here requested Core work being done first.

Steeve - put it into CureCode ... maybe we ignored GUI related bugs 
for much too long ...

I am trying to do simple CGI tests, using Cheyenne, and in reference 
to following blog: http://www.rebol.net/r3blogs/0182.html

For: http://localhost/show.cgi?test- I do get:

Content-type GE te 127.0 


Why always only 2 bytes? Is that actually two bytes? I would say 
- two "elements"

The code is:

#!c:\!rebol\altme\worlds\r3-gui\files\rebdev\view.exe -q

REBOL [
    Title:      "show"
    File:       %show.cgi
]

print "Content-type: text/html^/"
print get-env "REQUEST_METHOD"
print get-env "QUERY_STRING"
print get-env "REMOTE_ADDR"
print newline

Is that R3 problem, or Cheyenne problem?

I can only say - give us R3 beta release, full featured, give us 
Host source released after 4 years of promisses. Gives us new website, 
give us GUI, give us web-browser plugin, give us Docs, give us seminars, 
consultancy, PR activity.  And then maybe think of the rename scheme 
...

and redoing the UAE and actually Adding new concepts to the GUI instead 
of just making it shiny... vista had no single new GUI concept over 
XP a part for that mini app bar on the right (which sucks sooo much 
energy out of your PC that you can actually notice the speed difference 
when its running!).

Don't worry - a chat GUI is planned.