AltME groups: search

I thought I'd show what I'm working intensely with right now (needed 
a break anyway):

http://rebol.hmkdesign.dk/files/db-console.png


Sorry, it's in Danish. It's the adminstration console for my own 
database engine (very, very different from Pauls engine, so no competiton), 
all powered by VID, Rugby, LIST-VIEW and a home-made database engine 
as well as my own build system. The screenshot is from a production 
system (never mind the word "development" in the window title, we'll 
just ignore that... :-)). The system is 101.2% REBOL based. Nothing 
else but REBOL/View 2.7.6 is used.

The administration program is one of currently 4 programs made for 
the db engine, the other being a statistics program, the third a 
heavily dialected and customizable GUI frontend for the db and the 
fourth is a more rigid and flashy front end for easy readability 
(very much thanks to VID). What's visible in the console drop down 
sheet itself is the result of some db queries, here doing some searching, 
and altering of db records. You talk to the db with a simple dialect. 
I wouldn't call it very fast or anything, but it definitely gets 
the job done and even complicated queries are usually 1-2 lines. 
For what you see in that picture, there is around 200 kb of code. 
Well, that's just what I wanted to say. :-)

Nice looking gui as usual, Henrik.

Is it essential to use muted color schemes to get a decent looking 
GUI ??

Pekr, any update on the ffmpeg wrapper that you commissioned? Is 
it just a gui for the command line tool, or does it do something 
else?

In Hackety Hack (an app that teaches Ruby programming to kids) one 
of the first examples was how to use Ruby to mash up YouTube with 
the iTunes Top 10 music titles. You ended up getting a list of music 
videos for those top ten songs. It was just 5 lines or so and was 
pretty cool. I wrote an article a year ago teaching Shoes (a Ruby 
GUI toolkit) that mashed up YouTube with Twitter to show you videos 
of the current buzz on the net. Something like that is pretty easy, 
takes just a few lines, but the results are actually usable and fun.

r3 GUI ? sleeping R3 sleeping RebCode ? who cares RebPlugin Webrowser? 
dead etc etc etc etc more the time pass and less form as Rebol ... 
And pekr this is your fault not only yours  but  you have a big responsability 
in it...

it's odd because I need to use the password, when starting it from 
the AltME GUI, but I don't need it, when starting from CLI.

I think you may have to start it once via the GUI and enter the password.

Yes, CLI, since I don't have your pass to start it from the GUI.

Give Henrik remote desktop access to the machine for a minute or 
two. Let him start the server once from the GUI, entering the password. 
WNS should refresh. Shutdown and start from CLI again.

If I can make it 100% independent on my GUI library, I could try 
to make a release? It'll require about a days work though.

It does get complex, and possibly too slow, but you may be able to 
patch show usefully for your application.

Check out a patched SHOW near the bottom of http://www.lexicon.net/antonr/rebol/gui/mimic-do-event.r

do http://www.lexicon.net/antonr/rebol/gui/demo-percent-progress.r

with no gui ;-)

Ah oke thanks for the explanation Christian.. Well Yes im using make 
face far more often in bigger programs/scripts where layout i use 
for the quick build of gui's..

I asked my friend about Ruby, Python - as my idea was, that corporations 
should throw out tools like Delphi, VB .... .NET and JAVA are goliath 
... but he told me, that Python has to bind to other gui toolkits 
and that it is not so integrated .... he then mentioned AJAX, killing 
all needs for anything like View ... but - just go and find some 
statistics ... look at W3C and look for the state of support for 
all that MLs in recent browsers - you will find situation quite messy 
...

One thing I love using View for is to make very quick custom GUIs 
for customers who need to carry out special tasks, but have no idea 
how to do it via the command line. It takes minutes to build something 
up (say a simple backup/restore system) and show them which buttons 
to press. It can almost be done right in front of them.


I'd hate having to resort to downloading a 50-100 MB Flash development 
tool or build and compile Visual Basic apps, which, ooops, don't 
really work on their Linux box, and I just need a GUI with two buttons 
and a text field. Also how much system access does Flash give you? 
Can you create/move/delete files?


It's so much nicer to say "Sure, let me do this and it can be done 
in an hour" rather than "I'll have a look at it at home and we'll 
see what I can deliver some time next week."


