World: r3wp

Thanks. Claude, looking into it...

Sorry, Claude. I have trouple reading names of that color on a white 
background :(

It seems like problem with compound-face?. Replaced with parent-face? 
instead and seems to work fine.

only missing for the moment treeview menubar !-)

so this differs from altme where resizing only occurs on left mouse 
release

 - the difference in R3 is that during the window resizing the framebuffer 
 is 'resized' and redrawn as well. This was done to support  'realtime' 
 resizing during the mouse drag in the future but not implemented 
 yet.

Good to know

Posted my evaluation on the compatibility of r3-gui (release v1993 
dated 2011-03-04) with the standard release (recompiled) of r3 : 
r3-a111. Result: very good. 
http://www.colineau.fr/rebol/r3-gui.html

Thanks Jocko!

Following few things:


- why is "custom" include needed? We should either user R3 native 
facilities, or include an include as a standard into R3 :-) (this 
is no real question, just a remark that if we find it usefull, then 
why notto make it part of R3?)

- RMA does not work with CureCode tickets. It would be good to either 
dismiss/close or resolve them? E.g. I find renaming of do-style and 
do-face to do-action, do-reaction a good tip to implement


- we should resolve the size of buttons vs scroller vs tabs. In Carl's 
GUI, button is 28 pixels tall, and it feels OK. Our's here is 22, 
I have no preference here, but could be those 28 pixels. Scroller 
is only 16pix - not acceptable imo. It should be of the size of the 
progress. Tabs are proportionally too tall.

- tabs should have line removed for actual tab. I suspect it might 
be more difficult to draw the container then.

- there seems to be someone at RMA liking Old aqua interface of MacOS. 
Tabs, buttons and scrollers are a good example ... of how to not 
do visuals anymore :-)

- area - enter few lines, go to bottom, and try to hilite the text 
by keyboard (shift plus arrow-up). It always hilites only actual 
line

- info areas, labes, etc., should prohibit display of caret, maybe 
allow hilighting, but allowing to have caret in "disabled" area is 
not looking nice

- text-table buttons are Excel filter inspired, but looking strange 
- some more thoughts needed
- select-an-option does not allow keyboard navigation

- text-list does not scroll, when navigated by keyboard, ditto text-table

- tabbing feels strange for text table. I alway said, that we need 
nested tabbing. I can imagine tab stopping on table, but next tab 
moving away, not actually going into tabbing in terms of the hilited 
widget. Enter should enter the more complex style, escape move away. 
That is not typical also at OS level, but then - everybody has it 
wrong :-)

- between the text-list and text-table, I have to press tab three 
times -visually I am not sure, "where" hilite disappears

- is text-table a compound style? What sense does it have to have 
buttons hilighted, not being able to enter the action? Why are not 
arrows tabbable? Table headers cells should be one style, not two.

- text-table is the weakest "grid" we ever had. Comparing to Cyphre's 
style pack, and rebgui grid. This is like 5% of functionality, not 
thought out style, useless for any serious data. I want to see the 
display of infiinte amount of data, proper caching.

- tab should be tabbable, ctrl-tab allowed to switch between the 
tabs  


I find the styles/gui inconsistent. There should be someone defining 
the styles, their behaviour to keyboard navigation, tabbing, etc. 
So far it seems like style being put together with no deeper thought 
about the end result of the whole GUI.

Someone might have a feeling, that I sound negative. I don't :-) 
The achievement is concrete, material, good. But to have consistent 
and well behaved GUI, business grade, we need to introduce anyther 
layer - consistency:


- tabbing and visual representation of in-focuse styles - currently 
very inconsistent. Maybe not just implemented for all styles

- keyboard navigation is a must. We have to be able to navigate by 
keyboard thru allowed guielements, consistently
- keyboard acceleration keys are completly missing so far
- style metrics
- final design/skin as a last one

Resizing - very nice, predictable.

from tab-box docs - what is 'some?

tab-specs: some [

Thanks for reply, Pekr.

- curecode - I'm not sure about others but I don't have enough rights 
on curecode to change state of tickets.

- visuals - 1) as has been said many times, not a priority right 
now and also 2) highly subjective

- tabs should have line removed - see above reply to Graham, why 
it's problematic

- keyboard navigation is broken in this release, subject for next 
release

- text-table is useless - I really like these statements of yours 
without any serious backing. "I want to see the display of infiinte 
amount of data, proper caching." - please, elaborate of what's not 
possible here.

Rebolek - easy to describe. Cyphre is the guru of grids. I remember 
his Cyphre styles grid, and I also do remember grid my company paid 
for, for RebGUI. And I really don't understand, why witch each new 
GUI, we have to start from scratch, and introduce something which 
is clear departure from what was achieved before? Here's few features, 
which were supported:

- cell can be ANY style (VID dialect)

- virtual columns/rows. Simply put - no need to reformat data obtained 
from some data source. Easy to switch/hide columns/row. Only pointers 
to data moved, no need to reformat data, easy to submit back to db 
backends, without the need to reformat the data again

- hilighting - row or cell or cell + row, full keyboard navigation
- horizontal scrolling
- ultra fast, unlimited amount of records


