AltME groups: search

hoping for some help. I copied my desktop view install to a usb pen 
drive for my laptop and made the mistake of not doing an install 
so now it does not see my local dir.I used regedit to delete all 
calls to view I could find rebooted and still the same problem :( 
Any hints ? Thanks !

and also very precise View documentation - just go to rebol.com docs 
section

Pekr,  I need the other VID guide for the REBOL2 DocBase pages but 
the only one I have found is a VIEW guide http://www.rebol.com/docs/view-system.html.
Are you sure another and updated VID guide exists ?

you mix two things - vid and view ... the best doc for view is view-system. 
As for VID, there are just those two links present here. In other 
words - if you can't find it on RT's site, it probably does not exist.

Those 2 guides are both from 2001. So VID has 2 guides and VIEW only 
one updated in the year 2005.

I more and more often feel, we need at Style Guide for REBOL. Not 
for the source, Carl have already written about that in the Core 
guide, but a guide to user interfaces. What key combinations should 
mean what? Should labels for fields be left- or right-aligned? etc. 
I know, many of these things are different in different operating 
systems, but we build applications, that can run across many OS's. 
So I feel, we need at standard guidance to do these things.

Agree? Disagree? Comments?

Maybe we should put a group together to figure this out? Or is it 
best, if one person do it? We also need input, ideas and viewpoints.

imagine a preferences window like in Amiga MUI: The left side is 
a list. The right side is a set of switchable panes.The bottom would 
be functioning OK/Save/Cancel buttons  If that is available as a 
standard window type with all the mechanics for switching, so you 
only need to fill out the list in the left side with titles and some 
GUI elements for each pane in the right, and then be able to use 
it.

I may be biased ... no, I know I'm biased.  I'd start here;
http://developer.kde.org/documentation/design/ui/index.htmland

http://developer.kde.org/documentation/standards/kde/style/basics/index.html

of note;  http://developer.kde.org/documentation/standards/kde/style/basics/badInterface.html

I remember seeing the GUI/Program builder for the NeXT computer, 
when it first came out. That seems awesome. You specified, what type 
of application, you needed to build, and voila you've got the sceleton 
with menues and everything. Maybe it's something like that, you're 
after, Henrik.

It's a bit like that (XCode for OSX does exactly the same thing, 
BTW), but I think it's on an even higher level. Where XCode and its 
predecessor gave those easy hints at first, when you got your window 
and user interface elements, then you needed to know next how to 
connect the dots. The trick is to learn that, and then it's probably 
easy, but after following several tutorials, I'm still lost. It's 
actually a bit like in VID in R2 when you suddenly must learn about 
FEEL and the various CTX-* objects in order to understand what's 
going on. I'd hate this sudden jump in difficulty to be present in 
VID3.

I think there is to much emphasis on building super easy and fancy 
interface builders. Then when you need to code, you go "OK, now what?" 
and all the time advantages are out the window.

that depends on how big they are and how well they are put together.

Basically you have to construct the whole row as 3 separate faces 
and keep appending them to a much larger face.

Thanks to all of you for your input. That definitely puts me in the 
right direction (and keeps me from wasting any more time with "list".) 
 This morning I took a look at Carl's #29 cookbook and at least there's 
a fast way to get closer to what I'd like. I really appreciate your 
support.

yes, use insert-event-func for that and detect on event/close.

Rebol2  Console can be drag destination:  http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=sys-port-drag-accept.r

Rebol3 can be drag destination on view (drag.r example in rebol3 
alpha) :  http://www.rebol.net/builds/rebol3/alpha/rebol29904031.zip
and  http://www.rebol.net/r3blogs/0098.html

About drag source look  at  http://www.rebol.net/cgi-bin/r3blog.r?view=0098#comments

2.7.6 test versions are available and have library freed.

Were testing the final beta now and you should have it very soon.

Hello ! Is use the halt function to stop  to freeze my graphical 
app and open Rebol console .How can I close the console to return 
to my app ("quit" close the app too) ?