For those things, it doesn't matter that View doesn't use Aero, Quartz 
Extreme or super fast hardware acceleration to display a few simple 
buttons. It just does the job you need to do.

Not that I would ask a user to use a rotated and skewed gui..!

do http://home.wilddsl.net.au/anton/rebol/gui/demo-virtual-face.r

I'd wish they'd use this perspective twisted GUI stuff more in first 
person shooter games, instead of simple panels you poke with your 
gun or just press a key to activate.

Windows console apps can run on some other platforms as well, where 
GUI support is spotty. They integrate with batch scripts better too.

Well, I want native console mode REBOL to integrate with other console 
mode apps and scripts, and for when I am already in console mode 
and need to do something without switching to a GUI. When I am in 
GUI mode already, the existing console is fine. I need both.

do http://home.wilddsl.net.au/anton/rebol/gui/iterated/iterated-face-drag.r

do http://home.wilddsl.net.au/anton/rebol/gui/iterated/iterated-face-drag-drop.r

Is it actualy possible in view/pro to create a thread or a process 
when using the 'call command? Somehow its fully blocking under rebol 
using this... If anyone has a hint on how to detach a 'call process 
from rebol ;-) let me know...  Im seeking interaction from the an 
/output which should be put in an GUI window of /View...

ctx-viewtop: context ctx-viewtop

do bind [if block? ctx-prefs-gui [ctx-prefs-gui: context ctx-prefs-gui]] 
ctx-viewtop
;do bind [slide-to email-settings] ctx-viewtop/ctx-prefs-gui
do bind [
	use [face][

  face: foreach face prefs-face/pane [if all [face/style = 'tog face/text 
  = "Email settings"][break/return face]]
		face/feel/engage face 'down none
	]
] ctx-viewtop/ctx-prefs-gui
ctx-viewtop/view-prefs

Ok, from RebGUI group, as it's not just related to RebGUI:


I have the following problem from time to time on my system and always 
on the system of one of my testers.


On my system: I start my app, the gui comes up and I click the first 
widget and the app falls back to the console. Without an error. This 
happens as do-events returns.


The same problem is on the other system, but here I only can do one 
click on a widget.

do http://home.wilddsl.net.au/anton/rebol/gui/iterated/iterated-face-drag.r

do http://home.wilddsl.net.au/anton/rebol/gui/iterated/iterated-face-drag-drop.r

When designing GUI elements: Devil is in the details ;)

btw - what had Carl in mind when talking about "VID Revised or Redone" 
and "GUI - to VID or not to VID?"?

rebol of course, and i mean the new enhacements rebol is planning 
async, vid or gui, multitasking (if ever) etc...

GUI will continue to evolve (VID or not )...this is mention in the 
key note..and I think Reb-GUI is supporting it in that direction 
somehow

gui means some extended framework ?

pekr, last one, whats that noise about droping VID for GUI ? does 
RT have plans to enhace current view controls or maybe a more complete 
framework  to develop visual applications ?

You can see that it async as you can download files and transfer 
files while still using the GUI.

I started on the GUI a month ago, and with BEER a week or so ago 
to implement the communication protocols.

Ashley is in the business of building database applications so we 
share similar GUI needs :)

I use Azureus ... a good one ... java based, but fast enough, nice 
GUI

Just watching CArl's presentation now.. where he mentions 'transparent 
windows for Rebol".. I supplied the code for that years ago, along 
with a GUI contest, with zero interest at the time?

Brett, I also grokked Gregg's "turtle" hunting metaphor.  Already 
I have filled more than a page of inspirations from it.  Here is 
a sampling of  my found design patterns, mostly in REBOL which are 
powerful "turtles" which are concrete examples of what Gregg said:


1. View console where a user can type VID/View lines, and hit return 
to see what they do.

2. Using print statements to the console from a View script to understand 
it (so easy to do protytping)

3. Parts of layout.r IDE with Nubs, and you generate scripts (which 
are human readible) from the GUI.
4. The source and help systems built-in to REBOL

5. Arexx for Inter-App-Messaging (I listened intently to Gab's Reb/Services 
talk saying "Arexx of the X-Internet")
6. awk file parsing. (I know Gregg wrote rawk.r a while back)

