AltME groups: search

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

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

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

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 :)

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 ....

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

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.

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.

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

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 ....

sometimes you want to merge buttons into a group.

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

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

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.

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

Using multiple gobs for a thing like Graham suggests would make the 
style even more complex and we're back to VID3. Not having to manage 
gobs at all is quite a relief.

For focusing and such effects, it makes more sense to separate that 
out into a small gob system layered on top of the GUI. Similarly 
for drag'n'drop, bubble help, etc. It's not hard to do.

we should aim to introduce all possible subsystems

 ... I think we should aim to have something, anything, out ASAP with 
 as few subsystems as required to get a workable result that satisfies 
 80% of folks. The other 20% can wait another 10 years for "all possible 
 subsystems" to be designed and implemented.

Note: If my site is slow or down, it's because it's raining. My wifi 
connection is bad, because a big tree has started blocking my antenna's 
line of sight. I've not received permission yet to cut the tree down.

Your site is so slow, that I can sometimes even see textual path 
of the file, which starts to be downloaded a bit later :-)

Since no matter how long we spend on VID++, it can't be released 
without a finished core, doesn't it make sense that work on core 
be restarted?

antenna problem partially fixed. it was full of water, shorting the 
wire and the tube, but it's only temporary and only a part of the 
problem. site should work again.

I'm on 2.4 Ghz, plain 802.11b. The problem is that there is supposed 
to be a plastic lid sealing the end of the antenna tube (it's a homemade 
"cantenna"), but they tend to break and fall off due to weather exposure. 
The bottom of the cantenna has a hole to let the water seep out, 
but it's apparently closed up. And yeah, trees are a real killer. 
I'm going to have to find some stronger material for the lid, and 
isolate the antenna wire better from the tube.

I prefer it here at home, yes. But it would be wonderful with an 
external Cheyenne server on a good connection.

I thought you might be curious to see how FUNCT works. It's very 
useful:

>> source funct
funct: make function! [[
    {Defines a user function assuming all set-words are locals.}

    spec [block!] {Help string (opt) followed by arg words (and opt type 
    and string)}
    body [block!] "The body block of the function"
    /local ctx
][
    spec: copy/deep spec
    body: copy/deep body
    ctx: make object! 4
    bind/set body ctx
    unless find spec /local [append spec /local]
    append spec words-of ctx
    make function! reduce [spec body]
]]

Pekr: "There would be no complication, if frames would be used"

Using frames, especially the way you describe, would be a big complication. 
Nonetheless, that kind of thing is supported in the current system. 
However, it is not the simplest way to accomplish the task and for 
most purposes would not be the best approach.

Your characterisation of the current system is not quite accurate. 
A single draw block per style is the simple case that will do for 
most.

We are not working with a single-complex-gob system only, we also 
allow compound gobs, rich-text-only gobs, image gobs, whichever is 
the best for the situation. We even have modes and custom draw handlers 
for more complicated situations. The new GUI's approach is both simpler 
and more flexible than the frames system you describe, even flexible 
enough that you can implement that frames system in your style if 
you like.

After VID2 and what it is, I am scared of not asking though, and 
later to hear - ah, you would need such a feature? Well, it can't 
be addeed ...". You can as well write your own VID :-)

One question towards 'funct. What if I have global word, e.g. 'a, 
and then I would need to set 'a also in the fuction body? Am I supposed 
to use "normal" function, instead of 'funct?

or - will we have any chance to refer to context, module? Something 
like self/parent/a: value?

But according to the blog, it might seem that many users could in 
theory prefer using funct quite often. Wouldn't it be better then 
to have it as a native? (it can come later, of course)

It's basically a convenience function, though used widely in and 
by the new GUI code.

Please keep asking questions. As long as you are patient the questions 
can act like a Plato-style dialectic discussion, providing valuable 
information for the rest of the community. If you don't ask, we won't 
know what people want to know.

As for questions, I would prefer that you ask them now, as long as 
you can take "maybe", "don't know yet" or "hasn't been decided yet" 
as an answer on occasion. There are things that we need to know, 
but the overall design strategy is a good one so far.

