r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3 GUI]

Pekr
29-Mar-2010
[1287]
those things you mention (more styles) can be done even in recent 
VID state? Do you regard architecture being stable? E.g. - I remember 
you (and me too) did not like max-size. But it is basis of Carl's 
resizing model calculation. So no fear of later changes on your side?
Henrik
29-Mar-2010
[1288]
One never knows if the architecture changes, but I don't think that's 
likely. There are some things that are unclear with styles, such 
as how to change FACE/CONTENT dynamically, but otherwise there is 
plenty of styles that can be implemented.
BrianH
29-Mar-2010
[1289]
Henrik, for once the docs about the design were preceding the implementation.
amacleod
31-Mar-2010
[1290]
Playing with R3 GUI...I see panels and groups resize horizontally 
but is there a way to get it to resize vertically...or does that 
involve playing with the style code?
Graham
1-Apr-2010
[1291]
resizing is said to be broken .. so I'd wait
Henrik
1-Apr-2010
[1292x2]
yes, this is currently broken.
I need to ask who has read the whole source code for the R3 GUI?
Pekr
1-Apr-2010
[1294x2]
you, BrianH, and me :-)
but I am a lamer, not a coder, so I can only bug you with many questions, 
and point out some things I eventually don't like (and in many case 
I don't like them because of my wrong understanding of the topic 
:-)
Henrik
1-Apr-2010
[1296x2]
Pekr, do you find it understandable? Does it help you to understand 
how it could be extended?
ok
Pekr
1-Apr-2010
[1298x4]
VID3.4, from what I have seen, is more understandable than VID2. 
Maybe also because we now have docs, describing faces, their fields, 
on-* methods, etc.
What I did not like in the past was departure from multiple gob design 
and make-gobs, and limiting style to single draw block. But later 
on BrianH explained to me, that the design is ready to use multiple 
draw blocks (kind of original frames concept)
where my "experience" ends is event - mainly keyboard, editing. Rather 
difficult topic for me. So I am still eager to see, how keyboard 
navigation is going to be supported. This is BIG topic for me. Because 
as I already said in the past - users are forgiving non-platform 
specific look, but not behaviour. And I am a person using keyboard 
so much. So tabbing, accelerator keys, ability to swith tabs by ctrl+ 
tab (non trappable by REBOL at all) etc. - those things were not 
adressed yet ...
E.g. such simple thing as displaying the accelerator key - under 
windows, you can see underlined letter, representing the keyboard 
accelerator key. But - that would mean, we would have to use rich-text, 
for such things, as button, or even fields, etc. Or - we would have 
to come-up with different concept - e.g. pressing Alt key displaying 
small boxes around the styles, displaying the accelerator keys (layers 
could be used here) ... such concept is used by Lotus Notes ...
Henrik
1-Apr-2010
[1302]
Well, the keyboard navigation in the VID Extension Kit is a much 
bigger hack than in the R3 GUI. That's thanks to a good design and 
treating the window itself as a style. There are still some issues 
with Carl's method of tab navigation colliding with mine. Carl has 
a tendency to work functionality that should be generic into a few 
specific styles. I don't really get why he does that, because it 
scales like crap.
Pekr
1-Apr-2010
[1303]
So - there are still some design choices to make. And what I miss 
is discussion about those topic, unless we go too far, to later realise, 
we have to rebuild somehing because of new ideas ...
Henrik
1-Apr-2010
[1304]
accelerator key visibility is missing from spec. do you want to write 
something up, just to collect notes? I can clean it up later.
Pekr
1-Apr-2010
[1305]
Yes, I can write something up ... I already did with Marketing related 
documents (waste of time :-), but it will just collect basic requirements, 
I am not able to outline, how should it be done ...
Henrik
1-Apr-2010
[1306]
ok, thanks, that would be good. just post it on the discussion page 
for the specs.
Pekr
1-Apr-2010
[1307]
Can you post a link to your doc on DocBase? Can't find it from menu 
...
Henrik
1-Apr-2010
[1308x2]
http://rebol.net/wiki/R3_GUI_Specs
created a section called Accelerator Navigation. you can post in 
there.
Ashley
1-Apr-2010
[1310]
who has read the whole source code for the R3 GUI?

 ... I have, and my gut feeling is it could be made simpler without 
 much loss of functionality ... it just feels too "denormalized". 
 That's not intended as a criticism, but a statement of [my] preference.