... "Turtle hunting" challenges us to develop more of these.

So, no way for rebol to use the Gnustep libraries to create a GUI 
?

Graham, well, you could probably build the GUI files using REBOL, 
but that loses another point of GNUstep. It has a pretty powerful 
GUI builder that leverages late bindings in Objective C to build 
most of the functionality of the GUI without writing code.

I think that we have some tests to try with AGG, once we get back 
to GUI :-)

Max - have you heard about Fresco, node based GUI manager? http://www.fresco.org/architecture.html

GLASS will wait for R3, and plugins.   its a decision I took last 
year.  GLASS is also a completely new GUI concept.. its totally different 
in the way you relate to a gui.  


There are still a few technological aspects to the concept that I 
wasn't able to resolve in the architecture itself.  This engine should 
allow non Graphical interface to be applied to any application.

like a Voice driven interface to forms, for example.  but the application 
isn't even aware of this... this is part of the skin itself.

Adobe to offer GUI HW acceleration for all mobile platforms except 
the iPhone - http://www.osnews.com/story/22282/Adobe_Flash_10_1_Offers_GPU_Acceleration_Mobile_Support

I don't mind the concept of 10/GUI.  Looks very interesting.  Whether 
it would be easy to pickup and apply would be another thing.  However, 
a neat concept none-the-less.

Geomol - sometimes I wonder about your ignorance(?), sorry. You are 
very clever guy, so I really wonder, what is the reason to hear argument 
like in point 2) Henrik is right - who is more informed than the 
community members? I remember the time when Carl invited me to R3 
GUI world. You all gurus were there, yet he had to invite person 
like me (causing a noise many times), because of lack of input. So 
what are we complaining to? Replies to blogs are similar matter. 
Just don't tell me, you are not informed.


Te link to beta project plan - http://rebol.com/r3/docs/project.html
was posted here, was posted in November status update IIRC. Twitter 
message says, Carl is working on Host code NOW. Yesterday we posted, 
that Carl reported on R3 chat succesfull separation of Host vs kernel 
and that he is working on MinGw support. The host code is being worked 
on NOW.


So how can you post argument like you posted in point 2)? Isn't it 
a bit ignorant and disrespectfull to those who care to work on R3? 
How much support do you expect? I do care to remind Carl to update 
blogs, we do care to spread info even here, yet you claim "do you 
expect ppl to wait forever?". 


And even more so - do YOU expect anyone to wait for mysterious ORCA 
like project to be closer than R3 is? ORCA actually IS open sourced, 
for many years. How is that it did not bring competing environment 
to R2 at least to date? (not to mention its architecture is arcane 
compared to what R3 provides us?)


We are really small community. Everyone of us, can weight his own 
free time. So now decide for yourself, where do you put your free 
time REBOL wise. Boron, or R3? As for me, the answer is clear - my 
energy goes to project, which currently has chance to be completed 
in close future. Splitting our efforts at this stage can't bring 
anything usefull imo ...

And I for Henrik. He has alos contributed heavily to R3 mainly, but 
not exclusively, to the GUI so his contribution is not so visible 
at the moment.

Or break up the projects into R2 and R3 modules, not so easy with 
GUI widgets.

It's a lot easier for me - I almost never do GUI code with REBOL.

... because, I would not like to see following happen - you design 
some quick solution, which will not cover past VID missing part, 
which will not be easilly addable, and surely you will not feel comfort, 
if ppl will complain. We were there, and the response was - well, 
VID was written in about a week, and why you don't write your own 
one GUI engine upon View?

why you don't write your own one GUI engine upon View?

 ... a valid question, considering a "one size fits all" GUI is hard, 
 if not impossible, to do. I think [small] domain-specific GUI's built 
 on View are the way to go.

well, who started the GUI Design group?

dataflow: me, carl, richard, nenad, max etc were sitting discussing 
this at the devcon, and nenad asked - i don't see what this is good 
for in practice. carl said, i'd just like the gui part of the thing 
- connecting widgets, so how big is liquid? max said at least 20k, 
to which carl said "too big".

 I think [small] domain-specific GUI's built on View are the way to 
 go.

 -- I agree 100%. Better for RT to give us good docs on how to build 
 those, than trying to build them all in house.


