AltME groups: search

maybe Cyphre did some changes in AGG ...

agg changes in 2.7: most of the dialect changes/bugs are probably 
because of the internal string change Carl mentioned. i don't know 
of any major changes by Cyphre.

Cyphre, you should make sure, Carl is using the right DRAW source, 
when building for OSX.

Cyphre, you might wanna see my comments here: http://www.rebol.net/cgi-bin/upnews.r?view=0011#comments

Maybe you can give it better meaning, how it should work, than I 
did!?

Cyphre, under OSX, the transformed image has wrong colours. I think, 
the tuple is turned around. I'll make an image for you...

Cyphre, so SPLINE is most likely faster than LINE, because it's not 
separate lines as LINE is?

Cyphre, you can see the transform bug here: http://www.fys.ku.dk/~niclasen/rebol/transform-bug.png

Cyphre, my goal is to get Canvan RPaint for version 1.0 and work 
the same on Win, OSX and Linux. Then REBOL/View is in a condition, 
I'll call good! :-)

Cyphre, so if you can do anything to get text support in DRAW (under 
OSX and Linux??) and also push Carl to have prober event handling 
(something I haven't reported yet with the new Mac version), I'll 
really appreciate it. Maybe the time is now, where his hands are 
on View for OSX.

cyphre, has the window-to-front fix for OSX from the blog been noticed? 
someone posted a bit of code to eliminate that problem.

cyphre: oh, Carl is talking about a focusing problem, but it would 
be the same thing: http://www.rebol.net/cgi-bin/blog.r?view=0157

Has anyone tried Cyphre's my-http.r on REBOL/View 2.7.6?

I get an error here:

>> read http://www.rebol.net
** Script Error: querying has no value
** Where: halt-view
** Near: http-command: either querying ["HEAD"] ["GET"]

The point would be, were tables done correctly in RebGUI, that the 
pretty print formatting would come at cell rendering time rather 
than as input to the table. In the work I've been doing, Cyphre changed 
table for me so that it would allow sorting on strings that contain 
numbers.

It might be a good idea to patch in Cyphre's cookie handling support 
as well http://www.rebol.org/view-script.r?script=my-http.r

Gabriele, maybe Cyphre then. I just remember, or think I remember, 
that I didn't come up with it.

I asked Cyphre about his demo from 2005. It might be possible to 
do, but it's a fair amount of work.

Cyphre, can't the user set up an environment path for linux fonts?

continued from REBOL3! group.


they where not listed in RAMBO... I was just lucky to be online with 
Carl and it got fixed in a beta version of 2.7.7 in one afternoon 
with cyphre giving a more robust fix the day after.


 He also had the fix to another annoying issue which makes first item 
 to follow a space in a text to affect the transparency.  the more 
 spaces the darker it gets.  his even affects other items in a text 
 ends with spaces ! 

though I wonder if that ended up in the 2.7.8 release ' :-/

Cyphre had the second fix, but Carl disapeared then and it never 
got included AFAIK, so it may be in 2.7.8 though Cyphre would have 
to confirm this.

That is what Cyphre prefers, I am curious which approach "prevails"

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.

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.

Cyphre - your method is OK with me, with just a small note, that 
I would welcome the option to have borderless panel in the case of 
buttons in your above example ....

Cyphre - I can simply imagine, how we extend stylize to allow such 
definitions. But - in terms of html, you have IDs, CLASSes, and you 
have also the document tree, so you might know, where to apply which 
part of an CSS. What I can't imagine is - we have layout flow ... 
and no ID, CLASS definitions, we also don't keep tree information 
of the layout (faces), or do we? So how do you instruct, in your 
layout, that first button in the panel should use button-red definition? 
Just curious about what possibilities there are :-)

Cyphre - what will layout be good in next version? To preconstruct 
GUI, not displaying it?

Cyphre:

box-model:
---------------


Few notes. Certain systems use FLAGs, which could be thought about 
as kind of switches, or representing certains states, etc., used 
in binary masks for e.g. Then we have TAGs. Even R3 GUI uses tagging 
- it is used mostly to mark particular face as behaving some way, 
belonging to some area, etc. And in that regard, I wonder if box-model 
type could be done just by using TAGs? 


What I think about TAGs in GUI in general is, that we don't use the 
concept to the max. I mean - if tags were not be flat block, but 
block of blocks, it could be used even more, e.g.:


tags: [box-model [tag1 tag2 tag3] style [internal] draw-mode [normal] 
resizing-mode [.....] ....]


Of course that might not work for us in all cases, because as you 
could see in above example, it would be difficult to distinguish, 
if something should be a facet, or a tag. E.g. if we would move DRAW-MODE 
into TAGS, then why not moving MATERIAL there too, etc. My question 
is - is there any rule for me to remember - what should be a facet, 
and what could be a TAG? (I expect the difference in how you work 
with them underneath)