Henrik
1-Apr-2010
[1311]
right
Steeve
1-Apr-2010
[1312]
I Agree, lack of factorization. It should not weigh as much...
BrianH
1-Apr-2010
[1313x2]
I haven't read the GUI source in a while, but remember it to be kinda 
disorganized. That is what prompted Carl to make a module system.
So, same impression as the rest of you.
shadwolf
2-Apr-2010
[1315x3]
 AGG group about a bug in TRANSLATE

. henrik not a news that bu exist since 3 years i submited it long 
time ago when i was implementing matrix translation in AGG when i 
was writing SVG renderer. So far no one seemed to care about that...
So far there is no high level widet like flexible tables  treeview 
etc...
windows still can't be transparent
Henrik
2-Apr-2010
[1318]
the bug has already been fixed, so this will be available in an upcoming 
R3 build.
shadwolf
2-Apr-2010
[1319x10]
no note view no status bar no menu bar no menu pop  that still very 
rought interface ....
henrik  glad to hear that
no tooltip ...
( and on tooltip using AGG some cool effect can be done there ... 
 ( like a progressive fade away in time) )
it's a pain every time you need an advanced widget to have to do 
it from scratch  you then spend alot of time  designing widgets instead 
of inputing fonctionalities to your software
widgets should be organised in my opinion in 2 categories the first 
one are the "most used ones" not every one will put a tree view or 
a menu in his main windows but everyone will put  labels fields and 
buttons to most of their applications
the second categories countains the set of high level widget wich 
include a lot of time of  developement and though about how to give 
them flexibilities and extensibilities  not to end with a list-view 
widget that is able to display nothing but text like in R2.  Those 
widgets and widget set should be able to evolve in time and ofcourse 
without impling a redistribution of the complete R3 view stuff.exe
i liked pretty much the idea of an advanced high end side widget 
library like REBGUI . It evolved so much faster than View in  last 
years. and the result is nothing to deal with the rough aspect of 
the basic VID
maybe  this set of "advanced widgets" can be updated automatically 
through internet like rebgui was. IT depends in fact on how often 
do we plan to update the widget library  if its once or twice a year 
then it can be done through regular R3 release if it's more ofthen 
then we need a way to update the advanced library more often
for example in viva-rebol.r project advanced side widgets take 95% 
of the source code lines writen ( and i compressed some of them) 
OK viva-rebol involve a new way to deal with text in an extensive 
and heavy way okay but still a hudge part of this project are nothing 
but one time used widget and that's a true waste!
Pekr
2-Apr-2010
[1329]
Shadwolf - why don't you just read new VID3.4 docs? It is clear new 
VID does support creation of advanced styles, and IIRC Cyphre will 
do grid (table) widget for R3 ....
Maxim
2-Apr-2010
[1330]
just a quick (yes/no) question wrt VIEW R3 (not VID) cause I've got 
no real R3/view experience:


can we draw graphics clipped within other arbitrarily shaped graphics?
like a box clipped to a circle or spline curve?
Steeve
2-Apr-2010
[1331x2]
yes, in 2 steps (not specific to Rebol).

Make a mask with your shape, then apply the mask on the second graphics 
(you can use 2 overlapping gobs to do so).

Don't know if it's possible to do the 2 steps in only one gob though.
but it should be
Maxim
2-Apr-2010
[1333x2]
no I mean the mask crops the other shape, so that the box appears 
to be "within" the other (circle), even if its drawn OVER it .


its not just a question of layering two objects one over the other.
or did I mis-understand your explanation ?
Steeve
2-Apr-2010
[1335x2]
So i don"t see your point. To me, It's just doing the same thing 
you requested, but it seems you want something else.
Or can you reshape your asking ? :-)