World: r3wp

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.

Henrik, BrianH: could you please ask Carl to add one rather simple 
style, called Icon? It should consist of Image, text description, 
and it should be selectable (blue translucent color upon selection). 
I would like to see, how such selection is being drawn, if not part 
of draw block. If you want small but real-life app to test, please 
port effect-lab2.r to VID 3.4. We can then compare. Gab's version 
handles dragging and mouse-pointer change too.

when we get to it, we'll look at it.

Graham, drag support is already in the new GUI. All that would be 
needed for full drag-and-drop is some idea of what dropping is supposed 
to mean, which varies depending on the situation.

Same with multidrop - it depends on what you are dragging. It's an 
application issue.

Pekr, R3 will use real modules. The initial public development releases 
of the GUI will not. The module system (and even spec) are not finished. 
We will be able to resume work on the module system soon, and the 
design of the new GUI's code is being done with a module system in 
mind. It's helping to do the GUI first because it serves as a use 
case and inspiration for low-level semantic fixes like a module system.

The GUI system may end up being one module, but may end up being 
more than one. System design first, code organization later once 
we have an idea what it is that we are organizing. The entire GUI 
code base will be small enough for one (smart) person to understand.

Henrik - can the panel be non-rounded, just boxy? Will it be adjustable?

It's not a setting, but I guess it can be added.

but then again, would I want to? It depends on what we want to add 
as user settings for the skin.

simply put, button and even panel rounding, even if rather small, 
does not look good, when you place stuff one to each other. E.g. 
with buttons tied close together. While I like button as is, I don't 
like rounded panel at all. Once again it is my preference. IIRC RebGUI 
has it as a preference and all styles adjust. First thing I do is, 
that I go for strict boxy desing, no rounding ....

If such things are not settable, what chance do I have? To restyle 
all styles it should apply to?

Then it would not be possible to set. I'll see if Carl will let me 
add it later.

sometimes you want to merge buttons into a group.

So, then you only want the outermost buttons to be rounded at their 
extremes.

yes, that's true. unfortunately it complicates the draw block for 
BUTTON, so I would probably want to make that a separate style.

Carl is very adamant that the draw blocks stay simple.

Would that be complex?

if you have a group of two buttons or three or more?

and then you have the events for each button ....

I think this is a pretty common style for Mac OS ??

yes, since I need to replace all boxes with a shape, plus the shape 
is conditionally made for which button in the row is going to be 
rendered.

the events are a separate issue.

I found that when I tried to stick a few buttons together in rebgui, 
I always saw the rounded edges of one of the buttons

I'm arguing against it, only because of complexity, not because it 
can't be done, because it easily can. The skin is supposed to be 
a good example of a skin that most REBOLers will be able to understand 
easily. So especially draw blocks must be very simple, so the user 
can tell what's going on.

This is the DRAW code for BUTTON:

draw: [
		; shadow
		pen false
		fill-pen shadow-fill
		box 0x1 (area-size + 0x2) 3

		; edge
		fill-pen edge-color
		box 0x1 (area-size + 0x1) 3

		; background
		grad-pen linear 0x1 1 (area-size/y - 1) 90 1 1 area-fill
		box 1x2 (area-size - 1x0) 2
	]

And that's about as bad as it's allowed to get.

draw: ?

it complicates the draw block

. There would be no complication, if frames would be used! You would 
use different draw block. I'll tell you, where will it lead with 
more complicated styles or states and their combination (animation 
of style, up, down, over, disabled, focused, selected, on-drag-over 
- and that is just button - it imo can't be covered by one draw block) 
- ppl start to patch the system. You will have no other chance, than 
to introduce kind of frames in no system way, e.g. providing something 
like face/state/frames: [], where you will store alternate draw blocks, 
and you will switch them on various events.

Pekr, frames for such a thing would make the style 3-4 times larger.

Why? As far as I can see, the main problem is following simplification 
= 1 style = 1 gob = 1 draw block. And then somewhere under the hood, 
the text gob is applied over it? (that is the section which is not 
apparent from docs so far, how text is being handled). What is the 
point to have gobs at low level, and their ability to be chained 
(contain another gobs), if not used? Some things would not need to 
be repeated (and hence style bloated with x-times the draw block 
for each state), but gobs could be layered ....