World: r3wp

ICarii, what I did, was studying DPaint filling the screen, and then 
figured out, how to do it. It's a scanline filling algorithm. In 
short, it goes like:


- Search left and right for other colors from the point clicked on 
screen. That defines the first scanline.

- Look at lines above and below starting from the end-points of the 
first line. This defines 4 new points to look at.

- Again search left and right for other colors. Make sure, the whole 
area between the end-points are searched.
- Put it all in some list, and continue, until the list is empty.

A good way to test it, is making a lot of vertical lines on the screen 
with spaces in between, and not drawing them all the way to the border 
of the image. Then fill from some point at the center of the screen 
and see, how the filling is being split up into many separate fillings.

ah - i went with a push/pop stack and a 4 point scan

http://www.rebol.com/priorities.html


says 2.7.8 is "(Status: delayed, pending sufficient user-base response 
and contributions related to installation)"


Who can progress the installer?  That looks like it is holding this 
up ...

is the installer problem just under Windows?

I believe so ...

Is it required at all?

Yes, for file associations and the View desktop. R2 View, like AltME, 
is designed for Win9x behavior right now. It doesn't work well with 
Win2k and above.

The installer work has been delayed by Carl - he must have forgotten 
:(

is there any plan to remove viewtop from R2/View? To reduce the size. 
I always use View but almost never used viewtop.
second, there will be viewtop on R3?

No, the Viewtop will not be part of R3. It will be replaced with 
ReBrowse.

Any plan to remove it from R2? It can be loadable from web by a function. 
Not a big issue ofcourse, we just won't need for those public, desktop 
etc. folders anymore and gain some kilobytes.

I'm not sure there are plans to remove it.

There are no plans at the moment to remove the viewtop from R2. It 
actually doesn't take up much space in the program.

Work will be moving ahead soon on the R2 installer. Please post any 
information you have about installation issues in modern Windows 
versions (or links to sites with such), or about equivalent file 
location issues for other supported platforms. This will affect placement 
of the program, user-specific placement of the viewtop files, and 
(on Windows) file associations. Windows needs 4 installation profiles 
- let's hope that things can stay simpler on other platforms.

Any news here?

Not yet. Since Thursday, i have had no time to program. Since noone 
has yet posted any links or issues, I'm assuming that there will 
need to be research cheduled for this task first. That can't happen 
until the coming week.

Carl is not working on the R2 installer right now. For the moment, 
it's just me.

Volunteers are welcome, particularly for the non-Windows platforms. 
I only have experience writing installers for Windows.

Where are the issues posted to?  Not curecode I presume ...

Here. I asked for them to be posted here. Noone answered.

But it's still early yet, maybe people didn't notice.

I'm on linux and haven't been using View 2.7.7.4.2 because it crashes 
too easily with DRAW, so I'm still using 2.7.6.4.2.

(I'm assuming that will be fixed pretty quickly, however.) The biggest 
annoyance for me is the lack of DRAW text rendering.

It's been so long since I used the installer I can't remember any 
of the issues with it!

As long as "continue without installation" button works, I'm happy 
with current installer.

do people actually still use viewtop?

I use it regularly for deployment.

yes, you can run viewtop from console

ah ok - i built my own installer back when i used to do R2 deployment 
for people

I could have done that, but the viewtop solves the job OK.

i found it a little clunky - but i was probably using it incorrectly

it is clunky and awkward, true.

most clients were more interested in auto-install / single-click 
jobs with a desktop icon / registry linking

I don't care much at all about View installation on Linux, as long 
as directly invoking the binary with --noinstall continues to work.

I prefer it always runs as standalone console, even at first time. 
If user wants then he/she can INSTALL or starts DESKTOP.

So I can send rebol.exe to anyone and tell him just drag & drop that 
script file onto that exe file.

I just wish there where a version without sandbox.  its VERY annoying 
to install, on vista it took me a full evening to get it to work 
using -qs properties.

Not a version without sandbox/install, a *mode* without sandbox/install. 
It's one of the 4 profiles.

I just want rebviewpro.exe to be available as well as rebol.exe. 


 the installer is a nuisance, why should /view require one while /core 
 doesn't?


I'd much rather have no install and have a mezz or native command 
I run in the console that does an "install"

Which it why it will be supported. The installer is a nuisance because 
it wasn't done right.

Hate to break it to you, but the desktop is actually used by some 
and either needs installation or portable app mode. Console-only 
no-install mode, two install modes depending on permissions, and 
portable app mode, that's the 4 modes.

its a nuisance because its not required.  the desktop is fine for 
end-users.   I'm not one of them, and it gets in the way when I deploy 
my pplications at clients.

just the fact that we've got two intepreters using the same extension 
makes the whole issue even worse.

really, there should be two executables.  One which does all of that 
fancy stuff, and another which just doesn't do anything.  no install, 
no security.

two intepreters using the same extension

 - you mean rebview and rebcmdview? Core doesn't set or require an 
 extension.

R2, R3.

but cmd and normal too.

I'll check about the viability of the multiple executables model, 
but it looks like installation-related rebol.r settings are more 
likely.

my point is that install is very annoying for people who develop 
because it creates a dependency in the interpreter which cannot be 
rooted out.


I am not against the installer, i'm just against it being forced 
upon me, when the whole platform itself has no requirement for it


I have not started REBOL without it requiring an external file or 
socket in what 10 years... so really what is the point.  it just 
makes EVERYTHING complicated, like telling clients they have to fuck 
around with adding -qs all the time in their batch code, etc, etc.

vista doesn't even allow arguments in shortuts, so that's even more 
annoying.

Which is why the rebol.r settings.

hey, if the executable can reliably read rebol.r, then that's cool. 
 its also MUCH simpler for networked install, since you can lock 
down the permission on rebol.r so that every one launches the same 
way.   if we really need user.r... then just provide its path within 
rebol.r and load it from there.