how do I convert an %image.jpg to to a height of 100 and a cropped 
width of 200 ?

say I have 1200x 5000 adn I want to resize proportionally to a height 
of 100 and crop widht to 200

If your height is 5000 and you resize to a height of 100, your width 
will be less than 100, if it initially were 1200!?

So you just wanna resize height, and not width in the first go?

If i1 is your original image, you can do:


i2: copy/part to-image layout [origin 0 image i1 as-pair i1/size/1 
100] 200x100

This will resize height to 100 and crop width to 200.

do http://www.hmkdesign.dk/rebol/thumbtest/thumbtest.r<--- try this 
and you'll see it.

(and that's why R2 DRAW is largely worthless for creating thumbnails. 
R3 is however very good at it. :-))

Calling all gurus: Now that the R2 mezzanine source is in DevBase, 
we can fix VID2.


Anyone who has developed extensive patches for bugs in VID2, we could 
use your help in fixing them for real. Particularly since any fixes 
might break your patches - we really want to avoid breaking existing 
code when we don't have to. We need input from anyone who understands 
VID2 well enough to know what is wrong with it. We will not be changing 
the basic semantic model of VID2 though - that's what RebGUI and 
VID3 are for.


Anyone who wants to help, join the R2-Beta world if you haven't already.

I would like to participate but an not sure what to turn to: for 
now I am using 2.7.6 and only have a couple of quirks.  Is there 
a link to dev base?

I could emagine parsing the xorg.conf and look for the font paths...

And what about the system fonts for rebol? Will these be ttf one 
day...or is that moved to R3 finaly?

For reasons I don't understand .. it stopped working and I didn't 
have time to debug it.

because its a nice competitor for altme..(its code is open and adjustable 
;-)

But LNS at present can't act as client and server whereas some of 
the things I was doing was using exactly that .. acting as both client 
and server.

Hello... I have a general question about the relationship between 
REBOL/View and the ever-evolving-and-ubiquitous HTML-browser...

REBOL/View targets the native widget set of the host and tries to 
provide a platform-independent experience, based on a more abstract 
definition of interface.  This seems to be somewhat redundant with 
efforts like Firefox, Opera, etc.  I curious if REBOL/View would 
be better implemented by targeting an Ajax-like browser that already 
lives on the machine... or if there is a compelling reason not to 
do it that way.

And they seem analogous.

First - REBOL does NOT link to native OS widget set. We have general 
gfx objects (faces in R2, gob! in R3), and their events. View builds 
complete gfx engine upon it. Kind of XUL for Mozilla, before they 
gave up and linked to native widgetset?

It sounds like you are saying that REBOL, like the Qt library, abstracts 
the widgets and goes to more of a "give me a window and a graphics 
surface and I'll do all my own drawing and event management"

My friend told me - I work with Python, and I can use Tk, Wxwidgets, 
Qt, etc. bindings, while View (VID2) still has many deficiencies. 
And he is right, although partly. We are trapped in our own cave 
- we liked VID/View, for its simplicity. But we were not able to 
provide complete styleset for all those years, because VID2 would 
require complete rewrite (non OS compatible focusinga layer, missing 
rich-text, etc.)

Yes, I have my own opinions of how to do this right and of course 
I don't think W3C is doing a terribly profound job of it.  :)

Later on, guys improved situation a bit - including cool AGG vector 
library into View ... (www.antigrain.com ). This is really cool and 
puts Cairo into trashcan (which is what they should do in the very 
beginning, except the Mozilla politics)

Seems REBOL could get smaller by embracing that, and becoming a web 
server on the local machine... plus this would put web server capability 
and web forms native to REBOL...

Next move on our part was supposed to be browser plug-in. And it 
was partly done. You can probably find it via rebol.net and install 
- both IE, NS type plug-in, Windows.

And I still think, View can be used for the good. You can still replace 
it, but maybe we've got some advantages here:

View now switched its compositing fully to AGG, and it got something 
like 20x faster in some areas.

