AltME groups: search

I know we haven't been focussing on graphics or GUI bugs lately, 
but you should at least write the graphics bugs down somewhere.

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

So, do we write View/GUI enhancement proposal? :-)

A View proposal would be good, but we need to compile more information. 
We already have the GUI proposal.

The improvements have been to lower-level parts of R3. The work on 
the GUI made it abundantly clear that the lower levels needed some 
work. We've been doing that work. Part of that is the parse imoprovements 
that we're working on right now, which will help with improving the 
VID dialects.

load-gui 



; area-tc stylized gob -custom widget-

areatc-obj: context [


	stylize [
	
		 area-tc: box [
		
			about: "Area displaying in color keywords in text"
			
			facets: [
				size: 400x400
				max-size: 2000x2000
			]
			options: [
				size: [pair!]
			]
			faced: [ 
			]
		; internal face funcition:
		
		; empty draw block ...
			draw: [ fill-pen red text 20x20 [  "test" ] ]
			
		; events handler
			actors: [
		
			]	
		 ] ; fin area-tc style
	] ; end stylize
]; end areatc-obj
view [
    area-tc
]


 to draw in the end a black text over a background default colored 
 with a shape and color i didn't choosed that's not not not cool at 
 all  too much code for a useless thing and a wrong result.

Carl has some new ideas that will help fix the resize model, and 
we will be working on those when work on the GUI resumes.

I'm frustrated max ... i saw carl working on parse i wanted to take 
that opportinuty to start adapting area-tc to r3  and VID just is 
unfinished not even exploitable to do a starting of a begining of 
a test work ....  i though text instruction as been reformed last 
time carl working on GUI  and that we could use thing like text pos 
[ color1 "string1" color2 "string2" color3 '"string3" etc ...]

The Unicode enhancements haven't made it to the GUI yet. We haven't 
been working on the GUI since spring.

It took a while to even propagate the Unicode and moduule changes 
across the core, let alone the GUI.

we where not talking about VID... just the gob... and did tell you 
that unicode was not yet part of the GUI  :-)

my idea is to offer the user an easy GUI font selector  in viva-rebol 
and having the any fonts he use not disrupts the renderng  i noticed 
really strange effect with fonts on other Os's than winXP things 
rendered  like this :

