• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

AltME groups: search

Help · search scripts · search articles · search mailing list

results summary


results window for this page: [start: 2601 end: 2700]

world-name: r3wp

Group: !REBOL3 GUI ... [web-public]
I really wonder, if R3 GUI sees ANY regular development? ;-) Half 
the styles don't work or don't work as expected :-) Recent R3 GUI 
status is, that it is not usable for more than simple dialog box 
:-) I hope that we can see some quick fixes? :-)
I know Henrik - but I thought that there is someone actually working 
on styles? Possible Bolek? I was about to "port" rewrite demo, not 
to redo styles (which is beyond my capabilities :-) Most of things 
I mention here are obvious by very simple examples, so I wonder if 
someone tested them, or what is the "action plan" towards the GUI 
I a sense, this is very disappointing, as we have no more the possibility 
to use the Carl's gui, and the RMA 's version seems far from being 
usable !
So far, Petr's feedback helped us a lot and we know the GUI is not 
perfect yet. Nevertheless the more people help us the faster we will 
Robert - I can't see any subsystems ready, other than proper resizing 
(which is really nice), and focusing system. How can you say 2-3 
styles are enough to judge the design? I would not call non-working 
styles being an eye-candy :-) This is all about architecture -  when 
porting demo, I meet the case when I am able to easily change e.g. 
color of the scroller with Carl's GUI, which does not seems to be 
a case with RMA's GUI, or I just don't know how to do it. As I did 
not want to bether you here with such simple stupid thing, I tried 
to study material-system myself. But - I can tell one thing - if 
those things are not simple on the surface, it is either - missing 
docs, or very wrong architecture.

You should really remember, why Carl decided to rework the GUI - 
to be the pleasure to use, kind like of Amiga AMOS Basic, yet still 
allowing more complicated designs. If that aspect will not be pursued, 
ppl will not like the GUI. And what is the system good for, if not 
liked to be used by ppl?

OK, at this point, with 2-3 styles in focus, I might postpone port 
of the demo, no? As the demo is surely done with more than 2-3 styles 
:-) I will soon finish it to the state, when clicking the left side 
list items will not crash the demo. Non working stuff will be commented 
out. Then others might try to get more complicated set-ups running 
So much questions, great :)

I want freaking to change the color of the scroller
 - If not possible right now, it's bug and will be fixed.

How do I 
destylize" panel for e.g.?" - use material NONE

What is the correct way to call an actor?

 -  do-style FACE [object!] ACTOR [word!] DATA [any-type!] ; for example: 
 do-style face 'on-update none

how can I recognise, what arguments particular actors should obtain

 - good question. I have some ideas how to solve it, but right now 
 you should ask or study source :)

How can I properly attach scroller to progress bar?

 - In your case it should be auto-attached and 'attach shouldn't be 
 needed. Maybe 'attach doesn't work at the moment as the auto-attaching 
 of scrollers is actually a very bad thing that brings more problems 
 than it solves.So ATTACH is going to be reviewed and fixed when necessary.

I really wonder, if R3 GUI sees ANY regular development?

 - It does, but the developement does occur in areas you're probably 
 not interested in (GUI internals, TEXT-TABLE...)

Recent R3 GUI status is, that it is not usable for more than simple 
dialog box
 - Typical Pekrovina ;)
- Rebolek - if a button and field are enough for you forms, than 
yes, GUI is usable for a real-life apps :-)

- do-style - OK, understood. I also found do-face in the sources. 
Is it relict of Carl's GUI, or is that function good for something 

- actor arguments - Carl did so by simply put them in the comments 
of the first line, right after the left bracket. All it needs is 
imo a discipline, when writing styles :-)