We've got rich text, and we are at third prototype of VID3 - completly 
new beast, which will remove all obstacles with found with VID2.

I would wait. In the end, the problem is elsewhere - we need more 
ppl. Then some group can start to wrap Qt or WxWidgets and the point 
will be moot. But View still can find some nice usages. I will use 
it for our next kiosk project anyway.

However - you are absolutly right - no matter how non-realtime web-apss 
are (it is still a joke, ajax non ajax), it is where the world goes 
imo, and this is why Reichart choosed web as a Qtask front-end imo

Oh, I'm sure it is quite useful, I am only saying that given current 
trends I would think it should be moved out of the core download 
and that the core download should function on being a web server 
and using the browser for interface.

e.g. that would be a profound and compelling smart R3 decision in 
my view

Re browser inside  I'd like to see that;  I've been playing with 
w3m -dump to get formatted text out of pages into a View app.

Brian;  Some work has been done on BiDi


And this post got pushed up from Core yesterday.     REBOL is an 
awesome Webhosting language today.


Brian; Look to Cheyenne...  It's a showcase REBOL product.  Using 
its embed technology, in theory, a website with server can be a single 
REBOL script.  It's a Go Doc Go! example of where skilled REBOL really 
shines. 

http://softinnov.org/cheyenne.shtmlbut look to the !Cheyenne group 
here for  updates http://softinnov.org/tmp/cheyenne-r0918.zip


Just so ya know, I'm a real Go Doc Go! fan of Cheyenne.  Running 
on GNU/Linux ... webhosting from anywhere ... just nice.   Go Doc 
Go!   :)

noone prevents anyone from doing so. But what is going to be the 
end result anyway? And end user app? You could not choose worse environment 
for corporate app than web site.

look at - php (other), db on the server, js, xhtml, xml, css on the 
client ... what a mess. We are trying to push web where it never 
meant to go. Fixing layers upon layers by adding yet another layers 
and excuses for not functioning realtime on my Core 2 Duo 2GB PC 
:-)

Pekr: yes, I am looking at Qtask's source and pondering it, and the 
main thing I'm pondering is why they are doing that platform work 
and it's not built into REBOL and reviewed by more people.  I agree 
with you in some ways that the HTML lowest common denominator means 
that the apps you end up with seem crippled/slow/bloated... but we 
also have to look at facts.  Right now AltME is running on my OS/X 
and when I compare it with Qtask, it is AltME that seems crippled... 
despite greater access to the machine...

In fact, it doesn't have a title bar, and I don't know why.  I resize 
it and as I resize I drag a rubber band and only see the effects 
of resizing when I release the mouse.  It is actually somewhat slow 
to start up compared to the browser...

In the meantime, the browser reflows everything per mouse move... 
looks clean, stylish... Qtask is innovating with the way it looks 
and they pull it all off in HTML/javascript...

Mac View was never on par with Windows one (minus resizing effect 
- weird on Windows too). Don't be afraid, I know the facts - I work 
as IT manager for semi-large pharma company here, and no REBOL here, 
I am not insane (yet :-)

Fork - but - you are discussing inefficiencies of View. Once they 
are fixed with View/VID3, all you have to compare is source code 
... and then the difference will matter, once soem js library is 
easily bigger than rebol core itself :-)

AltMe is "bad", because it is VID2 which does not respect some OS 
native behaviour. I say it for ages - ppl can forgive different look, 
but not different app deployment and usability.

OTOH - show me easily some app out there, which will let me chat, 
share, calendar, checklist, buglist, like AltME. There is plan for 
Altissimo - extensible platform. And I say - platform, not an app. 
The best REBOL app is REBOL/IOS ... but I am not sure who could invite 
you to visit such server ...

And just don't tell me - Qtask ... it is not there - it will never 
be so fast.

Pekr: well, y'know, it's not like x86 is anything beautiful to look 
at, but it just got defined and hammered on... eventually PowerPC 
got beat.  I do agree with aesthetic arguments, yet it depends on 
which area truly interests you... I know what goes on deep in the 
heart of my intel processor and I guess I sort of accept it because 
it's too far down for what I see... if it works, it works, and I'll 
replace it if someone has something faster.  But if a thousand monkeys 
wrote a better book than shakespeare, I'll read the book the monkeys 
wrote.  :)