winXP:
toto: func [ 

on windows 7 was producing 
toto	:	f	u	n	c [

things like that

Indeed VID3.4 is far from done. You can probably use it for a few 
things, like getting a name from a user in a text field or submit 
a very simple form, but not much more than that. To reiterate the 
state of the UI:

- No unicode yet in graphics (when Cyphre gets around to it).
- Resizing acts like a drunken sailor. (Carl)
- Skin is not published. (Me)
- Style tagging is not implemented. (Carl)
- Reasonable requesters are not yet implemented. (Carl or me)
- Layers are not yet implemented. (Carl)
- Guides are not yet implemented. (Carl)

- Better font rendering. We are not taking advantage of what AGG 
can do. (Cyphre again)
- Event system is from Gabriele's VID3. (Carl)
- Many features are untested, like drag&drop. (Me, I guess)
- Proper material management for skin. (Me).
- Many styles are not implemented, especially lists (Me).
- More elaborate animation engine (Carl or Me).
- Form dialect (Carl talked about this).
- More/better icon artwork (Me).


Plus, Maxim has some ideas for DRAW, to greatly speed up rendering, 
but I don't know if they can be implemented.


The overall design of the GUI engine is very good. Whenever a change 
or addition is made, you alter 3-5 lines of code in one place, and 
it works. I doubt the entire engine will be rewritten.


You won't see GUI bug reports in Curecode for a while. There could 
easily be 2-300 reports, once we get to that point.


My work regarding skins is rather big: I need to work out the basic 
styles first, so we have a reasonable way to build compound styles. 
These are being done using a very simple, but pixel accurate GUI 
using plain colored surfaces. This is easier for testing out, as 
draw blocks are small, but as Pekr likes to complain: They are not 
pretty to look at. Once the real skin goes into place, the draw blocks 
will grow a lot.


I would love to see a low-level GOB management dialect, like Gabriele's 
MakeGOB.

i feel  like this being focused on too many targets ( OSes where 
VID exists) make you loose from your sight what are the real interrest 
in coding on one particular OS among the others ..  wanting to be 
too much generic and too few specific gives a bad image to your product 
(that's my own opinion)  if you see port of  other libraries like 
GTK+ or OPEngl  they are ported to act the same way but they include 
 to some very specific plateform related obtimisations and functionalities. 
this should then mean the guy that need a basic set of instruction 
to quick to interfaces GUI forms to a database then rebol crossplatform 
 abilities will allow him to just don't care where his program runs. 
But in some high level area  optimising is 90% of your task  and 
it's a constently evolving task . If we want to bring rebol and VID 
to the Guru level to a solution that make people considere it serriously 
and not like another freak toy for freak kids then it's  obvious 
that area have to be digged up and brought to rebol too

that's thinked to render help documentation in your own GUI  software 
that's not thinked as a document writing tool. you have to use an 
external way to easyly create large formated documentation without 
having to keep in mind the over all markup language

maxim i already long time ago worked in the Markup document creation 
tools with ashley MDP-GUI  and one of the limitation was that you 
could not create the markup data and the at same time see the rendered 
result at same time you had to use 2 separated boxes one for rendering 
the other for "scripting the document"

something that was sorely missing in R2 , and isn't readily available 
in all GUI systems. :-)

My preferences:

- Get it done
- Make it easy to use

- Use R3's existing timer system for long delays, and then multimedia 
timers for the last precise bit

- Get smart graphics people to help with the little details, but 
smart systems people for the overall design

- Make it so easy to use that I, as a non-graphics-person, can write 
GUI apps

brianH yeah ... i always said new VID have to be as easy to write 
as previous vid for non specialist and  it serves even a greater 
purpose the GUI designers area. With easy made gob or panels (windows 
where you arange the gob to be displayed on screen ... ) the the 
designer output source produced with those tools remains easy to 
read.

visual gui editing with row columns is pretty easy to build.

re GUI - I proposed to set-up wiki page similar to Parse proposal. 
We have few request for View kernel itself, as well for VID.

The question is, if it makes sense to jump to GUI anytime soon, without 
Core stuff not being finished to beta status ...

Of course, there is also group interested in GUI - shadwolf, Steeve, 
me, maybe Henrik ....

do we have any date for gui R3 and the beta R3 ?

could we aks for have gui R3 before decembre with Beta R3 ?

Do you need R3 GUI for any specific project, or just to play/learn? 
Because other folks might prefer more finished Core, e.g. Multitasking 
...

I don't know how you can come with an estimate of 2-3 weeks especially 
as the current GUI only works on Windows and doesn't yet support 
Unicode..


Even if it only takes that little, I can't see Carl having 2 to 3 
weeks to dedicate to the GUI this side of the New Year.

I am also not sure, GUI will support Unicode from the very beginning, 
altough many expressed it being a priority. There is a difference 
between GUI and VID. Carl worked on VID. Once he is back to it, I 
believe Cyphre is going to be contacted to do some work on View part 
...

A non-unicode GUI beta will nicely establish R3's internationalisation 
credentials.

demo gui not working any more in the new R3-a86.exe !!!!!

** Script error: make-text-style does not allow block! for its font-parent 
argument

** Where: parse fontize do do either load-gui catch either either 
applier do try demo
** Near: parse spec [
    some [
        spot:
        set name set-w...


This error message is kinda weird. What is the content of "where" 
section? "parse spec" can be found in text-fonts.r source ...

Here's the fontize:

fontize: funct [
	"Define text styles (from dialect)."
	spec [block!]
][
	assert-gui parse spec [
		some [
			spot:
			set name set-word!
			set parent opt word!
			set spec block!
			(make-text-style to-word name parent spec)
		]
	]["Invalid font syntax:" spot]
]

A87 helped on the GUI demo at least.

Running from the windows command line: that would also remove the 
side effect that a console would be opened, when starting a R3 GUI 
app from the desktop.

I want to be able to pop up a new console if I need to, but it should 
be a GUI console and I should be able to pop up more than one in 
the same R3 process, in different tasks. Text mode console usage 
should use the text mode console.

External

 doesn't mean it won't be built in to your particular copy of R3, 
 just that it won't be built into Henrik's GUI app.

It looks to me like some GUI functions like 'handle-events and 'base-handler 
that belong inside View are also available in the main context and 
are also listed in the docs. I assume those functions will disappear, 
once the GUI goes into a module.

there is nothing stopping Carl from adding the R2 console back into 
R3.  the current.exe is still a GUI app.

but then the ask is what kind of rebol feet the need of those fone 
(personnally VID would be an awsome way to do animated high sight 
GUI application on fones )

Are the device events the same as GUI-events (meaning the machanism 
is the same or different)

Not everyone realizes that Carl has spent a long time building a 
very strong lever.... might not be pretty... but its damn straight 
;-)


now he's about to give us a chance at holding that lever as a group 
and leverage all the work.  He's been putting all the effort to putting 
the pivot of the lever (the fulcrum) as close to one end as possible... 
so R3 will be very strong and allow to do much more heavy lifting 
than R2 ever could.


now we just have to paint the lever and make it all shiny (gui) put 
a nice handle on it (the host) and even add a few more handles to 
it (threads).


most of that... we can do as as group with a few helping hands working 
together  :-)

Question about R3 GUI. On this page http://www.rebol.net/wiki/GUI_Example_-_Move_a_window
 is an example for moving a window. After moving it with button "Move 
to 100x100" I move it manually to another spot. When I then push 
button "Move to 100x100" again, the window won't move anymore. Is 
that a bug or am I missing something?

For the record; I am using: Windows XP Pro SP3
Rebol3 2.100.94.3.1
GUI 0.2.1

arie, ok. I don't have a solution, but this needs to be looked into 
once GUI work continues. While the Core of R3 has moved forward a 
lot, GUI has not moved in the past year. it could be that a feature 
is broken in the GUI now because of this.

Today I have seen a Wii GUI in action. It has been designed to be 
used with a remote controller.
Also XBOX 360 and PS3 have been.

Interactive Boxes like Digital TV receiver, Mediacenters are designe 
to be used with a remote.

We are entering in an era where mouse and keyboard are no more the 
standard input methods.

To the designers of REBOL3 GUI please consider the new paradigms 
and provide different interaction methods:
- GUI to be used with REMOTE controllers and similar devices

- GUI to be used with the click of the mouse an keyboards and even 
pedals.

- GUI to be used with multi-gesture multipoint touches (either on 
big and small screens)

Animated transitions and some 3D are necessary for a modern GUI system.


GUIs are the basic instruments users interact s with our applications. 
If we give the feeling of a modern GUI 50% of our work has been done 
because they will feel the program to be modern and good, even if 
it isn't. really so.


Our customers are people: specialist and families like the one I 
have encountered this evening. They use Modern Touch based Cell Phones, 
MediaCenters, Remote Controllers and at the and Mouse and Keyboards.

Hope my observations helps.

what can we expect from rebol version for christmass ?  rebol - core 
? rebol - core + gui ? rebol - core + gui + odbc ? rebol - core + 
gui + odbc +plugin ;-)

carl said => # The Core host environment will be released, with major 
updates each week until it is stable, acceptable, and documented 
for initial developers. I'll be "in the cave" until this is accomplished.

# Personally, I'd like to see the View host environment also released. 
This would enable development community progress to resume on graphics, 
the GUI, and also on ports to other systems, such as OS X. Maybe 
some Christmas candy, but no promises.

perhaps => rebol core + gui  for windows and linux ?????????

rebol core + gui only for windows then ???

Robert - I think not. Henrik named few fundamental changes Carl is 
after. You surely remember e.g. frames concept, which was later removed 
for e.g. IIRC, things like - better resizing, changes to layout engine, 
layers, etc. are planned. What is interesting is, that it would take 
imo max 1 week to implement them. So - dunno when Carl is back on 
GUI. As for me, I would not like him to jump from topic to topic, 
which happened today, as Carl is moving to website topic for few 
days. BUT! - I think he just needs break from heavy coding ...

FreePBX (an GUI for Asterisk) is building an interface to freeswitch, 
but the code is a nightmare

If there's one thing I always have running on my monitor, it's the 
browser. I don't see much need for another GUI, including /view

It's exciting.. i'm sending javascript back to the browser via the 
websocket to be eval'd.. the browser just became a killer GUI

yes, so hopefully you can now understand, why I objected to your 
(taken from Project plan) words: "Also, this list is only for R3 
core operation and does not include community-based projects such 
as graphics, GUI, protocols, documentation, and other features that 
can be developed externally, depending on the needs of the community."

and I use it also on the R2 and R3 pages for GUI images, that I serve 
locally, as you have seen.

BrianH: "and leave the periferal stuff to other people" - I know, 
what I am trying to point out though is, that - it does not work 
(as can be seen with networking). The GUI would not be here, if it 
would not be sponsored by Robert. So I just asked, how much is eventually 
needed, for someone taking the DLL bounty? I surely am not able to 
write it myself, nor are other ppl, but we might be able to collect 
a sponsorhip fee :-)