I may not have studied Gabriele's system as much as you have, but 
I have studied many other GUI systems and implemented some as well. 
There are a lot of differences between the systems in implementation 
details, but to a great extent they accomplish many of the same things. 
I know enough about Gabriele's and Carl's GUIs to be able to tell 
you that the overall design strategy is different, but the capabilities 
are comparable.

BrianH: could you please elaborate a bit on following?


- what is make-panel function good for? To predefine statical layout, 
without viewing it?  General question then is, if we don't miss 'layout 
function with R3 VID. Is there more functions like that, e.g. make-face 
as with R2?


- could you please explain a bit 'plane style? I thought that 'panel 
style itself spans available window space, and if the content is 
larger, scrollers are used automatically (kind of area with auto-scrollers 
:-) And if we need to distinguis resize or don't resize states, wouldn't 
it be enough to use something like "panel all-pan options [resize?: 
no]"?

Thanks a lot ....

>> source make-panel
make-panel: make function! [[
    {Create a panel from layout dialect block and options block.}
    style [word! none!]
    content [block! none!] "Contents of the panel"

    options [object! block! map! none!] "Options of the panel" /local 
    options face
][
    if content [
        unless options [options: copy []]
        extend options 'content content
    ]
    face: make-face style options
    init-panel face
    bind-faces face
    do-style-all face 'on-init none
    do-triggers face 'load
    face
]]

Henrik - question towards your skinning experience. So far it seems, 
that when you choose gradient based backgrounds, the overall colors 
are darkish - round button, slider. Are you settiling for such a 
theme, or still just experimenting? The problem is, that when you 
make it brighter using gradients, it starts to look glossy (maybe 
not necessarily, dunno).

I'm experienting until the skin is done. Anything can change at any 
time if I find that a particular element is not working or if I get 
a better idea along the way.

Pekr, some answers.

- The make-panel function is currently used internally by most of 
the group-like styles during their creation.

- A panel will resize its contents when it is resized, a plane will 
maintain a fixed internal size and provide a scrollable surface with 
scrollbars if its external size gets smaller than its internal size.

- No, it is not easier to distinguish resizable states that way. 
For one thing, that requires more typing. For another, a plane is 
a compound style with extra internal faces for the scrollbars, while 
a panel is not. Simpler styles are faster and easier to debug. They 
already share most of their internal code, so it is no big deal to 
add another style.

I'm confused by these statements in Docbase:


 "1. The READ-STRING function is a temporary function used to read 
 files and convert them from binary (and possibly in Unicode format) 
 into a string datatype."

I thought that the string datatype was now UTF-8 encoded.

So does this mean that the graphics library is still treating a string 
as being 8-bit encoded?  No doubt according to the current Windows 
codepage?


does READ-STRING convert  utf-8 to whatever 8-bit encoding the graphics 
library is using?

puting widget organisation into the view command ???  and if a want 
to mix below things and accross other things in the same pane I'm 
fucked ?

i put an example of that kind of mixed below and accross organisation 
of widgets in same pane and notice a bug

SCROLLER now has a tiny bit of intelligence: It will scroll the first 
face that responds to ON-SCROLL if one precedes it earlier in the 
layout code.

So:

view [text-list-box [1 2 3 4 5 6 7 8] scroller]


will automatically attach scroller to the text-list-box and scroll 
it.

As far as your code is concerned, a string! will be a series of Unicode 
codepoints. Internally, who cares? The implementation of string! 
is likely to be the same as the native implementation on the platform 
is running on, or whatever is more efficient. I think that string! 
is now UTF-16 on Windows, and the symbols behind word! values are 
internally UTF-8.


Still, it doesn't matter what strings are internally because AS-STRING 
and AS-BINARY are gone. All string-to-binary conversions will need 
encoding. REBOL scripts are going to be UTF-8 encoded though, as 
I recall.

READ-STRING is a temporary function because it is intended to replace 
it with a full encoding and decoding infrastructure supporting multiple 
formats and encodings. Until then, we have READ-STRING and WRITE-STRING.