My experience with the web is the more complex trhe page the longer 
the wait. There are sites I avoid because I hate the wait...and the 
browser seems to bog down the whole system. Rebol apps for me are 
instant. No waiting and they do  not bog down my system.

Amacleod - the biggest problem of View is the need to install. I 
say - as for R3, we definitely need plug-in - then you can do your 
app in rebol and ppl will stear how fast web app can be.

In this example, the REBOL developers would be Shakespeare, and the 
Intel chip developers (PHP programmers, etc) would be monkeys.  :)

One aspect of the new "reality" is that your computer always has 
a web browser running, it has to.  So any comparison of REBOL and 
a web browser you have to do is to run REBOL * in addition to* the 
browser.  Not fair, just true.  Performance-wise, how quickly the 
app starts up or not doesn't matter anymore... you've paid the startup 
cost for Firefox (or whatever), you've got the code pages in, they're 
there you have to live with it.

so, simply put - forget View - that is for us, long time rebollers, 
this is our toy. Now let's integrate core into browser and use such 
bindings, like others do ...

Noone said View is going to be part of the core! I would like to 
send you to R3 architecture page: http://www.rebol.com/rebol3/architecture.html
, and as you can see, all RT is responsible for, is platform agnostic 
rebol.dll or rebol.so, which you can statically or dynamically link 
even to something like Delphi.

My preferred way will be R3 browser plugin. Because ppl accept small 
installs, if deployed well ... and "well" means browser here :-)

Yes, well, the main download includes it... and starts up with it... 
I just mean to say that whatever it is that's the small download 
off the site that new users are encouraged to grab and comes with 
standard features would fire up a browser... e.g. even the console

Simply put, what I say for few years - web browser is not browser 
anymore. It is a "container" for various technologies, and it will 
become central point of app development in the future.

And already showing off a lot of stuff the rebol console *isn't* 
doing.  The browser is the platform, windows API + Xwindows API + 
Carbon/Cocoa are headed out... http://blog.pavlov.net/2008/03/11/firefox-3-memory-usage/

Anyway, just wanted to put forward these ideas.  I am looking at 
what Qtask has done and getting a grasp on their methods... was just 
wondering if there was any push to make those methods more mainstream 
as a replacement for REBOL/View in the standard download.

Well, watching what you type and suggesting things you might try 
in pretty out-of-band places, being the most prominent aspect.  :)

If they wanted to, they could make that console take up the whole 
screen, and put a button there to let you do so.  The browser would 
allow it.

So you never probably tried rebol reflectivity and self inspection? 
:-

The language is not the point, really, just the point that if new 
users downloaded REBOL and got something like that instead of a REBOL/View 
window, they'd say "oh, snap!"  :)

so what do you prefer? Getting rebol console not knowing what to 
do, or getting simple console with "Type desktop to start the Viewtop." 
and visiting visual world with plenty of examples and demos to run?

Well, point being, I don't have a whole lot of use for REBOL/View 
because I don't care for native apps.  And as far as I'm concerned, 
REBOL could drop windows and mac support for REBOL/View and just 
run in a virtual linux machine with a lightweight X-windows.  I'm 
a big believer in VMs.

(and letting those VMs do the work, rather than port: http://hostilefork.com/2007/11/03/virtualization-and-the-integrated-circuit/
)

(Nice thing about making your "one version" linux is that then people 
can download pre-configured VMs with the software installed and not 
worry about licensing of windows or os/x )

In any case, thanks for listening... again, I'm just trying to understand 
the direction.  It sounds like you're suggesting a distribution of 
REBOL could be made which did not include bind to the host's native 
GUI but targeted the browser/server/UI and had dialects for that.

PHP is a nightmare and got popular because they made it easy to write 
web apps.  Er, at least easy to get started with a hello world web 
app, and people pushed forward from there.