but there should be one more complete/robust one, which will serve 
for 

general" app development" -- There is. Today it's called VID. It's 
not perfect, can be very limiting, and has big holes (e.g. no focus), 
but it's there.


I think the point Gabriele made--that this is how Carl works, and 
we have to live with it--is very important. That's not an easy thing 
to do, but I think getting too many people involved will not work. 
I hope there is a small team of technical people, and that someone 
makes note of what has been requested. I don't expect perfection, 
but I don't think RT will ignore what has been said in the past either.

Carl talks a lot about programming the large. I hope this aspect 
fits with the GUI as well, so if we can't get a complete GUI, at 
least give us the solid foundation to build it ourselves.

I would prefer that RT would work on the foundation, rather than 
something quick and sloppy that tries barely to cover everything 
like VID does. We'll help with the upper layers of GUI element design. 
That's not design by commitee, but simply compartmentalizing who 
does what. With R3, I had expected the goal to have as small and 
efficient a core as possible, with the rest being open source. Carry 
that philosophy through with the GUI as well, so RT can do a fast 
and efficient basis for a GUI and let actual artists and GUI designers 
work on the GUI.


This way, if some of us want a serious GUI system, we can build that 
and if we want something very fancy and artistic, we can build that 
too and both will not compete with eachother, but supplement eachother 
instead. I hate to see double work done in such a small community.

Gabriele, I only think there is a matter of miscommunication. Some 
time ago I joined a private GUI design group in here, which was called 
the official one for R3. I can't remember who started it, but a lot 
of people, including Pekr, joined up. So I started working on concepts 
for integrating an animation system into VID. I think people are 
a little upset, because it felt like RT were going behind our backs 
and wanted to pull R3 GUI in your own very different direction and 
disregard the work we did.

Being a REBOLer from a lot of years being not a guru, especially 
in the GUI area and having suggested REBOL to other programmers I 
wish to share with you my pov that, maybe, can explain the situation. 
The lack of documentation and the initial easyness of VID is a deterrent 
for programmers to adopt REBOL. In the last week I asked Anton for 
help with some VID and styles and he wanted feedback from me. He 
did a few things (an analog clock style and some adjustments to his 
scroll-tables) but make up his and my mind about some design details 
is still not over as need, POVs and uses of the same style can be 
very differents with two people involved (with one being the programmer 
and the other a little user like me). Imagine an as small as you 
wish group and try to figure out the time it needs to decide design. 
Put this together with the pressure of not taking too much time to 
release R3 before July and I think it should be clear why Carl has 
to stop asking opinions (after 2 years) and put more time on coding

It would be nice if RT communicated to us in here, we who are very 
interested in working as closely as possible with RT, but cannot 
do work directly on the core, on what it would be a very good idea 
for us to consider building.


Like: "RT thinks you should look at building a GUI system" or "RT 
would like you to build a test case suite for R3" or "RT would like 
you to work on making OpenGL work well with REBOL as a dialect like 
VID" or "RT would love to see you building protocols for this and 
that kind of communication" or "RT needs a very good multithreaded 
webserver, that can handle X users" and have those efforts officially 
endorsed by RT, similarly to how MUI eventually became the GUI of 
choice on the Amiga to build your applications on. Perhaps put out 
hard specs and see if anyone will pick it up.


Right now, many efforts feel like they are there, not because RT 
felt they were a good idea, but because some individuals thought 
they were good ideas. Most of us here speak highly of our own ideas, 
but without much dialog with RT. AltME feels like it's the only non-RT 
effort that is endorsed by RT and perhaps also Cheyenne. Such directions 
would also mean that perhaps a lot of people would flock to the same 
official project, rather than starting 2-3 separate projects.

for some reason, I always thought that once the R3 core was released, 
we would be allowed to measure it, come to grasp with IT.  then one 
or two updates later, we could better see how it might allow gui 
to be worked in.

I would hope that Anton will be included in any discussions on View, 
GUI planning. He knows it inside and out, and has been a great help 
to me through many GUI problems.

