AltME groups: search

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.

Rebolek - will it not complicate a bit design/syntax of style? so 
instead of facets [size: 10x10 color: blue  text: "test"] we will 
see maps? Or will it be hidden in some lower level?

I spent a bunch of hours in the code, and thinking about the architecture, 
so hopefully you don't dismiss them in 10 seconds :-)

There was very long discussion, towards if we should allow to change 
the size of the button to allow any size being set" - did you really 
mean it? One can easily make sure, that the init-size of the button 
is set as specified." - Yes, I meant it, because IIRC there were 
opinions, trying to suggest here, that it should not be allowed at 
all :-)


All stuff you write - I know. It is just that I might not necessarily 
agree with the outcome. I am trying to think form user's point of 
view. I wonder to what points you would agree, and to what not:


- Let's assume I set button in bounds (between what min-size/max-size 
allows): I tried various scenarios, and I almost never got button 
of requested size. The reason is in how resizing system works. In 
fact, when inspecting various sizes - init-size, min-size, max-size, 
those don't contain actual button size. Actual size is in face/gob/size. 
Button gets different size due to resizing system cell alignment 
imo. From the resizing system point of view, it is correct behaviour, 
but from the user's perspective, it is questionable, if the result 
is OK?


- In regards to above point, I really wonder, if buttons should be 
resizable at all. I said - resizable, not settable. I wonder, if 
I would like buttons to be of consistent size. I might try with face/resizes?: 
false, if that would make the trick.


- Then, in regards to above - I might think of init-size setting 
the requested button size


- Maybe (and I am not sure about that one), we could allow some debug 
info - "out of bounds", if my init-size value does not fit in between 
the min-size, max-size, as style author defined it. I have heard 
that guys are working on some field accessor functions - those might 
be able to print some debug info to console, at least when in interactive 
mode.


Othere than that - this one is a minor issue for me, I e.g. care 
more about architecture, and so far I can see materials having real 
low benefit, for how complicated it turns out ...

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.

Pekr, materials are inspired by 3D modeler tools, which work the 
same way, with centralized resources of materials. They use similar 
parameters to adjust the appearance of a material, which is lifted 
above the direct approach of manipulating colors. Materials are a 
way to have designer friendly methods for adjusting the appearance 
of a style quickly and to provide logical connections between the 
highlight, color and shadow of a style.

Henrik - am I right thinking, that 'materials do affect only area-fill 
parameter in the draw block? I am a bit confused - I can see various 
colors in styles, hardcoded. So what actually material system abstracts?

The practical benefit is that you can adjust the appearance of styles 
in a more logical way, than fiddling with RGB values. It's much harder 
to produce a correct look, when having to work with plain colors, 
unless you are producing abstract or flat cartoony styles.