- I am not much interested in attaching the scroller to progress 
bar, apart from getting demo ported. But - it surely should be allowed 
and fixed. I will ask different question here - how do I display 
scroller, with minimal sized knob?
What is the situation with compound styles? When you e.g. design 
scroller - is it a mixture of two styles? Slider (in old gui sense) 
+ arrows? I mean - if we have arrow style, and you will use the arrow 
in some compound style, then when you change/restyle arrow, will 
it change also inside of compound style?
FACED is not usefull anymore, as you reversed the design. Once gain 
- Carl's gui: FACED = instance local, FACETS = shared. RMA's GUI 
- FACETS = instance local, FACED = dismissed, INTERN =  instance 
local. So if you question usefullness of FACED, then you are also 
imo questioning usefullness of INTERN. I must miss something then, 
or you did not understand, what was FACED supposed to do in Carl's 
Carl's gui: FACED = instance local, FACETS = shared.

 - I know, but what is it good for? In the end everything will end 
 in face's facets anyway. Neither me nor Cyphre saw a single reason 
 to leave it, if you have some user case, then please, enlighten us, 
 because for us, FACED is only problem-maker.
OK, so my weak brain just dictated to create four tickets, related 
mostly to architecture of the GUI :-)
My opinion is, that noone will be ever able to work with materials 
in any gfx tool. So for me the central material storage is a wrong 
decision. The same as it was with Gab's GUI to have central storage 
of skin and look. At some point, it makes sense, yes. But otoh, I 
prefer the source readability, and I think RebGUI was better, keeping 
stuff related to one style together.

What is more - we keep style draw "frames" at the style level too. 
I would like materials to move in the style too. I don't expect having 
tonnes of material skins, to switch between.
Henrik - I am not sure I am denying materials. I can understand the 
abstraction, although so far I can't see the PRACTICAL benefit. The 
reason is, that the whole "skinning" is overrated, especially in 
regards to REBOL. Because - can you take R3 GUI style, and open it 
in Photoshop, do some skin/material simulation, and have it being 
saved? If not, the idea of central storage, regarding it being kind 
of collection of hundreds of contributed skins, might not follow 
the reality :-) I wonder if there ever be more than one skin :-)

Hence - this is the reason I might prefer in-style storage.
The difference in these two images is one setting:
One rule we follow with the GUI is, that everything that provides 
"additional features" should be plug-in able. If you want to use 
it, you can include it and you won't notice an artifical break. If 
you don't need it, don't use it.
Yes, it does more, but this is clearly not part of style but part 
of GUI system.
Cyphre - let's be realistic - I am the only one, because in fact 
I am most probably the only one, who is investigating GUI in such 
a deep manner, if not at all. This is imo a result of bad RT's treatment 
of R3, which is bringing REBOL into isolation even further more, 
making less and less ppl interested with almost zero RT's action 
... and that's the reality ...
Ladislav - let's not just take it personally :-) For me, and as you 
can see, it is a good experience to experiment with the GUI, as I 
am gaining some internals knowledge. I published the tickets for 
RMA team to consider the consequences, and it is up to you, to react 
accordingly. So - if you guys feel that it is ok, then just dismiss 
the ticket, ad the comment there, and it will server for future GUI 
users as a knowledge base, that's all ...
The source is gui-object.r3
I would not mind, if style/options would be renamed to args or params. 
And if it will unify with reactors, then - why not? I know that other 
pov might be, that those really options, just inlined. So - you can 
have RMA voting, as now you imo clearly understand, why I had the 
problem with the recent naming. Maybe you will decide that it is 
fine as it is, it's your GUI after all :-)
it should be, otherwise you couldn't use the GUI at all
A111 was reported to work with the RMA GUI, but under WINE I get 
[kaj-:-Kaj-Portable-PC] ~/Desktop/REBOL-3 $ ./r3-a111-3-1.exe r3-gui.r3
** access error: cannot open: shape reason: "module not found"
This doesn't seem to happen if I load the single GUI file and write 
my own Hello World
I got A111 working with r3-gui.r3 under windows, but not with the 
pre-compiled version. I recompiled it from the source.
The crash seems to happen due to the TITLE widget, because it also 
crashes with the single file GUI
if you use a request function to display a message, this is the cause 
of the problem: the request function from RMA is bugged (and also 
the alert). You should either correct in the RMA r3-gui.r3 file, 
or, better, overload it. change the words group  by hgroup , and 
change the line doc (message) by text-area (message)
>> do %r3-gui.r3

Script: "R3 GUI - load and start" Version: $Id: $ Date: 9-Dec-2010/10:32:04+1:00
>> do %demoJC.r3

Script: "R3 GUI - Development Test Script" Version: 0.1.1 Date: none