My general problem is, that FACETS block is becoming long and messy, 
so what to do about it? There were following suggestions to think 
about:


1) close particular settings in subobjects/maps (whatever). There 
are settings belonging to the areas of resizing, colors, box-moderl, 
others, etc. The question is, if we want to refer to such values 
by face/color/bg-color for e.g.?


2) the simplest solution is to at least use some source code conventions. 
E.g. Carl introduced comments to particular ACTORS, desribing what 
arguments are supported for the function. So my idea is:

facets: [

   ; colors
   bg-color:
   other-color:

   ;resizing
    resizes: 
    init-hint:
...
]

ALIGNment:
----------------


It is probably not wise to change all subsequent areas to halign, 
valign. But anyway, we are a bit chaotic here, unless someone tells 
me, what's the rule here - to stay compatible to html/css, or to 
be consistent REBOL wise? I mean - if various areas use ALIGN/VALIGN, 
then my logical question is - why HPANEL/VPANEL, and not PANEL/VPANEL?


My comment is just food for thought, not a claim to change anything.

Cyphre, thank you for the info and the link.

Please don't do special changes for me, unless you see a real interest 
to do so.

That is what I thought was more "natural" for native english speakers 
too. But, looks like Cyphre (maybe other non-native speakers as well) 
is not used to it, (e.g. in Czech the equivalent "content" is usually 
singular).

/CONTENT:/CONTENTS currently 5:4 (counting Cyphre for /CONTENT and 
me for /CONTENTS)

Cyphre - detailed log is not updated as announced,the last items 
are dated 18.3.?

Cyphre, I was supposing that this would be the same for style content 
as well as for layouts. Hard to explain without a deeper study of 
all the mechanics of how events are propagated or overwritten.

Cyphre: if we go for #3, will there be the option to "insert-event-func" 
like in R2 ('detect functionality), which would allow us to apply 
some filters? E.g. for dev/demo purposes?

Close the topic, Cyphre - your conclusion seems about to be right 
.....

The current overview of all styles:

http://rebol.hmkdesign.dk/files/r3/gui/253.png

Some more images here:

http://rebol.hmkdesign.dk/files/r3/gui/

A bit of status:


- Cyphre has recently fixed a bug in the hostkit with the display 
of some unicode characters. Will see if there can be a release.

- Cyphre has been working on fixing various low level issues in the 
R3 GUI source

- Cyphre is working on testing scheme for GUI and some documentation

- Bolek is working on styles and a TODO test application, called 
"Notation" for Robert

- We still need Carl to fix one particular bug, which is prevents 
creating complex layouts

how powerfull is a table style? I expect it not being full grid capable, 
as Cyphre did in the past, however what's the basic functionality 
to expect?


- column sorting - two state, or three state? (I don't like when 
I can't get back the original sorting = unsorted), but that's just 
my point-of-view, and not importan feature initially
- column filtering like in MS Excel
- how much data the table handles?

Thanks Cyphre for the explanation.

Cyphre - is there any chance Carl is going to be available to do 
some low-level fixes? It kind of crashes very often, but of course, 
with one specific use-case, so "normal GUI usage" (whatever that 
means) could be without any problems ...

When I build R3A110 and use text in view, the text is invalid. It's 
valid only if I provide it as UCS2, like:  g_text: make gob! [size: 
100x20 text: "^(41)^(00)^(42)^(00)"]

Does anybody (except Cyphre, who is not here) know, what can be wrong? 
I build it with CodeBlocks.

I think the file you're looking at is not really part of AGG, but 
written by Cyphre as a bridge between AGG and Windows

Btw... it's the reason why I'm hacking the code... I would like to 
enable bitmap fonts. AGG supports that, but I don't think that Cyphre 
has enough time to work on it alone:)

maybe with HW acceleration, it will not be that much? But we have 
yet to see Cyphre's integration of such a stuff ...

Cyphre - but we want to create MS Word clone, so megabytes of text 
are expectable :-)

Cyphre - what was the result of your acceleration experiment (not 
talking JITTer here)? I do remember it provided some further speed-up 
to some folks here (not to me on intel chipset). Will it  be added 
to hostkit by default, if it works under all Windows versions?

When rebols meet :-)


http://www.xidys.com/pekr/rebol/two-rebols-cyphre-pekr.jpg- some 
3 years ago

http://www.xidys.com/pekr/rebol/two-rebols-ladislav-pekr.jpg- one 
month ago

Jokes aside, guys - yes, we are getting older :-)

Cyphre, did you test with R2 or R3?

Cyphre, Robert reported this from a customer, who I assume is running 
Windows natively.

Cyphre, thanks a milion!

