World: r3wp

I thought Gabriele made it to work?

with R3?  I don't believe so ...

but I don't know.

I think he did make some parts work, but not the whole thing.

BrianH: are you suggesting, that because of VID3.4 work, we will 
see some changes to core? There was supposed to be one - context 
lookup, which was not added though, as Carl solved it by binding?

Graham - there is now Rebservices-R3 source code group in DevBase. 
It was submitted there on 11th of June, 2008 by Gabriele. I don't 
know, how feature complete the release is, or if it is usable ...

A new DevBase is still intended to be a testbed for REBOL technologies, 
including the new GUI and LNS.

A more modern GUI for devbase would be nice

sliding screens ... :)

translucency

skinnable

there has to be a few exemplars for the rest of us :)

I can't go into the core changes right now because some of them aren't 
finalized (and it's 4am here), but here's a teaser: SELECT on object! 
acts like GET IN, but much faster. If the argument word is not a 
field in the object, #[none] is returned - no errors, no undefined!, 
just like with map! values.

So far, we are solving panel (page) style elements. What I miss is 
one layer above it, namel split-window. Hopefully it will not be 
problem. When I look e.g. at Outlook, the UI is - one window, background, 
and panels. When you move over the space between the panels, mouse 
pointer changes to that of resize. I wonder how would we do it?

Why is SELECT faster? :-) re error - get in could change to return 
none too, no?

that's a custom widget

Graham, I'd be happy with a DevBase that isn't a usability nightmare 
and implements a collaboration model that makes sense.

GET IN does return none, but it does it as an error workaround. SELECT 
does it in one, non-erroneous operation.

custom widget? All apps I can see provide kind of split window ... 
even AltME :-) I think that solution might be to allow one of four 
sides of panel to be resizable in certain direction. The rest will 
be handled by resizing model ...

Pekr, that is supported already by the splitter style, I think.

what will also be interesting is pop-ups. Caused us some problems 
in the past. Menus, rotary, etc.

trying to solve too many problems at once

if devbase is a nightmare ( I've not had access ) someone as you 
say needs to design it properly first

(sleep now)

chicken and egg

who knows ... but there a lots of collaborative tools out there. 
 Designing another might be considered a distraction from core business 
( pun intended )

Many ppl suggested to accept e.g. SVN Trac, as RebGUI is using. But 
DevBase otoh gave us another good VID expert - Brian :-) He was also 
doing some fixes, which will be part of Core 2.7. Sometimes it is 
good to use your own tools. That is also why Carl is putting so much 
energy to new VID - trying to do some real stuff using VID.

The current design of DevBase has been useful to show us what works 
and what doesn't. The new DevBase will be valuable to the community 
beyond its specific use, but I intend for it to be worth making on 
its own merit.

Pekr is right, I never used VID2 at all before I started working 
on DevBase. Now I am working on improving VID2. That's a value :)

Now you are working also on VID3.4 :-)

If we are concentrating on VID, perhaps we need to locate the most 
common widgets and see if there any dificulties in creating them 
... like Pekr's split windows

If we don't want to start with own windowing system (which might 
be important for browser plug-in where using pop-up windows could 
get problematic because of blockers), then we should start with some 
kind of split window, and look for inspiration to various nowadays 
apps. Once you divide your app window into such sections (it imo 
still can be done with adapted panel style), you can then place icon-bar/menu 
at the top, icon-list or tree on the left, and the form on the right 
side. What some REBOLlers I talk to are also expecting, are styles 
like tree-view, tabs, grid, out of the box ...

Well, Rebgui has set the current working benchmark

yes, except the system friendly behaviour (accelerators, ocusing 
system, ctrl tab for switching tabs, etc.). Other than that, RebGUI 
is nicely feature complete.

How realistic is it to want to be able to drag and drop widgets?

and have the ability to drag items from one widget to another?

Can widgets accept such events?

I don't think that would be too difficult, although a framework for 
that would need to be made.

I sometimes wonder about the inherent limitations to a dialected 
GUI vs an object oriented one

Graham - we are kind of object oriented. And why should it be a problem? 
You can go and locate effect-lab2.r script in R3-alpha world. This 
clearly shows, that drag and drop is not the problem, and that items 
even react to such stuff, including mouse pointer change. Simply 
put, all you need is to get low level event which tells you the drag 
is happening, and then you provide on-drag, on-drag-over event handler, 
where you can ''cause-event (in Gab's version) and style can react 
to it ....

and the type of widget being dropped is known to the event?

you could store such information centrally, since you usually only 
drag one item at a time. the on-drop handler for a style would then 
read the information on what was dropped here.

I often drop a bunch of stuff across ... eg file copying

we have to support multidrop though ... imagine selecting several 
images and dragging them at once ...

Pekr, sure, but still you can store that centrally. the method would 
be the same.

Henrik:  from the docs - "The GUI module object (currently called 
GUIE, but soon to be just a module variable) " - does it mean VID 
3.4 will use real modules, or just reading too much into it on my 
side?

AFAIK the GUI system will be a module.

the GUIE almost looks like new name for the GUI :-)

Henrik - do styles/faces have something like origin, margin, edge? 
E.g. how do you adjust field, what unit (pixel) should text start 
from?

I'll respond to that later.