A thick-skin is changing the entire layout and interactive behavior 
of an app. Think Winamp 5+

Medium skins will be the most common, and it is currently intended 
for a medium skin to come bundled with more than one thin skin. This 
may change though. It is intended for a medium skin to be able to 
be designed by a non-programmer graphic designer.

I think a medium skin will cover that well enough. Scrollers are 
currently implemented in a single face with draw commands.

You may be off in looking for practical reasons for thin skins - 
that is a reason why I chose Winamp as an example. Still, if you 
want a practical example, there is a Chinese version of OpenOffice.org 
that uses a vertical version of Office 2007's ribbon interface instead 
of OOo's menus. That is the kind of thing that would be possible 
with thick skins.

If by "precise control" you mean accessing a string! from C, how 
would you use binary! instead?

string! internals are not OS dependent afaik, and technically it's 
not UTF-16 either. currently, R3 switches automatically between an 
array of 8-bit unsigned values, and an array of 16-bit unsigned values. 
i assume a 32-bit mode will be added in the future as not all codepoints 
will fit 16 bits, though those that don't are very rare.

Peter, the array of unsigned values would effectively be UCS-2 if 
it behaves the way Gabriele says. This would mean it would be faster, 
but use more memory for those with characters outside the BMP. It 
would also cause a problem on Windows because Windows >= 2000 is 
internally UTF-16, as are all of its Unicode APIs.

It's not supposed to be seen, because otherwise I wouldn't be able 
to see the lines that are supposed to occupy those pixels by the 
style itself. The debug function is activated like this:

view [button "hello" debug]


and the red box appears in the face, not around it. The red box stretches 
to the very edge of the gob, so you can see where you draw.


The box is generated in the same draw block, by simply inserting 
a red box in the beginning, if the debug flag is enabled.

Having this box, helped us solved numerous layout bugs.

BrianH: As I understand UCS-2 cannot be used to encode characters 
outside the BMP. It is a full subset of UTF-16. It should not cause 
problems with WIndows Unicode API except that it would not be able 
to display characters outside the BMP. (It would instead include 
 an non-displayable character for each 2-bytes returned by Windows.)

Henrik - re your new screenshots - calculator - what is the reason 
grouped buttons of math operations are not precisely aligned vertically 
(at the bottom) as the num pad? Is it a bug in layout, or is it like 
it should be?

BrianH, can you talk about the set [a: b:] issue and what it means 
for us?

Brian: same as there is a conversion between the Linux UTF-8 APIs 
and the internal 16 bit array, there is a conversion between the 
Windows UTF-16 APIs and the internal 16 bit array. In the same way, 
we can eventually support 32 bit arrays and convert those UTF-16 
strings that can fit into it to just 8 bit arrays.

The SET [a: b:] issue:


In current REBOL a block argument to SET for the word parameter needs 
to be filled with values of the word! type, not any other word types. 
This is in contrast with just passing a single word value, which 
can be of any word type. The result of this is that values in word 
block argument need to be converted to word! before being passed 
as a parameter.


There is no reason that those words need to be of the word! type, 
particularly since the block isn't evaluated. One interesting thing 
about REBOL is that a word! bound to a context will refer to the 
same value as words of the other word types with the same spelling 
otherwise. This means that if you set a lit-word! to a value, you 
can get the same value from the corresponding word! or get-word!.


Now, the current behavior has some bad consequences as well, usage 
issues. Some word block arguments had to be preprocessed. The big 
problem we ran into was when we wanted to use SET inside of functions 
created with the new FUNCT function (temporary name).


FUNCT collects set-words from the code block and nested blocks and 
adds them to the function's locals. This is cool and works a lot 
better than I thought it would, and all action handlers of the new 
GUI are turned into functions with FUNCT. The problem we ran into 
is that when we had to use block SET to set local variables, those 
local variables would leak into an outer scope, wreaking havoc. If 
you are specifying the function spec directly there is an easy workaround 
for that: Just specify the locals that aren't caught with your own 
/local vars. However, you can't specify the function spec of an action 
handler in the dialect, just the code blocks (security/stability). 
This meant that if you wanted locals to be captured, you had to set 
them to none earlier in the function. How soon do you expect that 
to fail?