Cyphre, in your example, when you insert the first x in the block, 
it's the x holding the value 10. To me, the x in the block is bound 
to the outher x at the time, you insert it into the block. The next 
x, you insert in the block, is the x from the context o. So at the 
time, you insert it into the block, that x in the block is bound 
to the x in o.


So the block holds two different x, and they're bound at the time 
of insertion. That's what I meant, when I said "the binding of words 
in a block is done, when the words are put into the block".


(Words can be rebound at a later time using e.g. BIND, but I'm not 
looking at that in these examples.) I don't have time and energy 
to argue with Ladislav right now. :)

i've never had to copy the block passed to context for eg.
 - many people never had, but:

* Cyphre fell into "the trap" when writing async code

* the code written for R3GUI has to use copying due to the way how 
it is implemented

Cyphre fell into 

the trap" when writing async code" - as it stands, async code is 
"too hard" in REBOL. (IMHO of course.)

OK, since nobody objected, I shall proceed with the preprocessing 
directives user-poll:


- in the current INCLUDE, the PREBOL directives are made standard, 
while other directives, like COMMENT are made "user-defined", which 
means, that they are defined "on-demand" only


Since in RMA, we actually used the COMMENT directive as "standard" 
for quite some time, there is a suggestion (by Cyphre) to make it 
standard as well. Any other opinions on which preprocessing directives 
should be made "standard" and which ones should be "user-definable"?


Just a note - switching this in the code is trivial, it is more of 
a standardization issue, than a problem of work in my side.

Regarding the translation functions: yes, the directives do not suffice 
to supply all the necessary functionality. Other code is needed to 
handle the run-time translation of "marked" strings. That code was 
written by Cyphre and is influencing the behaviour of RebGUI widgets 
to show the currently required language version of the text.

Why does the STRING! constraint exist?

 - Cyphre and I thought, that it may be of help for the programmer 
 to tell him that he "forgot" to put in strings. Even the numbers 
 are unlikely to be put in unformatted.

Cyphre was against it, and, in fact, it is not needed, since you 
can substitute so, you can generate any string you like this way.

I suggested the #"%" character as an escape, but, Cyphre is right, 
that it is, in fact, not needed.

the advantage would be that you don't have to allocate a substitution 
argument for that % escaping

 - yes, understood, I was originally for that alternative, but, Cyphre 
 convinced me, that for human writers, actualy the substitution is 
 more readable

Cyphre: thanks, will try that ...

Under OS X using gcc, I get bool length 1 both with Cyphre and Andreas 
versions, and also with or without -std=c99 option.

Althought not precisely undestanding the topic, I might agree with 
Ladislav. Now if I am not wrong, then e.g. Cyphre's JIT code could 
be regarded being kind of REBOL dialect - it looks like REBOL, it 
might have syntax like REBOL, you just can't do all the tricks with 
it. Whereas we could not say the same about e.g. a RebCode? Does 
it make sense, or am I wrong?

Cyphre: thanks! Need to fix the README to point to R/View...can't 
believe that struct! is not supported by Core...Damn limitations...

Cyphre says that it's easily possible to use the AGG part outside 
of R3.

IIRC, Cyphre once said, that idea for R3 was to add some port or 
other low level encryption functionality, and that https etc would 
be done in REBOL level, using thow low-level facilities ...

The reason why I am also opting for such an aproach is, that there 
will be possibility to inline Red/System in Red itself, so it should 
look similar, where possible. I e.g. liked how Cyphre did JIT to 
R2 - the code still looks like REBOL, it is just a limited subset 
...

One question towards library wrapping and type casting. One DLL function 
is defined as:

typedef bool (WINAPI *LSN_OPENCARD)(void);//open led card 


When I defined the return type of wrapper funciton as LOGIC!, it 
was always true. When I defined it as an integer, it was either 1, 
or some really high integer number. So i took Cyphre's advice towards 
R2's interface, and in R2 I used CHAR, and in Red/System, I used 
BYTE! type.


Pity construct of a type return: "as integer! [byte!]" is not allowed, 
but at least I now get correct result - 0, or 1, in my print statement, 
where I do: print [as integer! led-open-card lf]


So my question is - why using Red/System's LOGIC! did not work? Is 
C level BOOL a clearly defined type, or can it be defined in various 
ways, so I can't say, that I can automatically use LOGIC! = BOOL 
logic, when wrapping stuff?

If you do copy-on-write then TO-BINARY some-kwatz-value would be 
able to work on the same data, at least until you modified it. That 
would make the binary-vs-kwatz distinction less important. Nonetheless, 
Cyphre's solution of having an internal flag on the binary! type 
to mark it as kwatz! and a KWATZ? function to test for it is similar 
to the fake datatype trick used in R2 2.7.7 and 2.7.8.