Script: "R3 GUI - load and start" Version: $Id: $ Date: 9-Dec-2010/10:32:04+1:00
** Internal error: stack overflow

** Where: reduce switch parse to-text reduce parse to-draw all update-subgobs 
foreach update-subgobs foreach update-subgobs foreach update-subgobs 
show-native show-native show-native show-native show-native show-native 
show-native show-native show-native show-native show-native show-native 
show-native show-native show-native show-native show-native show-native 
show-native show-native show-native show-native show-native show-native 
show-native show-native show-native show-native show-native show-native 
show-native show-native show-native show-native show-native show-native 
show-native show-native sho...
If I load RMA's original GUI in Jocko's R3, I get the same result
I also have that. If you launch directly %demoJC.r3, you don't have 
the problem (there is a call to r3-gui.r3 inside demoJC.r3). It seems 
that if you call it two times, it crashes.
This GUI and GLASS are also terribly slow
not much time to fix everything anyway. There's two fixes for Doc 
style but generally - this gui is incompatible to Carl's one in many 
aspects ....
well, not sure I understand the word "endured" correctly, but anyway 
- I wanted to become more familiar with the GUI, published some tickets, 
learned a lot, yet I am far from being a good coder. I also only 
have few hours a week to experiment. I initially thought it is going 
to be about changine few things here or there, but it seems to be 
more complicated.
I believe the released GUI is out of sync with A111. The GUI works 
One or two years ago, Carl's GUI was demonstrable. This one isn't
Pekr, we are by and large at the same point. Your version is compatible 
with the a111 version that I compiled, except for a certain number 
of tests, like mine. Did your version work with the a110 of RMA for 
the drawing test ?
Kaj, I agree, Carl's version was demonstrable.

Some basic functions like request or alert, and styles like doc are 
still bugged in r3-gui.r3
pekr - I see that you have put many other contributions on r3-gui 
I agree with you. The point is, as there is not enough documentation, 
we may "translate" incorrectly the code. Anyway, I would be pleased 
to contribute with you to make this demo work, as I feel it very 
"sexy" and representative of the potential of the gui. Of course, 
RMA is welcome to do on their side this kind of demo, showing the 
various functionalities of r3-gui
Guys, I don't know how often I have to repeat it:

1. we get basic concepts implemented. All these basics are seperated 
as much as possible. That's why it will be totally incompatible to 
Carl's GUI. And, we don't try to be compatible. Our goal is to have 
an enterprise enabled GUI framework.

2. To do step 1, we just pick 1-2 styles, and enhance and change 
them exactly to just work with the concepts from 1. And, please see 
the plural in "concepts". We are doing step 1 & 2 by concept.

3. If this stabelized, we take the next style and adopt it. This 
might lead to some changes in 1. which than have to be carried forward 

4. Then either next style or next concept.
It's quite simple. The GUI is not functioning in general purpose. 
Anyone expecting this is just pure wrong... you have to wait or help. 
And the concepts and styles we care are priorized by what we need.
Well, RMA doesn't work for years on R3-GUI.
The other R3-GUI stuff is nothing I take seriously into account for 
I agree, that's why we bite the bullet and invest a lot of money 
into the development of a useable GUI framework. It's a hell lot 
of work as we mostly started from scratch, and need to fight on the 
c-level as well.
Maybe it would have been better to have kept Carl's GUI as something 
that could have been used warts and all, .. and the GUI team continue 
to work on their alternate GUI?  Would that have been possible?
Carl's GUI is not working because of internal changes like moving 
graphics to extensions module (using commands)
Graham, I guess, that you realize, that the original Carl's GUI is:

*kept and available

*maintained, the RMA is just the continuation of Carl's GUI, correcting/improving 
things that have been found necessary to correct

What exactly are you asking for, then?
Everyone crying for Carl's GUI should use LOAD-GUI function in Carl's 
builds of R3 alpha (the builds having View capabilities, not the 
console-only ones, as Kaj creatively tried)
Ladislav - my guess is, that what  Graham had in mind is the demo, 
load-gui, etc. As we understood, demo was not a priority for RMA 
if my understanding is correct, load-gui in RMA's releases loads 
If something does not work, it is just because what you call "Carl's 
GUI" is the old version, while the newer version of the code are 
(somewhat improperly) called "RMA GUI". Nevertheless, everybody crying 
for it, can easily take it and update everything that he sees fit.
The "show-native" is another case of Kaj's reinventing the wheel. 
It has been corrected almost a month ago (the correction was even 
posted by me above), wondering where Kaj is getting his %r3-gui.r3 
Just making few notes:

1. we don't push anyone to use/accept R3GUI from RMA

2. anyone who is missing "Carl's GUI" can download it at http://www.rebol.com/r3/gui.r
and happily use and enhance it. (It really works much better than 
RMA version...especially with A111 :-))

3. Having 'good looking' demo doesn't mean anything when the system 
cannot be used in real application. (That was the first thing we 
realized when checking the "Carl's GUI" and that's why we continued 
to improve our own version based on Carl's design)

4. It has been said by defferent RMA-members:

-this project is still in 'alpha', we are working frequently on it 
to be better
-we are publishing/sharing our work-in-progress code
-we invite any good contribution to the wip code

So far the major reaction to our effort is none,negative or contra-productive 
here even from some people who have experiences with mangement of 
larger projects(*sigh*). I don't understand why.

This has of course nothing to do with constructive critics which 
we hear, discuss and think about every useful comment (even if it 
is not accepted in the end). Unfortunately we could count 'useful 
comments' in this group on fingers on both hands max.

5. even with all the negative energy that is 'pumped' on us from 
Rebol3 we will continue with releasing our work and inform people 
here about the progress etc.
Cyphre - just some friendly opinion exchange, hopefully you will 
be able to understand my explanations (which don't necessarily represent 
my exact point of view):

- most ppl here are well aware of the fact, that RMA is a business 
entity, and hence has absolute right to do what makes sense for its 
business. The trick is, that in the end, it does not work for ppl, 
I will tell why later.

- The point above is even more difficult to understand, as RMA is 
offering its work for free, yet ppl still complain to something (including 
me of course)

- What might have failed is, that ppl might think, that accepting 
SCRUM method will mean, that we have finally found a viable model 
for  general R3 development, which will allow Carl to stay available 
 to small agile team of developers, isolated from the noise.

- Ppl were expecting GUI to probably appear in 2-3 month period. 
Althought Carl's GUI worked mostly on the surface, it was something 
ppl could experience. RMA's aproach is much broader aproach to usability 
and architecture. But - that resulted into refusal to provide usable 
demo. There was some attempt to provide style browser, but it was 
highly unusable to attract ppl.

- RMA seems not to understand (or it is not its priority) the importance 
of visuals. You surely remember the "design sells" claims, which 
are know for ages. Do you remember your Rebcon AGG demo? So much 
joy, so much applause. The current look of the GUI and its metrics 
just ruined the "hmm, nice" first look experience, and for no apparent 
reason, then constantly repeating "the skin will be done later". 
If so, it should not have been changed in the first place. (After 
porting the demo, my next area to play with is to try to play with 
material system, etc., and box-model style metrics)

- Ppl are well aware, that RMA is mostly on its own, and that even 
SCRUM methog did not work in regards to keep Carl attracted to such 
method in the long run. We are now facing the worst ever period of 
R3 development, where Carl apparently has some other projects, and 
R3 is almost stalled. Ppl are clever enough to realise, that we are 
being fed with some mid-time blogs, which should keep us distrated 
from the facts (huh, rebol file suffix importance anyone?), and we 
are also facing rushed releases as A111 is, and 2.7.8. was. You are 
free to not agree, but that is how I personally feel about the situation 
towards the RT. In the past I would probably write some letter to 
Carl, but I am at the point where I think, that RT is effectively 
burrying R3 under month by month. So - Carl is not able to find free 
time to continue with R3 development on a regular basis, and noone 
is denying his right to personal life, but - the fact is, that R3 
situation is at least - worrying. We wait for the beta plan for more 
than 4 months! If someone does not have time to even think how to 
proceed, then it is probably time to close the shop ... or open-source 
... but that will not happen. So - welcome the Amiga fate ... 

- And before someone else adds it, I will add it myself, as I believe 
I have my points right :-) Amen! Could I be wrong? Of course I could. 
You can easily state - hey, the situation is not like that, we know 
Carl works on this or that. Well - RMA knows, but that's it - the 
rest of the community is kept in information embargo from Carl. And 
that is difficult to deal with for many of us, who really like REBOL, 
and would like to see some coordinated development and the light 
in the end of the tunel once again ....
And now also - back to point 5, away from politics :-)