In the past (1998) we bought a product called GridPlus for our CA 
Visual objects. It was few thousands of lines of code, but it just 
smashed any other grids from Delphi, etc. Ditto for DOS era - EzBrowse 
- it even allowed to freeze columns, save set-up of grid plus filters 
for particular windows etc. I have very good idea what kind of functionality 
should grid allow.

Keyboard support - I'll wait for next release then ...

As for the consistency, and my complaint that the whole gui is not 
build with unifying idea - it has NOTHING to do with the skin. Just 
look at arrows:

- arrow button
- arrow button of scroller
- arrow button of drop-down
- arrow button of text table


Those are all different, and this is exactly the reason why some 
ppl try to do comound styles - to have just one arrow. If you are 
not carefull, you end up with above different arrow representations 
...

Pekr, it might actually be that it's not a good idea to use the same 
arrow for things that are quite different, for skinning reasons. 
But I also suspect, you wouldn't complain, if the arrows were skinned 
identically.

- cell can be ANY style - this is TEXT-TABLE so it's clearly not 
intend of this style

- no need to reformat data, easy to switch/hide columns/ rows - data 
are referenced, simple update-face will update table, columns can 
be hidden, that's specified in dialect, row hiding can be done with 
filters

- unlimited amount of records - if you mean limited by RAM then yes, 
that's implemented and only visible lines are displayed, not everything

- save set-up of grid - yes, text-table supports that. You can store 
state of whole table and create new one from this state in one line 
of code.

- horizontal scrolling - wasn't needed, but isn't problematic. text-table 
can support unlimited columns.

visual consistency - it has been said many times (but probably still 
not enough) that it's not priority.

there is TABLE style that can has cell of any type. It was too slow, 
but it should be much faster now, so you can expect in one of next 
releases.

Rebolek - I am suggesting that anyone doing a serious GUI work should 
do some mock-ups, and build a spec table. rows= style name, columns= 
tabblable? | accelerator key |  shared visuals. It is not about the 
look, but it is about the behaviour imo. Just look at the text-table 
arrow - it is a separate button. It will have influence to tabbing 
for e.g.?

Pekr, that is solved using tags.

Henrik - do we allow tab order somehow? Just curious ....

I think that is to be determined how that should be done. Currently 
it follows face order.

wow, we really earned some feedback with this result. Very good.

text-table: This is a very good and powerful style already. It solves 
80% of all use-cases in commercial apps. It's lean, fast and supports 
some advanced features out of the box. Speed of implementaiton is 
focus here, not configurability. The auto-filters are XLS inspired 
but the semantics are extended. You see all available values divided 
into from current shown list (above divider) and from all data (below 
the divider).

I'll wait for next relase. For me, the person who mostly uses keyboard, 
the demo shows it is very broken in that regard. Maybe I might try 
to catch few bugs here or there with simpler set-up than 'all-styles. 
But then Rebolek knows about the bugs, so I don't know if the experimentation 
would not be wasted?

Will there be any interim release of already known bugs, or will 
it be typical "friday" release in a week or two?

Please take the not about allowing tabbing order into consideration. 
I do remember I used it in gui only few times though, so not sure 
if it is any usefull to be able to define tabbing order other way 
than in top-left to bottom-right direction?

not=note

I'm not sure if the direction is possible other than by simply doing 
it with layout, where you can flow faces in a particular direction, 
but ordering by specifying a number should be possible.

what about left-to-right guis? But dunno if we should care about 
those rare countries to support? :-) Or does layout allow already 
different than left-to-right setups?

I think it would be fairly easy to do a straight mirror of the GUI 
and just flow text in the opposite direction.

Pekr, experimentation would definitely not be wasted, we know about 
the keyboard-navigation problem, but there still may be lot of bugs 
we don't know about, like those two Graham and Claude found yesterday 
(thanks again!)

Danger, Will Robinson! Better not call Arab countries rare

Kaj, I am OK with that :-) I thought about them rare as in - rare 
REBOL usage :-)

When drawing style is going to be fixed?

Unicode should change that

Jocko - very good achievement with the demo.

Drawing - next release I think.

Is my understanding of box model correct? The GOB size is maximal 
size, and it contains content area, which is being called viewport, 
plus padding, plus edge, plus margin?

According to the following doc, Richtext is improved upon what was 
available with pre A100 releases? http://www.rm-asset.com/code/level1/r3-gui/richt-text/

As there now seems to be available info like glyph-metrics, is it 
possible to get nicer text rendering? Or is the nicer text rendering 
unrelated? Not being skilled in that area - what is kerning info 
etc. good for?

Kerning is the adjustment of the distance between glyphs

Is there anyone for who, the code in this report does not crash:

http://issue.cc/r3/1866

works here. With priori release I get rebol level error, stating 
something about copy ....

btw - this simple design shows one aspect we should adress - too 
many lines too close together. I wonder if there should be panel 
style with no borders.

there are and they're called HTIGHT and VTIGHT

Rebolek - I am not sure. Aren't TIGHT styles using different metrics?

yes they use. Ok, we can make *PANEL borderless and call current 
panel for example *FRAME