This tools is maybe better http://technet.microsoft.com/en-us/sysinternals/bb897437
as it has gui as well

I am wondering if I can use this to control various applications 
I have running.  They currently run with GUIs, but I think I should 
use a web service module to control them so that I can run them all 
GUI less.

well, you can still have a gui, but all it needs to do is build URLs 
and confirm the results  :-)

Yeah, we're waiting for R3/GUI/ReBrowser...

btw, let me micro-interview you here: why the hell are u still using 
windows!? especially for development? :)


I consider that GUI are an improvement over CLI that make my life 
easier and computers simpler and more fun to use. I stick with Windows 
as my main platform because I never got used to Mac OS UI (tried 
for a few weeks, but gave up rapidly) and I found the other UNIX 
GUI less "efficient" than Windows. Also I found Windows to be quite 
transparent for my work, it just doesn't get in my way as other OSes 
tend to do, so I can focus on my work and forgot about the rest (especially 
since Vista days, I am now a very happy Seven user).


I must also add that I was an Amiga and BeOS user for more than a 
decade and spent all my college days on AIX, X-Windows and SunOS.

Btw, the embedded mode is for providing an HTTP server to an existing 
app, not a full-featured Cheyenne. If you want to make a GUI app 
in View for just a few simple interaction with Cheyenne, you can 
just #include your View code in %cheyenne.r.