- New resizing model. Will API change too? Or is is just internal 
change, so I don't need to care about it, apart from knowing, that 
in some cases, resizing model will be more efficient?

- Is RMA building any commercial app using R3 GUI right now? Because 
I still might miss something, but style-wise I find it difficult 
to imagine, how it could be used. (Tables, lists, tree, area, tabs 
missing or buggy?)
Ladislav "The "show-native" is another case of Kaj's reinventing 
the wheel. It has been corrected almost a month ago (the correction 
was even posted by me above), wondering where Kaj is getting his 
%r3-gui.r3 file?"
I implore you to read the discussion better - with an open mind. 
For example, the r3-gui.r3 file is from your own distribution
Kaj, I bet your r3-gui.r3 was definitely not the latest version from 

The bug you showed has been fixed in the release from 28.1.2011 (see 
the announce group)

It looks more like you have been loading the r3-gui.r3 from Josko's 
http://www.colineau.fr/rebol/downloads/tests-R3Gui.ziparchive ;-)
That provokes another request from me: please stop presenting "political 
opinions" here. The purpose of this group is to discuss the GUI.
Cyphre: "Kaj, I bet your r3-gui.r3 was definitely not the latest 
version from http://www.rm-asset.com/code/downloads/files/r3-gui.r3

The bug you showed has been fixed in the release from 28.1.2011 (see 
the announce group)"
The fact, that you are insisting you used our r3-gui.r3 version while 
at the same time proving yourself wrong stating that you always ran 
a different version not obtained from us puzzles me. How can you 
describe "state of the gui" in such case is totally beyond my understanding.
I may have missed the latest version, but the one in my zip has the 
same date as the one at this link. http://www.rm-asset.com/code/downloads/files/r3-gui.r3
.i.e; 9-Dec-2010/10:32:04+1:00. May I suggest to put a version nr 
to r3-gui in order to avoid any mistake ?
Regarding the date: currently, it is just the date of the file loading 
the whole GUI, which has not changed since December.
So, r3-gui.r3 is just a loader, not the whole GUI code?
The r3-gui.r3 is the whole code, but it "gets" the information from 
the main (loader) file
The fact, that you are insisting you used our r3-gui.r3 version while 
at the same time proving yourself wrong stating that you always ran 
a different version not obtained from us puzzles me. How can you 

state of the gui" in such case is totally beyond my understanding."
the r3-gui.r3 should be obtained from:

If I load RMA's original GUI in Jocko's R3, I get the same result
 - this is a citate, proving:

1) you stated you used our r3-gui.r3

2) you have proven yourself wrong by obtaining a result that can 
be obtained only from Jocko's code
I am not trying to forbid you to speak about anything, but am publicly 
making a disclaimer: Kaj has proven himself wrong when stating he 
tried the r3-gui as available from rm-asset.
Pekr, regarding the Box-model: did you read


, where the box-model description (needs update!) is?
To recap:

- Kaj has reported crashes of a111 on WINE, both RMA's and Jocko's 
builds. He doesn't use Windows, the supported platform.

- RMA needs to update its modified date for r3-gui.r3 when it changes 
its component parts.

- Jocko now knows his build was outdated, and has likely updated 
it. This will solve the additional Jocko build problems.

- Ladislav, please note that Kaj's crashes with the RMA build were 
WINE-related. Only later did he try Jocko's build. Testing on WINE 
might help.

- Kaj, please try demoing on Windows if possible, and if you aren't 
too annoyed to demo the RMA GUI stuff.
Could the RMA build be updated to alpha 111? This all started because 
the release notes of alpha 111 said that R3 was now compatible with 
the RMA GUI, but RT's build is a core build. This is why Jocko had 
to compile his own build from the alpha 111 host kit.
Ladislav, thank you for the link http://www.rm-asset.com/code/level1/r3-gui/
. The point is that this link is a presentation page, referring to 
a second one (downloads) which at last leads to http://www.rm-asset.com/code/downloads/files/r3-gui.r3
... the link that I used from the beginning. And so far I have no 
means to check if the file that I use is the latest one. Are you 
sure from your side that this file has been updated, and corresponds 
to the version issued 28th, january ?
Pekr, Kaj :