I fear that noone will understand deep DF thoughts, and that novices 
extending GUI might feel once again lost, like they were when looking 
at VID internals for the first time :-)

allowing me to use a gui and open it up in OpenGL, activeX, if I 
have the need/resources/time to provide it.  I mean to be able to 
extend the whole engine so I can skin it without needing to rebuild 
100% of the gadgets, etc... many of the things we spoke at the devcon, 
but more too.

I'm just afraid that "programming in the large" will not apply to 
the GUI.

just one last quick note: I think that having a look at MUI will 
be good - MUI resizes buttons automatically to fit the text in, there 
are no absolute coordinates. Someone may think, that absolute coordinates 
are good (bitmap graphic-heavy people), but absolute coordinations 
are PURE EVIL, at least from internalization/Localization POV. And 
if the GUI is not made with internalization in mind from the beginning, 
it's not possible to add it later (if it was, there won't be about 
forty people resing every button in Vista for every language edition 
manually)

Rebolek: i have programmed a MUI like gui engine in AmigaE some 12 
years ago.

but you see, Carl has PITS embeded in his mind... the problem is 
that if you want power in a GUI at some point, some things need to 
be more extensive.  which can imply complexity.

what did this bring you?

1) I clearly feel (in most of people who post) that there is a sense 
of uselessness of the community that needs to be addressed.  I am 
not talking about specifics.  just a general sense of being ignored. 
  for my part, I expect it so am not bitter.  I just hope for the 
best, in any case I can already just use gobs and ignore view3, I 
have my engine pretty much finalised and working within an app.


2) communication FROM RT is insufficient.  having you as an official 
RT person will most probably change that, cause I regard you highly 
in your communication talents.  you genuinely want discussion  :-)


3) more specifically, people do not ONLY expect/want a PITS model 
for the gui,  

4) people want more access to internal without fighting,  


5) it seems to me that the community is not expecting a quick release 
of VID and some have expressed that they'd rather wait a bit for 
it than get something too simple.


6) there seems to be disapointment that RT will be feeding us the 
solution, I think after devcon I feel that a few people would have 
tought it would have been a bit more community driven, but then, 
that could be more my skewed vision.

I would like to be a part of the early access group, but not for 
VID. My GUI experience is founded in quite different environments 
and my input about GUIs would be more along the lines of API cleanup 
and other low-level stuff. For the major design issues, I defer to 
Carl, Gabriele, Cyphre and the other capable people here - I trust 
your judgement.


I would like to help with some of the other parts of REBOL 3 though. 
My main interests are in language design, interoperability issues 
and platform integration, particularly Windows platforms and derivatives 
since that's what I need to use most of the time.

Do we need a GUI designer to join us with regards to the next VID 
implementation?  Would Carl be willing to pay for the services of 
a designer?  I know a few guys who work for the local office of Adobe 
and do interface design for their products.

remember there is also a difference between skinning and actual GUI 
design, e.g. the layout of elements on screen. One can have a beautiful 
skin on an annoying interface. The same goes the other way around.

I'm just thinking about making sure we have identified the current 
use cases and have a way to build them.  I personally have no idea 
what is involved in building the GUI engine so if I am speaking out 
of line, I apologize.

java is extremely slow at gui...an application I used which used 
their layout engine and graphics would take 2 second on my computer 
when resizing the applicaiton.  just for fun, I built the same layout 
in glayout (VID) and it would resize in .1 seconds (on the same computer).

so java really sucks at GUIs.

if R3 is to take advantage of OSX GUI, it would have to be made compatible 
with .nib files, the file in which menus are stored. The GUI is a 
separate file in the application bundle.

pekr, it probably depends on what type of UIs you develop. Is it 
large programs or just smaller scripts with a GUI slapped on? I see 
guides only as beneficial, when developing larger programs.

Four
do http://anton.wildit.net.au/rebol/gui/demo-menu.r

By rolling your own vs platform, I mean on the GUI toolkit level. 
We shouldn't require individual developers to implement their own 
menus, but we should allow it if they want to. That's why you would 
seperate the specification of the menus from their implementation.

both. Gremlins are the cuter ones (if defined by movies).

About gob, i imagine one speaks with customers about the gui and 
uses gob all the time. Sounds not that nice..