If you want a full-featured Cheyenne and integrate your own GUI app, 
you would have to make it the other way around, which is include 
your app in %cheyenne.r.

Anton did a 3D GUI demo ... useful for that?

Gabriele, could be useful to build a GUI like yours to standardize 
our benchmarks.

strangely he puts the GUI as part of "community projects".

1. Extensions with Callback support: This makes R3 immerdiatly ready 
for the server-side where no GUI is required.

Sqlab, a better console for Windows requires the GUI to be built-in, 
not in extensions. The GUI would be used to make the console.

However, the low-level graphics portion of the GUI would be in the 
host portion of R3, which interfaces the core in similar ways.

What I most want in R3 console are not different colors or fonts 
etc. , but a way to write commands longer than one line, 

meaning that I can define a function over more than one line and 
easily paste into the console.

R2 seems to delay checking and doing the input after all brackets 
are closed.

I can not understand that this requires a GUI.

System admins won't be able to use a GUI console at all - they need 
a version of REBOL they can call from batch files.

This means that we won't be putting off the R3 beta until we reach 
feature parity with R2. In many ways we have already surpassed R2, 
but there will be some things missing in this round (VID). If you 
need those features, keep using R2 for that portion of your project. 
The new GUI won't be compatible with the old ones anyways, so you 
might not want to delay starting migration because you may want to 
rewrite your GUI later.