checking, and modifying the code. In some tens of minutes,I will 
put a new version, with the latest r3-gui.r3 version. Later (in some 
days) I will go more deep in the non working tests.
Pekr, thank you for the doc patch : it works
just posted an updated version of the test-demo (version 0.3.0). 
It includes the latest version of r3-gui, dated 28-Jan-2011.
Is the way of how styles are being drawn compatible with Carl's GUI. 
I definitely request scroller being progress + arrow button based, 
as I have goose bumps looking into the recen one, which has to come 
from different planet probably :-)
no, taken from Carl's gui. How the hell scrollbar can be 16pixels, 
whereas progress is 22 pixels? It look like Mac OS-9 relic of the 
past, and is completly off with the rest of the design? I want to 
have it fixed, before I go mad :-)
view [progress 50% slider scroller] - try this code to see what I 
mean ... and try the same code in Carl's gui. What is wrong with 
his scroller? It looked much better.
Hmm, I don't have Carl's styles available :-(, only some GUI related 
code. I wonder if it was ever available.
Yes, these are the boxmodel attributes, as named in the recent versions 
of the R3 GUI
The updated version of the %r3-gui.r3 currently looks as follows:

    title: "R3-GUI"
    from: "RM-Asset"
    license: http://www.rebol.com/r3/rsl.html
    version: 1917
    date: 25-Feb-2011/17:50:30.907555

Note, that this is a version, that is not available yet for the download, 
since it is being updated. Also, the VERSION number and DATE are 
values taken from the RM-Asset Subversion repository.

Anybody knows what happened to the license page Carl originally kept 


? Another question: do you miss any other info in the header?
Header update:

    title: "R3-GUI"
    file: %r3-gui.r3
    from: "RM-Asset"
    url: http://www.rm-asset.com/code/downloads/
    history: http://www.rm-asset.com/code/level1/r3-gui/
    license: http://www.rebol.com/r3/rsl.html
    version: 1917
    date: 25-Feb-2011/17:50:30.907555
    purpose: "REBOL 3 GUI module"
Notice, see

    history: http://www.rm-asset.com/code/level1/r3-gui/

, that there are other changes, and more important, than just the 
correction of the SHOW-NATIVE definition
Is this fix mentioned in the tickets you put ?

I did not read them up to now, I wanted to correct quickly the version 
which used an out of date r3-gui file.

For the other fixes, I will introduce them later (Or you, if you 
want). And I will take some time to make the other examples work, 
out of RMA documentation.
You already have the other fixes as listed in the history page, if 
you updated to the latest public version of the %r3-gui.r3
jocko, the fix is in view-show.r

; this is a run-once-code, i.e. it causes problems when LOAD-GUI 
is run twice
;show-native: :show

; this is a way how it can be corrected:
if command? :show [show-native: :show]
Pekr - I checked, the fix is already introduced in the last public 
r3-gui.r3 (which is in my zip tests-R3Gui-3.zip) so, you normally 
should not see the problem.
is the "drawing" style working in r3-gui ?
I have done a new version of the demo, with a page of docs, and I 
was waiting for the new release of R3-gui, but if it does not come 
this evening, I will deliver it.
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. 
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 

- 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 

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
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.
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 
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.?
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?
I think it would be fairly easy to do a straight mirror of the GUI 
and just flow text in the opposite direction.
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/
I remember style of such a name from some prior gui attempts, and 
it used tight spacing between the elements. What I am looking after 
is precise copy of vpanel, hpanel, with just zero graphics, or at 
least different border
hmm, there seems to be so much of colors, etc. I sometimes almost 
feel, that we overload GUI once again. In R2, there was a face. We 
introduced gob, as a means of having smaller object in memory. In 
fact, there is a face linked to each gob, no? And just print recent 
styles structure - it is now bigger than R2's face. And you also 
don't use 'intern for things which could be shared between the instances 
= wasting memory again?
2601 / 286712345...2526[27] 2829