An easy solution to this would be to specify the words you want local 
as set-word! values in the literal word block argument to the SET. 
Those set-words would then be caught by FUNCT without any overhead. 
No problem, except for that SET doesn't allow it right now.


This is what we are going to fix in the next build: You will be able 
to do SET [a: b:] value.

In some circumstances like with FUNCT above, you will likely *have 
to* do SET [a: b:] value. This is where we get to the implications, 
what it means for us: We are making changes to the core, sometimes 
subtle changes with big implications. These changes are coming as 
a result of the work on the new GUI. Some of them are bug fixes, 
some of them are new functions or other enhancements, some are fixes 
to design flaws in the language expressed in functions we have already. 
They will affect the code you write even if you aren't doing GUI 
code. Every change like this is going to make R3 a cleaner, easier 
and more powerful language than R2, even with the backports. Something 
to look forward to :)

A bit of status:


- Carl ran into a bug in the AGG C++ code: "draw 10x10 []" in the 
console will crash R3 and it's a tough one, as it might be compiler 
related. Not fixed yet.

- Some of the stuff that BrianH has talked about above is now implemented 
in a new build of R3 as well as some additions to MAP!.

- My ramblings on DRAW has caused me to pause on skinning until I 
can get a clear picture of whether the problems will be fixed. Otherwise 
I'll have to redo a lot of work later on. I experiment with compound 
styles instead as well as some simple color palette tools.

- It was decided that popup graphic elements are to be done in separate 
windows for greatest flexibility. No code done yet though.
- No talk about overlays or drag'n'drop yet.

I miss plan for inclusion of important things I named in the past 
... releasing new VID without them is imo a fatal mistake ...

Well, that's what comments in the blog and here are for. Please provide 
a list of things you consider important and we can discuss the list 
and get them included, or come up with alternate features that do 
the same thing but better. Don't assume that any features we already 
have will conflict with what you want. Feedback is king here.

Simple answer: I don't think we are currently talking about finalization 
and the color picker was an example, not a feature.


Longer answer: The new GUI is going to be part of the open source 
portion of R3, and open source projects are never really finished 
until they die. So the question here is not "finalized" but "ready 
for a release to the wider developer community". In order to do that 
we need to put together the core design of the infrastructure and 
enough styles to get the new DevBase GUI up and running. Right now 
we are focussing on styles and features that have the most impact 
on the system as a whole, or the most potential to flush out bugs 
in the underlying runtime.


If it all seems low-level, that is because it is. We will have a 
development release before we have most of the styles you mention 
because we will need the help of the developer community to make 
those styles and more. However, don't expect the styles you list 
to be missing - some of them meet the criteria I lested above, like 
helping flush out design flaws or use in DevBase.

amacleod - services are in rebol in general (rebservices, aka LNS), 
and they will be supported by R3 too. But - as for "rebol browser", 
so far I can once again see only business graphics being a target. 
      More casual design should be possible though.

Pekr, I understand Services will be there in R3 but Carl blogged 
about this concept of a button linking to the www...It was a little 
vague and Henrik did try to clear it up buy the new GUI seeems void 
of this..

I thought it was to be tightly intergrated into the gui and a major 
reason for the delay of vid 3.4. I thought it was a bold new step 
in the concept of GUI's but it does not seem to be a part of what 
we have been privy to.

What I can't imagine right now is the browser concept. Well, it is 
a layout window, it can be for e.g. a panel. But when you look at 
various web sites, e.g. news portals, you can see that their design 
is more "free form", or casual, dunno how to express it precisely. 
So - what would you need to mimick for e.g. www.OSNews.com ? Define 
few styles, decide upon the columns design (group, panel), prepare 
styles for particular sections/zones (portlets - IBM, web parts - 
Microsoft, iViews - SAP terminology) and fill them with information 
....