In the following document (images don't work), there was a way to 
show, how one can create complete style. No need to go outside the 
stylize. No imagine incorporating material system in there. First 
you have to know, how it works, so it is not enough to work with 
style draw frames, but you have to react accordingly in various phases, 
as on-init, on-draw. 


Then you have to go to completly different place, to define it. And 
that is breaking the workflow for me ...

If you keep everything inside the style, it's hard to create a skinning 
system.

I mean - there is an engine. And then there are styles. My idea (maybe 
wrong :-) is, to have one file per style, containing everything style 
related. Or at least having max 2 files. panel.r3, panel-funcs.r3. 
I just don't know - looking into style definitions is a disappointment 
for me - there is only few basic things, and there should/could be 
more. First things which come in my mind is materials, then options 
block handling, and I can imagine even functions: [] slot, where 
all related functions could be put.


I'll leave it where it is now, before the system is more complete. 
But later on, if I have a feeling, that there is some usability problem 
for users, I'll restructure the system myself.

looking into style definitions is a disappointment for me - there 
is only few basic things

 - isn't it good thing if you can write new style with changing just 
 few basic things without need for long code?

it might be that I'm understanding it wrong, but do you simply want 
a MATERIAL word for the style? that seems to be the only difference.

My idea is to have style "simulator", having just few named code 
areas, representing above post style: [ ......] structure. Then by 
protytyping, you would be able to develop full style, by putting 
code into particular slots. Well, that could be done even now, but 
I don't find a reason, why e.g. draw blocks, or actors are there, 
but code like options block handling, supporting functions, materials, 
are not part of the process ...

I don't see a single reason why code like option block handling should 
be part of every style, it simply bind words from options to facets 
and one function does it for every style.

Imagine 20 customers, all wanting their own branded version etc. 
with an externalized material system you just link in a different 
setup code and you are done.

I don't see a single reason why code like option block handling should 
be part of every style, it simply bind words from options to facets 
and one function does it for every style.

 - Rebolek - what function is that? I found that e.g. for panel, it 
 seems to be an init-panel function, which maps options block to facets. 
 And no, it is not about simple binding, it does more than that.

Robert - my long time experience is, that code reuse is very often 
being a trade-off. I can't even imagine, how you make new material 
for your new customer. You don't have any visual tool for that anyway. 
And I am not sure if I can if it is in separate file, or with each 
style. I can understand the plug-in mechanism, but I am just right 
now not sure, if it outweights the usability aspect. I simply remember, 
that I liked to use the AMOS basic. Because it allowed cool things 
rather easily. And if users like the system they use, they will use 
it, and extend it. And sometimes it is about how cleverly the code 
is organised. We will see, how it turns out ...

Max - a good one :-)

And because style has 'options block, which maps to inlined parameters 
("OK" string in above example), what I am claiming is a name clash/confusion 
here ...

I can rephrase the question - how does user define, creating a style, 
what might be declared in an options block (dialect level, my-field: 
"test"), and how is such options block being evaluated, and values 
being assigned to facets?

Let's assume I set button in bounds (between what min-size/max-size 
allows): I tried various scenarios, and I almost never got button 
of requested size.

 - yes, the size is always a result of resizing rules, as applied 
 in a specific style. There are two methods working quite differently, 
 the first one is used by vgroup/hgroup, the second one by vpanel/hpanel. 
 If none is what you like, then there is a possibility, that you would 
 like to have a completely different style, with different resizing 
 rules...

If you really want to have a completely different style, with different 
resizing rules, you should carefully write down your requirements/ideas 
so, that it would be clear how it would work.

- In regards to above point, I really wonder, if buttons should be 
resizable at all. I said - resizable, not settable. I wonder, if 
I would like buttons to be of consistent size. I might try with face/resizes?: 
false, if that would make the trick.

 If you set the RESIZES attribute to OFF, you get a completely different 
 behaviour, than what you expect:


- the resizing algorithm will leave the button untouched, which means, 
that it does neither compute the position, nor the size, and the 
button would just "float" - the next version will contain more than 
20 different examples, Cyphre's visibility example manipulating the 
RESIZES attribute included


- if you just want the resizing algorithm to not change the size 
of an element, while allowing the resizing algorithm to compute the 
position of the element, you should do it differently. Just set the 
INIT-SIZE, MIN-SIZE and MAX-SIZE of the element all to the same pair. 
You will notice, that the size of the element will not change, no 
matter what, only the position may change.

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

Wrong, reasons: 

- those values clearly *are* options the user specifies

- the fact that some options may be inlined (i.e. the name may be 
used in another context) does not change that in any way

- what is "deep" about saying you don't like a name (in an arguable 
case) is beyond my understanding

- renaming to "facets" would not help anybody including Pekr as he 
surely knows

OK, and I think you are wrong too, and we can let it that way :-)


the fact that some options may be inlined (i.e. the name may be used 
in another context) does not change that in any way

 - yes, it does. So far I can only follow my brain logic, which simply 
 was confused. Well, I could admit, that I am dumb :-) But the chances 
 are, that some other ppl might be confused too, so my answer is:


- style/options does NOT clearly define, what options user can set 
in dialect options block, because that block, is SUPERSET of the 
style/options. It allows you even to define whatever word, without 
the word being a regular facet field:


>> view [b: button options [ble: func [][print "huh?"]] do [b/facets/ble]]
huh?


I wonder if that might even be a security issue, to pass such a function 
via the options block? So - how is that options block even closely 
similar to what style/options is? Those two have completly different 
meaning/functionality :-)

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

This is part of Carl's original design and I imagine that he made 
the idea of "slots" as you call it, so there is a simple way to map 
grouped areas of code to faces, when they are created. Note in the 
source, the definition of a style and a face are right next to eachother. 
So it becomes "how do I create a face from a model of a face, as 
quickly and easily as possible?"

Yes, no problem if explained - just my thought chain was - how is 
that I can see some values being specified in an options block in 
a dialect level, which I can't see defined in style/options? That 
is all. If documented, maybe no confusion is going to happen. And 
maybe - not all ppl will think the way I was ...

You named them "slots" first, so that was the word I use, but the 
words you use there are distinctly different. because this is an 
attempt at creating a sane interface for the face. In VID, you didn't 
have that. There was one single object and it was flat, and therefore 
could become large.

release date: Cyphre will not be available to commit a new release, 
and some scroller, etc. changes are on the way, so, the release will 
happen on Monday or Tuesday

Wasn't there a fix to binding draw blocks in the last release?

I think Cyphre is working on a change to make it easier to use.

OK, I am fighting for three weeks with this or that, and I feel like 
giving-up and going to health-leave too ... I should not have played 
a soccer yesterday :-)

Could I ask you for a download link?

yes, I was just uploading a zip:
http://www.colineau.fr/rebol/downloads/tests-R3Gui.zip

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)

It only has a title extra over a non-crashing version

At one point there was a guard added to make sure that SHOW-NATIVE 
was only redefined once, to avoid that stack overflow.

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.

to summarize: open a new cosole, launch directly demo:
do %demoJC.r3, and it should work ok.

I have to leave, now
Anyway, I wish you a fruitful conference.
bye

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.

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

I have put a new version of test-demo, where the status of what is 
working and what is not is mentioned, and the crashing actions and 
faces are disabled. Pekr, I have not yet integrated your fix for 
the doc style ... later
http://www.colineau.fr/rebol/downloads/tests-R3Gui.zip

well, some of tickets are not clearly a bugs, but misconceptions 
... which most probably might get dismissed because of my incorrect 
understanding of the topic. But I wanted to have it "recorded". I 
just don't know, if RMA works with those tickets, as e.g. Doc style 
fix is not yet commented. I will wait for new release and we will 
see. Hopefully together we might get the demo working. I expect the 
biggest problem being in the area where new box model is involved 
... we will see ...

What we're observing is a regression over years

It's been a year now

It's one of the base rules of software engineering to keep complex 
systems in a working state

The reset of R3 development was already a flagrant violation, the 
results of which we're dealing with now

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.

But it doesn't work. And you'll have great trouble getting back to 
a working state, with so many issues interfering. This alone explains 
the long time spans

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

The demo is still a good case for catching obvious bugs, so even 
if it doesn't work in the short term, due to focusing on a few specific 
styles, we get a lot of good feedback on it.

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?

So to follow point 5. above here is some update:


The next public release will be postponed to the end of the next 
week (current estimation). As we need to do some 'major' changes 
to the resizing concept. We need to add more flexibility to the system 
internals to be able implement proper column/row resizing (also used 
for dividers)  etc.


Our current internal version have lot of improvements but it will 
be better to wait a bit to not confuse developers with 'obsolete 
methods' that will be changed in the planned major update.


We are also preparing much more documentation to make things easier 
to understand.

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

Nevertheless, I don't see R3 Core is a show-stopper for RMA.