So far proposed words:

(gob! face! gfx! cell! atom! layer! vis! sprite! bob! blit! )

the only which really applies is gob! or vis!  others are all pretty 
much non-related.

people you forgot the most obvious and pretty!

gel!

graphic element.


but I don't see the point of the heated debate over the name gob. 
 gob is chunk, a morcel of something.  in this case its pretty precise. 
 its a part of the gui, not the whole gui... and in another sentence 
its also meaningfull... when you say gobs of text, it means a lot 
of text... so in reality we WILL need gobs of gob to make up one 
gui.

Carl did VID as an example and we wanted it being perfect. And only 
lately it was Ashley, who understood situation, and produced separate 
GUI

I can imagine R3 could bring diversity to the GUI. I can imagine 
e.g. GUI for Presentations (as Carl's script) and also GUI for kind 
of Scala product ... we can build Scala "killer" based upon plug-in, 
with various transitions, etc. For such things, something like RebGUI 
is not suited at all.

the bad thing is, that once you decide for your app, you can't migrate 
so easily, as it is not only about GUI, but we often link it to data 
handling logic, its linkage to certain elements, etc.

hmm, if View is small GUI toolkit, I wonder if there is a way, how 
other languages could benefit from that? :-) Tk, GTK, qt, /View :-)

Gab, when thinking about the next generation GUI stuff for Rebol, 
take a look here: http://www.cs.cmu.edu/afs/cs/project/amulet/www/amulet-home.html


The thing that's (was) really cool about Amulet is the usage of constraints 
to keep everything updated. Perhaps a bit what Max has done with 
Liquid. But very nice to use.

what about porting Particles demo for e.g.? Or any other clever measurement 
gui stuff?

I would like View to become new cross platform gui toolkit, as Qt 
is, GTK is, etc., and if ppl would find it easy to use, especially 
to create non-traditional UIs, then actually we will have something 
nice in hadns ... it all depends upon VID completness. I hope it 
reaches at least state of RebGUI ....

I just really hope that new VID will be fully featured GUI system, 
and that it will support most things needed to do larger business 
apps ....

we can link to SDL with Core, no? As others do. We can link to VxWidgets, 
if we wish to, no? View is simply yet another gui engine ....

The cursor demo was done about a month ago, so that issue was solved 
then. Using different cursors is in active use in the GUI.

From my pov, I can already see some things, which are a bit disappointing. 
I represent userbase as any other potential user. And I can already 
imagine typical answer - "you can create your own GUI after all" 
:-)

E.g. - let's look into some VID reference Introduction. Some may 
find it vague, and saying nothing:


By their nature, graphical user interfaces (GUI) are more descriptive 
than they are functional. In REBOL, the Visual Interface Dialect 
(VID) provides an efficient method of describing GUIs. VID is implemented 
as a layer that rides on top of the REBOL/View graphical compositing 
system. VID provides shortcut expressions that are automatically 
translated into View objects and functions. You can seamlessly combine 
VID and View code and data for great power and flexibility.


Whereas for me, it s real jewel, as it introduces me into concept 
of relation of View and VID.

VID is much more visible than pop. For some people, the fact that 
REBOL has a simple declarative GUI is the *only* reason they noticed 
and subsequently use REBOL. I think the focus on VID is the right 
call.

the layout engine can with the use of styles generate a flash or 
javascript gui ??

and if you're running a non-gui app .. any difference?

regarding Henrik's blog, i should note, that being semantic is what 
i was suggesting with my old notes about how r3's gui should be. 
that would give us a great power... but many people are against it, 
so it won't happen soon.

GUI & functions: The only way I think we really can let GUI people 
work on it wihtout disturbing the code is to use a event model. So 
a GUI widget just sends an event to some rebol internal event-handler 
& dispatcher and this calls the app code.

So a GUI could look like this:
	...
	save: button "Save" [signal-gui 'save-contact-record]
	...

And to make it even more "self-contained" we could use:
	...
	save-contact: button "Save"
	...


And the GUI system would send a message of the form [save-contact 
left-click] or [save-contact right-click] etc.

So the GUI designers just need to now how to name the GUI elements 
the app code needs to reference.