Just a question regarding GUI: We have GURUs like Henrik, Ashley, 
Cypre, Maxim. II have read that host source is being released to 
Maxim and Cypre. Why don't you build a GUI Team made of all those 
GUYs to push forward the developement ? I think they will make something 
explosive ! Also Gabriele has experiences because he build a prototype 
VID 3.4.

Our main goal would be to build the official GUI for R3, which Carl 
is forming from scratch. Right now it would be a bit foolish to go 
build our own UI to immediately go into competition with VID 3.4. 
It would be double work.

i vote for GUI  team !

And don't count on me to be part of it i'm just an idiot unable to 
understand my own source codes so the source codes from others .... 
too much a challenge

Shake is not good because of LLVM-like low level imo, but because 
of properly Graph based GUI. Now allow us something like that for 
View, and you get-me-interested :-) http://www.apple.hu/hun/mac/shake/shake/shake.html

What's the status of the gui ?  Is Carl working on that now ?  Or 
is it not going to be in the beta release ?  ( as most of us would 
prefer ...  leave it out )

Now soon, GUI work will continue and there are graphics subsystem, 
OpenGL, etc. Enough work for 4-5 people there alone.

if you want to download within a GUI app, that could be the GUI's 
main event loop

well, generally inside a gui .. so that's okay I guess.

so we add a gui event to the thing .. and we work inside of that

fine for gui's, yes

Have you created a GUI to replace VID using open GL yet ?

I was thinking of using net-log as a way to hook into the low level 
activity of the protocol so that I can patch it as needed when interacting 
with a GUI ... eg, for progress meters

Nice ...  I'm looking for a dialected flow control GUI tool too :)

I'm lost in current somewhat fragmented documentation on asynchronous 
networking. Does anyone happen to know of an example somewhere on 
how to do a http request and meanwhile displaying a progress bar 
or just print some progress info to the console? I know I have to 
use a AWAKE handler, but I just don't grasp what to do therein.


Let's say I want to PRIN "." to the console (or draw something to 
the GUI) every 0.25 secs the http request is taking . Are there any 
docs out there on how to accomplish something like that?

You would have to modify the existing awake handler to print.

I don't think you can display a progress bar as the only way to update 
the GUI is by creating a GUI event, and that is not documented yet.

So, in this example of sending a fax http://rebol.wik.is/Rebol3/R3_GUI/Sendfax.r


the net-log function is altered to update the GUI ... but in fact 
nothing happens until all the network actiivty ceases.

In R2 you'd do a wait to allow the GUI to update ... but you can't 
do a wait inside a wait

As I mentioned before ... you can't still update the gui without 
the information on how to create a gui event

No, I mean how do you update the gui while in the middle of a network 
operation ?  The only way to force the gui to change is to generate 
a GUi event, like a mouse click etc but a fake event

I'd say the useful solution in R2 at least is to use a call-back 
like read-thru does, so you solve the issue in the networking code, 
not in the GUI cide.

http://rebol.wik.is/Rebol3/R3_GUI/Sendfax.r

I update the GUI in the awake handler

Yes ... as I redefine net-log in the gui to do the updating, and 
net-log is used inside pro-fax.r

Yes, that's what I'm after, Gabriele. Opening a network port and 
then waiting for network, time, or gui events.

the asyncrhonous stuff is doable only if one start GUI do-event loop.
Quite limited

Not the GUI event loop, the event loop. Which is as simple as WAIT 
port.

Async was pretty limited in R2 because you had to start the GUI event 
loop, which only the View builds had. With R3, even core has an event 
loop, and a lot of stuff uses it.