Robert - you have a business case. For many of us, REBOL is kind 
of hoby, a church, where we need a leader, that's why Carl's being 
greatly missed being more publicly active :-)

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?"

Or in any case, I made sure to also test with your version, as the 
discussion shows. It was solved, I didn't think about it further, 
and I never brought it forward as a complaint

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 ?

We shall find a way, how to put in a more informative value.

So, r3-gui.r3 is just a loader, not the whole GUI code?

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

The file with the whole code should at least have a modified date 
that matches when it was last built, or match the most recent modified 
date of its component parts.

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

For me, that makes a huge difference.

You're a good wizard yourself. You magically know what projects I'm 
going to talk about

I'm having a good laugh over here

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.

Next time when we try to promote someone's project, we'll have them 
sign a contract in advance stating that they want it

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.

the change log for A111 does not claim such a thing

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 ?

After checking, I confirm that the version that I used is different 
from the version presently available at this url. I will do a first 
trial with the new version (but probably not an extensive check).

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

RMA seems not to understand (or it is not its priority) the importance 
of visuals

 - That is not correct. The visual design is prioritized exactly where 
 it needs to be: When the architecture is settling. It would be *crazy* 
 to start doing skin work now, as styles are changing all the time. 
 I once fell into that trap on a project and spent 6 months redesigning 
 the same skin and in the end, we got nowhere.

I definitely request scroller being progress + arrow button based

 - I suppose you mean slider instead of progress? Anyhow, I'm not 
 sure that's likely to happen, as a slider is not the same thing as 
 a scrollbar and there would be too much code needed to write both 
 so they fit together.

scroller could be just progress + 2 arrow buttons

 - and that won't happen, because it's an inflexible solution, when 
 we start working more seriously on the skin, where each arrow will 
 likely have individual draw blocks customized for each direction. 
 It only works in simple GUIs like VID, where the appearance is just 
 a pixel edge and some flat shading. In that sense, it might make 
 sense to have a separate arrow style, but it won't work here.

If we don't reuse the code, then I wonder, if we have not failed 
design wise. Because then it leads to reimplementation of arrows 
for each particular style, and then no wonder that we are in a messy 
situation, if each style uses different arrows?

We reuse the code when it makes sense. In this case it doesn't necessarily 
make sense, because an arrow is a rectangular button with a particular 
draw block. There is no gain in trying to cram it into the scroller 
style, because skin-wise you will need to adjust it anyway, which 
is more code. That may not be the case in the finished scroller style.

I don't necessarily want styles being somehow magically compound, 
if the only thing you need is to use a draw block, and in fact "integrating" 
multiple styles together is even beyond my imagination technically 
wise, but I request identical visual representation ....

Cyphre promised to update the documentation for the boxmodel, as 
a part of the upcoming update.

The updated version of the %r3-gui.r3 currently looks as follows:

REBOL [
    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 
at

http://www.rebol.com/r3/rsl.html

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

Seems ok.
Mayby a link to the page with the changes list ?

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]

Have read much noise here.
Just sitting on the side of the REBOL river.
Everything that will come is a gift for me.

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.

When you hover over a tab, the indicator changes to red.  The green 
indicator indicates the current tab, right?  So, you actually lose 
information.

Would it hard to create a different indicator of what the current 
tab is . .. such as a higher tab?

I think a higher tab has more visual impact

and is closer to the metaphor of pulling a tab out of a filing cabinet... 
in real life tabs don't change color

Yes, there's a state change

the other argument is  that a tiny led indicating current tab which 
uses 5% approx of the tab surface vs the 100% if you raise the height 
of the tab

btw, the same argument applies to the toggle button ... a tiny led 
to indicate state does not have a large visual impact

Some of those color combinations I find hard to read ..like the white 
text on a gray/white button background

a little problem (perhaps only with wine) it is the resize of the 
application with the left bottom corner. the app seem to not find 
a good size !!!! flashing !!!