If I got some Finnish hackers and gave them a task to hack into my 
gmail account vs. my AltME account by watching my wireless network 
traffic, would you bet $10,000 that they'd hack Gmail first?  :)

Well, don't shoot the messenger... as I say, I do believe in good 
native apps, just don't think it's where REBOL can "win".  Of course, 
success is up to each person to define.  For some it means making 
the thing the way they wanted it, and I understand that notion well.

Programming is not all practical, some of it is art form, and people 
have different ideas of what makes "good art".  One person will like 
the forum chat that is 2KB of source because it is 2KB of source, 
even if they can't select text and then get a right click context 
menu to copy it to the clipboard :)

That doesn't matter to them because of other assessments of elegance. 
 I just feel that my own aesthetics of what is elegant or inelegant 
are being redefined by the likes of Gmail.  I sort of don't care 
how it works when I decide to like t, I use it and notice its nice 
properties.  That gets me to the next question when I assess a new 
development platform, I ask: "how can I make something as good as 
that using your tool?"

If the answer is "you can't make something that good without a lot 
of work, but you can make something else that's not as good rather 
easily!  here's how..."  then my interest wanes, because I am only 
interested in the case of matching the best of breed programs I've 
seen.  Right now those are increasingly web apps.  And I think they're 
winning because of what I referred to vaguely as "leverage".

Too much to read, so the answer to my question might be up there 
somewhere. If it is, just point me to the time of the answer, and 
I'll look it up, but here goes:

Fork, what is in your opinion the benefit of having the application 
inside the browser?

Pekr has an aesthetic argument against the idea that the platform 
of the future would have lots of bloated javascript powering its 
behavior.  I am just being more practical, and don't understand why 
I would care about how much javascript is implementing the UI any 
more than I'd care how big the windows GDI DLLs are.  What matters 
is the dialect... the rest is platform I'm willing to ignore how 
it's done.

I guess we could talk to Reichart and see how much time went into 
developming AltMe. Then we could find out how much time has gone 
into gMail, along with how many technologies are used in each, for 
both the front and back ends. Obviously the scale of things skews 
direct comparison.

Well Reichart believes what I am saying, hence Qtask... I am looking 
at the source and just pondering why they are solving this instead 
of having it be the general emphasis of the REBOL interactive environment, 
in the basic download people get off the web.

If you view the browser as OS, then you also have to take the bad 
with the good. Both FF and IE shut down a lot more than my OS, bad 
pages cause problems, PDFs opening can hang things, memory consumption 
makes me restrt them, etc.

That's Carl's call, and he has strong ideas about how to do things. 
:-)

Having worked both with VID and with some ajax technologies, I far 
prefer VID despite its shortcomings in Rebol 2. VID3 in Rebol 3 is 
a very different beast though and compares more directly with Cocoa 
or QT. It just doesn't compare with ridiculous javascript based GUIs.

As a developer, I prefer REBOL, but I readily admit that REBOL hasn't 
advanced as I hoped in some areas. e.g. the plugin has enough issues 
that a client of mine is having a new UI built in Flash to replace 
the REBOL version we did initially. Of course, the REBOL version 
took very little time, and the Flash version is costing about seven 
times as much.

Many things taken care of automatically.

It's like starting a program with
#include <all.h>
and link it with all.lib.

Maybe the problem is, that it's hard to get a good OS with easy access 
to the needed resources, and only those that's needed? So developers 
look for platforms, where it's easy, therefore the browser.

I am not arguing that REBOL/View should not exist.  And in fact though 
I am talking about how I like Gmail I do currently use Apple Mail, 
a native program, to read and send messages via Gmail's IMAP (usually). 
 I'm just saying that the reason people are targeting the browser 
now instead of native code is because browsers have one of the most 
important features--efficient multilingual text layout in a 2D space, 
with inline images and such.  I can't embed a YouTube video here 
in the text box... if I type in a hyperlink it's not clickable... 
right click can't copy text, etc.