What I hate about many websites is that they have very inefficient 
layouts. This is particularly so for forums and certain newssites, 
where perhaps 10 or 20% of the information on the page is relevant 
to you. Now imagine AltME's GUI inside a webpage. It's very efficient.

One of the saddest tricks nowadays is to divide a small 2-300 word 
article on a news site into several pages, so they get more ad-visits.

Pekr, let's say you want to read a blog post on a "rebpage". Would 
you want to download a rebpage, formatted as a webpage from that 
location or would you want to get a custom fullscreen reader that 
downloads only the compressed plaintext as makedoc format, compiles 
it on the fly and displays it?

You can work like this now already with R2. Just 'do a script from 
some webserver. Works the same way.

so, it's a form of make-doc?

It's a nicely ironic touch to have a document widget in a system 
without built-in printing though.

We can go with layout-to-pdf or layout-to-html translators at first 
run. Well guys, I wonder what you will say, once sources are released? 
Then it will be fully upon us. Printing is imo not a priority - it 
first needs to be studies, then implemented - how to do it in cross-platform 
manner?

Hardly what I was expecting for 
RichText"."


The style is not meant to be used for directly editing rich text. 
It is a method to just display rich text efficiently using an existing 
document format.

It's a nicely ironic touch to have a document widget in a system 
without built-in printing though.


You already know that printing is much harder to get done than it 
is to render for screen. How would the community react if Carl decided 
to focus on printing right now?

Source code for the style:

doc: text-area [


 about: "A tiny document markup method for embedded docs, notes, messages."

	options: [
		text-edit: [string! block!]
	]

	actors: [
		on-make: [
			; See text-area style for details.

   face/state/value: face/facets/text-edit: parse-doc face/facets/text-edit
			init-text-caret face ; (call before make-text)

   append face/gob gob: make-text-gob face face/facets/size - 2 "empty"
			face/gob/size: gob/size ; estimate to start (may get resized)
			do-style face 'on-update none
		]
	]
]

Cyphre's editable what? If we want to call that a rich-text attempt, 
we are really doomed. It was not really usable for real work.

You have a block of strings and words which represents the rich text, 
a caret position, some caret movement handling code, and a style 
that displays rich text. The biggest amount of work sounds to me 
like the code to set/get the caret position as well as movement. 
Manipulating the rich text block itself is trivial.

Henrik, I just checked out your latest movie (#3).  Very nice. I 
was wondering (as I always am) about the lists - There's a note that 
mentions that there will be tables. Will that in essence be like 
list-view?

Multiple draw blocks are now supported inside the style and a function 
has been added to help switching between them. This should simplify 
making horizontal and vertical versions of the same style.

You could call it that. Building SCROLLER and SLIDER became way too 
difficult with a single DRAW block.

The reason the octagon and triangle are inkscape based are also because 
scaling a rounded corner is very hard to do unless you to it correctly. 
It even took some time to get right in Inkscape.

dialogs are nice (although I hate them as a concept :-), but the 
most important for ppl will be lists - tex-list, list, grid, tree-list. 
Those are more complicated style, and highly expected ones (looking 
into blog comments). At least one of those styles should be tried 
to proof the concept. So far the most difficult style which was build 
seems to be scroller (area)?

I think there are a few more problems to solve right now, before 
we can get more people on board, otherwise there would be too much 
noise.

Pekr, I think iterated faces are gone, which is a good thing.

all depend of the efficientness of caret-to-offset/offset-to-caret 
functions (or their equivalent).

if the can deal with richtext block or draw blocks, we are daved. 
If they can't it will be ever a mess to build richtext editors.

From Parse: Scrolling panels was greatly sped up a couple of days 
ago. I noticed some extra refinements to some internal updating functions 
to omit excessive redraws.

Maarten;  Not to purposely pollute the REBOL3 discussion; but isn't 
rule 3, a Rule of Management?  Not something Carl (fortunately for 
us, or many rebols come to think) prescribes to.  Anti bloat being 
part and parcel of our long winter of wait for REBOL/3?

Bloated is the opposite of working correctly, as a clean design is 
one of the design requirements. So, 1.5 negates 3 :)