AltME groups: search

Maybe provide a unzipped download for the r3-gui as well? So that 
we can directly DO the url?

This setup will raise the release frequency of R3-GUI a lot as we 
will use automatic scripts to update it on the server.

There shouldn't be any unless you use binary compression or a checksum 
without compression.

nve, you need a "view" build of R3 in order for the GUI to work.

I'm going to upload our internal build in a couple of minutes.

I tried to use SciTe editor to run a simple gui script: rebol [] 
 do %r3-gui.r3 view [button]

running the same script from command console: "r3.exe testgui.r3" 
works just fine. It opens a new console window with the same output 
" REBOL 3.0 A110 2-Nov-2010/3:56:20 handler added" and another window 
showing the button

Maybe anyone has a tip how to fix this, I know this is SciTe problem, 
but I wonder whether other editor has the same problem. Thanks!

Cool! Thanks a lot Edgar! I really appreciate this.

Pekr, that's list-box (text-list) style problem. This style is currently 
updated to support more columns than one (called text-table) and 
text-list will be only sub-case of text-table.

The new distribution channel may bring problems like this for regural 
users, at least before BETA is reached. Some developers prefer to 
put changes to SVN only when everything is ready, other developers 
prefer to push changes more often, it might temporarily broke functionality, 
but  it's much more crash-proof strategy.

It's a question to debate if every submit should be a release, or 
if only some special versions should be released, with first option, 
you will get latest release, that may be broken because of we're 
still in alfa-phase, with second option you will get more or less 
working release, but you're definitly going to complain that it's 
not updated too often (even if my estimate of 1-2x week is hit.)

Thy psychological trick is, that ppl will consider any such visual 
tool being a demo ... the one expecting to work. Prior R3 demo was 
nice app, pity it is not included with the releases anymore ...

Prior R3 demo was nice app

, from what I believe, that app served the same purpose as the style-browser. 
Having Carl's R3 GUI being more limited, it could be considered more 
bug free than the current version, thus made a better impression.

whatever ... this is just playing with words, and I think it does 
not matter, as it is not a big deal (btw - when I found the bug, 
I reported it). My observation though is, that ppl naturally expect 
some visual demo or something like that - being it a former demo, 
or a style-browser - it does not matter. So - hopefully when things 
turn more stable, we could ask Carl to link R3 console demo function 
to launch a style browser?

this is just playing with words, and I think it does not matter

 - sorry, I think you don't understand the importance of the style 
 browser as a *testing* tool rather than as something to show off 
 with.


If we blamed the style browser for the bugs, we'd never finish the 
GUI. I really mean that style browser bugs are irrelevant. Any more 
development on it would be to make testing more thorough. At this 
stage, it's important to build the programs as we want to see them 
working, and if they don't, the underpinnings are to blame and should 
be change to accommodate the needs. That is what's going on now.


We publish the style browser to help users get the quickest possible 
overview of the styles as they are right now, crashing or not. Showing 
off is too early.


It should be possible to have the style browser as part of the demos.

A RETURN keyword poll.


The RETURN keyword is used in groups (Hgroup, Vgroup) to signal the 
end of line/column. Panels, however, neither need nor can use RETURN 
as a keyword. There is a question, whether the RETURN keyword in 
panel specifications should be:

a) silently ignored
b) considered an error

As far as I am concerned, I am slightly in favour of the b), which 
makes the starting score A:B=0:2

b) -- also gives you the option to add a meaningful RETURN for panels 
later on.

It may be helpful to put a warning in the style browser GUI

This is not a demo, this is a style browser, just like the label 
says.

Browser still sounds like a working utility. It could mention that 
it's for testing the styles and they are currently expected not to 
work

I used to develop a Chinese Font Engine in R2 using Win32 API GetGlyphOutline(). 
Now I am trying to do it again in R3, but this time I will get the 
glyth data from OpenType font files directly. Basically, I can read 
the Glyph data now, However, when the glyth has zero contour, my 
OpenType font format parser got error. The OpenType Spec offered 
by Microsoft is not clear to me on this.... Hope I can solve this 
problem soon. I cannot wait to see Chinese Characters in My R3 GUI. 
:-)

So, the current state of the RETURN keyword poll is A:B = 0:4

A show face user poll:


We decided to introduce a face attribute allowing to implement the 
following show states of a child face of a panel (or, eventually, 
other container):


1) the face is visible and it resizes/repositions together with its 
parent panel

2) the face is invisible, but it resizes/repositions together with 
its parent panel, reserving the appropriate amount of empty space 
for itself

3) the face is invisible, it does not resize/reposition itself together 
with its parent panel, the positions of other faces in the panel 
aren't influenced by the presence of the face

4) the face is visible, it does not resize/reposition itself together 
with its parent panel, the positions of other faces in the panel 
aren't influenced by the presence of the face

Possible implementations:

===A


Define a new SHOW? facet (you may indicate your preference to use 
a different attribute name, if you like), which could be set to one 
of the following four REBOL words, corresponding to the above defined 
face show states:

A.1) VISIBLE
B.2) HIDDEN
C.3) IGNORED
D.4) FIXED


(you may indicate your preference to use different words, if you 
like)

---Advantages


*The user can to determine the show state of the face by examining 
just one attribute, the SHOW? attribute.

*When using an appropriate function, the user will be able to change 
the show state of a face by evaluating a

    SHOW-FACE state

expression.

---Disadvantages


*Data are not normalized, seen from a data-related point of view 
- if a user sets the FACE/GOB/SIZE value inappropriately (e.g. if 
FACE/GOB/SIZE is 0x0, while the SHOW? attribute is set to FIXED, 
or, if the FACE/GOB/SIZE is non 0x0, while the SHOW? attribute is 
set to HIDDEN), the state he obtains will not be consistent.

*Speed - since it is necessary to test which of the four variants 
has been chosen, we need to use four tests in resizing code, i.e. 
the code becomes slower.

*More complicated code - it is necessary to take care the state is 
consistent, which may require more complicated code, maintaining 
state consistency.

*Documentation - the users need to be aware, that not all changes 
produce consistent state.

===B


Since the invisibility of faces is already implemented by setting 
the FACE/GOB/SIZE value to 0x0, we need to implement only an attribute 
telling, whether the face resizes/repositions with its parent. A 
RESIZES? attribute (you may indicate your preference to use a different 
name of this attribute) is used for the purpose in this variant, 
possible values will be TRUE and FALSE.

---Advantages


*Normalized data - all four possible state combinations are meaningful, 
and consistent.

*Speed - when needing to test whether the face needs resizing, only 
the RESIZES? attribute needs to be checked.
*Code simplicity

*Documentation - the user does not need to memorize the possible 
inconsistencies

---Disadvantages


*The user does not have the SHOW-FACE function, but, if required, 
it can be implemented easily, it can even use the keywords mentioned 
in the A variant, just translate the state to respect the B implementation.

*The user will not find the keywords in the face data, but it does 
not look like a disadvantage one should be afraid of.


So, please, indicate your preferences for the show state implementation. 
As far as I am concerned, I am strongly in favour of B, so the initial 
score of the show face poll is:

A:B = 0:1

I'm not saying is should be same as above. I'm just trying to find 
out the layout dialect based initialization for all the 'modes' so 
it is easy to use for people. I understand the SHOW-FACE function 
is not a problem to use in both variants once the layout is already 
'running'. I worry about the init part though...

Initialization is hard: for a FIXED face we still don't have a way 
how to specify the offset, do we?

GOB-OFFSET - do I understend correctly, that it is a new facet, which 
is "permanent for all faces", while being needed only for initialization?

a similar approach might be useful for HIDDEN faces as well, I guess

I prefer a normalizexd model, as long as it makes sense and is easy 
to work with. So, tentative support for B unless we can come up with 
something easier.

I didn't mean that. Of course you hide something when it is set to 
0x0 size. I was asking if that was how you set something to be hidden: 
setting it to 0x0 size. That might have interesting effects on the 
layout of its contents when it is unhidden, while a hidden property 
would not.

Changing the topology of the panel by ignoring the face requires 
some considerations. What happens if a focused face is ignored?

There is a demo of above mentioned features here:

http://94.145.78.91/files/r3/gui/panels-24.r3

It requires the latest sources. I'm not sure a build is made yet.

wow, a progress ... will read it shortly .... guys, I have one question, 
which will most probably get dismissed, but I'll at least try to 
ask:


- when prototyping stuff in console, and e.g. when your gui crashes 
from some reason, I am very used to just "unview". But - in R3 I 
have to do either "unview none" or "unview 'all" (not caring about 
the name of the window)


So my question is - couldn't the aproach be rethought, and old R2 
functionality brought back? Especially "unview 'all" in comparison 
to (imo) more rebolish R2 "unview/all" is non intuitive for me ...

About showing faces: In R2 I found it quite annoying not to be able 
to create an image of a layout without viewing it on screen first.

If I did things like set the face size to 0x0 or move the faces outside 
the window bounds, clipping would introduce artefacts (black regions 
not supposed to be there) in the image created by TO-IMAGE.

So, in R3 at least, I'd like to be able to create an image of a panel 
layout in R3 without first viewing on screen.

I think I thought that an UPDATE FACE function, being similar to 
SHOW FACE, except without the final copy to the window buffer, might 
be what's needed.

Anton, as long as you have a face you can to-image it.  no need to 
show it first.  I've done this many times.  many your problem is 
related to a specific style like a iterated face.

Late to the game, but


as for A) - don't we have already tags? It could all be in the tags 
block, not in the new field. And if tags block is just flat, and 
those for states could collide with another flag names, we could 
use nested blocks flags: [ show? [visible]]. I see no reason why 
to introduce new field, unless from the speed reasons

Generally I like B) more, but:


I definitely don't like being dependant upon the size of 0x0? That 
seems really strange to me. Visibility state in the gob-tree should 
be imo independent from the size? E.g. look at Cyphre's code example:

button 0x0 "test" options [resizes?: true]

Do you really want to see code like that in the VID level?

Cyphre: "Brian, yes, what would you want to see on the screen if 
something has zero size?" - really, I am not sure I care about if 
something is theoretically visible in 0x0 size, because face itself 
will not have a meaning even with 1x1 size, but I think that visibility 
(event flow) should be separate. OTOH, I can't find any practical 
reason how it could be internally usefull to have some inner state 
as shown, while being at 0x0. I thought about some graph models, 
event flows via the face hierarchies, etc., but with 0x0 size, you 
can't receive events anyway (apart from timer events maybe)

Max - speak on :-)

Yes, generally all possible states - visible ignored fixed hidden 
no-resize etc. could be part of a bitmask, and IIRC that is the aproach 
win32 is taking. I thought that named bitmasks are implemented, but 
they were removed.

But some states are mutualy exclusive, so this is not such a good 
idea. You can also achieve the same with block!

Yes, not a big deal for me ... except the idea of using size 0x0 
to express the hidden state :-)

I don't agree with having 0x0 as hidden. It is an implied state, 
that would occur any time the X or Y size becomes zero. There are 
behavioral issues to consider, such as, whether you want to obtain 
data from the face, using GET-PANEL, or how tabbing and disabling 
behaves with a zero sized face. If the layout is dynamically created, 
so that a face is inadvertently presented as zero-sized, you will 
get topological side-effects.


For animation, you would have a start and end position. Animations 
should not express anything about face states. Only dimensions, offsets, 
transparency, colors, easing are relevant with animations.

For that matter, a face can also be considered hidden, when its parent 
is 0x0, or if the face is located outside the viewport of the parent 
face.

SET-FACE is already reserved. Adding HIDE as a shorcut is of course 
possible.

that a face is inadvertently presented as zero-sized

 - this may occur, should a style implement its own layout engine, 
 which is possible to do.

hmm, I lack imagination for all possible usage cases. But we should 
have in mind the most complex scenarios, which might be some animations 
along with timers, simply a graph structure.

A new one, not posted yet

I agree with Henrik, and I reiterate my uneasiness with face size 
0x0 == hidden. Conflating the two concepts creates the problem of 
how to separate them, which may be difficult, or impossible.

I would not like that in order to hide a face, I would have to set 
its size to 0x0. That means that in order to restore the visibility, 
I must store its previous size somewhere else. So squashing two concepts 
into one value means one or both of them just pops out somewhere 
else, confused, or some state information is lost.

Steve, on window close issue, we need to decide.


The issue is this: when use hits a close button (or causes OS-side 
close event), do we close the window at the host layer, or do we 
send an event, allowing the higher layer to pre-empt the close.

Steve, a few comments on script interrupt...


Yes, currently, we use CTRL-C. But, it's purpose must be better defined, 
because there are really 2 types of interrupts that we want to process.

1. script interrupt: does a halt
2. program interrupt: does an exit

What we want eventually is for host-kit to detect ESC, and call RL_Escape 
for that too.  But, that requires that we use raw stdio processing 
(or use an OS that's good enough to detect and signal us on a specific 
key press), so it's not implemented yet.

By script I mean a shell script but it could also mean REBOL script. 
:)

It is also possible for a window close to fail if the EVT_CLOSE event 
cannot be queued. This situation is currently ignored in the Windows 
implementation.

Inability to catch window close is a defect in desing, easy as that 
...

I don't understand low level implementations much, but once again 
- I regard eventual non-ability to control such behaviour as windows 
closure from my script, a defect, not a feature :-)

I don't use it in my scripts. Maybe I used it once. But - I don't 
want to explain to eventual client, that REBOL as a platform can't 
offer such a feature as a dialog box warning before the close of 
the window happens ...

I suppose I should go file a bug report right now so we don't forget...

If you don't have the ability to intercept the closing of the window, 
then you will cause data loss in apps, and not giving the program 
a chance to clean up (temp files, file locks, etc.) when quitting. 
Tthis deals with more than plain warnings of window closure. This 
is a UI and app specific behavior issue and should really not be 
controlled on a low level.

I'm with Petr and Henrik here. We need to get the event and not have 
our process end before we can clean up. Hard terminating an runaway 
or zombie is a different issue.

Filed a bug report.. bbl

The trick is to partially link all objects into an (internally resolved) 
single object and then use this to create the shared library. So, 
for Carl's example, that boils down to:

  ld -r -x -o lib.so a.o b.o
  gcc -dynamiclib -o lib.so lib.o

Here's a full package illustrating this:
http://bolka.at/2010/misc/exports2.tar.gz

guess it would be a .lib

A: yes, can export static lib for OS X and Linux.

Cool, Steven. Can you upload a screenshot? We like to have material 
to show progress with and I keep a library of screenshots.

Henrik: I have a blog where I'm going to try and document my progress.. 
see http://solie.ca/

Pekr: AGG is very quick  which is why it renders so nicely but it 
is all CPU bound (no h/w accel) -- I would appreciate a benchmark 
because I think we should be compiling AGG with -O3 given it is C++ 
code heavy on templates

Some say that video is based on an inefficient color conversion process. 
Others say that Flash uses a really stupid polling mechanism. I think 
there is a garbage collection issue, but that is again hearsay.

I know that some things in the Apple APIs wrt access to the hardware 
where never opened up and could only be used by apple themselves. 
 its possible that some people figured out how to hack their way 
through this, but flash is embedded in a browser, so probably can't 
since there would be some executions conflicts between the browser 
and the plugin.   


just a guess, but when you compare flash to other adobe apps, I can't 
see why flash would be left in perpetual agony when their other software 
doesn't have these issues.  in fact, for years Adobe apps where the 
fastest ones on Apple HW.

Well, there should be no problem for us yet, no? So far, R3 uses 
SW rendering, there's not much to worry about in regards to OS-X 
API, no? Later on, as we have proper codec system, or we try to accelerate 
gfx or video, it might be a different topic.

BTW It's a shame that AmigaOS will have View sooner than Linux! It 
looks like the Rebol comunity have no Linux 'power programmers', 
or noone needs View on Linux?

yes, it is a pity. But mabe even more so - maybe many ppl would welcome 
View or at least Core on mobile OSes. Android and Wm6.5 are the biggest 
candidates imo ... (dunno what can be done about the iPhone)

Henrik, opening a browser is not really implemented in the OS X port. 
The methods that are tried are Linux conventions

Kaj, it used to work, so I'm considering it a bug.

>> browse http://www.google.com
== none

A97 pops up a browser window.

I'm trying to run the hello world example at http://www.rebol.com/r3/docs/gui/guide.html

Here is what happens when I try load-gui:
>> load-gui
i
Fetching GUI...
GUI Version: 0.2.1

(Developer test GUI theme)

** Script error: expected command! not font

 ** Where: size-text font-char-size? make make-text-style parse fontize 
 do do either load-gui

** Near: size-text gob

Is this a host-kit issue or ?

Thanks guys. GUI seems to function now after changing the fonts. 
I left a comment in REBOL3 GUI. Now I need to make the buttons actually 
work (more event work to do).

5) The amiga being such a different beast, its a good way to find 
any problems and make it a better API overall for all platforms.

We could use a Haiku or AROS person as well.

effectively yes, but tens of millions of devices out there. WinCE 
will probably stay too. Well, this was my preference because I use 
Touch Pro2, but if we decide against it, I might buy different phone, 
although there is now no alternative to such a gem like Touch Pro2 
(full qwerty)

Win7 Mo is a toy OS, as iOS is. If someone is able to port it to 
such phones, it will be good, but dunno how difficult is it going 
to be, or if it is even allowed ...

Henrik: I think we should focus on a more mobile-oriented target 
next. Haiku could be interesting given its unique API. AROS is just 
an Amiga clone so I don't see much value in that one from a host 
kit testing point of view.

I may be missing something fundamental, but


1) am I supposed to be able to build a A110 r3.exe from the sources 
at github.com/carls/R3A110 on Windows with MinGW and gcc? The gcc 
makefile differs in a lot of places from earlier versions (A109 and 
below) and even seems to generate some .so's instead of .dll's. It 
fails for me with 

gcc  -c -O1 -D_FILE_OFFSET_BITS=64 -Wno-pointer-sign -I ../src/include/ 
 -o obj/host-main.o ../src/os/host-main.c

cc1.exe: error: unrecognized command line option "-Wno-pointer-sign"
before doing anything.


2) given that I somehow manage to build it and include my own changes 
in a clone of that repo, what happens to them if once there's a A111 
repo? I don't see how a A110 repo could be turned into a A111 repo 
- I would have expected to have a R3 repo on github and to have commits 
tagged as constituting a alpha version like A110, A110 etc.

You can try do download the zip again as I did. There was a wrong 
version.

I blogged a bit about the FreeType implementation in the host kit 
at http://solie.ca/


Besides the bold/italics issue I also noticed the line length is 
not being calculated correctly or similar because the text is rendering 
beyond the window bounds. If we can fix both of these issues I think 
the FreeType implementation should be as good as the win32 implementation.

Christian, what are your hardware specs? Your unaccelereated speed 
is higher than my accelerated one and my video card should be pretty 
good. I'm getting the following stats with a Core 2 Duo @ 1.8 GHz, 
Radeon 5770 (slightly overclocked), Win 7 64 bit:

0:00:08.846 45.218 FPS | 0:00:05.125 78.048 FPS
0:00:08.45   47.337 FPS | 0:00:05.037 79.412 FPS
0:00:08.498 47.069 FPS | 0:00:05.024 79.617 FPS

AdrianS, I measured on a Vaio with a NVIDIA GeForce GT 330M graphics 
card, 8core Intel i7CPU Q 720 @ 1.60GHz, Win 7.64 bit, 8 GB RAM.

Yeah, I think he's got the right archive with the 132/86 numbers. 
Pretty sure that my card should be close to or better than his in 
a test that would not be doing any CPU heavy operations.

Oldes, I've posted new timings here Fri 20:16 some messages above, 
getting 86 FPS without and 132 FPS with hw accleration using the 
zip archiv r3gl-proper.zip, have you noticed that? So, seems to be 
the correct version since there is a reasonable difference between 
those two version.

If you want just to try A110, go to REBOL3 GUI group here, there's 
a link to download a binary and dll .... we will have to wait for 
Carl to resurface and correct the release, or even better - to merge 
the changes to official location ...

wait a bit ... I'll try to redownload Carl's HostKit

It's a test location

Second, the temporary R3A110 repository is even more unsupported 
than usual. Unless you want to work on distribution and building 
of the hostkit itself, it's probably better to stay clear of this 
and  wait until things settle down a bit.

Third, Pekr, you are _still_ using the wrong URL for your remote. 
Either make a fresh clone with

  git clone git://github.com/carls/R3A110.git


or fix your remote manually (Probably via `git remote set-url origin 
git://github.com/carls/R3A110.git`.)

A quick note of success: just built an A110 hostkit on OSX Intel!

yes, another blac-out, which even SCRUM did not prevent us from .... 
nearly a month now, without a single message ...

I found out, that Genesi is now sponsoring Linaro Linux, which tries 
to unify distros for ARM target. They gave away 50 smartbooks:

http://bbrv.blogspot.com/2010/12/momentum-is-building.html
http://www.genesi-usa.com/products/smartbook


From past month's discussion with BBRV, I believe they are able to 
send us a machine to port R3. And now again - this is not my port-it-for-me 
request, just a note, to eventually start a discussion, how do we 
get ourselves on ARMs. Carl could have one smartbook to port Core, 
and someone willing to play with the HostKit port could have another 
one. In the case someone is interested, I could try to negotiate 
it with BBRV.


Of course - ARM is a broad term. I never heard of Linaro. We have 
some TI hardware, and I know there are some embedded systems for 
such stuff, mostly commercial and expensive, and Linaro might be 
an answer here. Another HW option is BeagleBoard (cheaper, more OSes 
supported, even QNX, Android):

http://beagleboard.org/

Porting R3 to an ARM netbook Linux would be a good start. The binary 
R3 library may then even work on Android

However, the Android cross-compiling SDK with its emulator is also 
a good development environment

Porting to a mainstream Linux ARM will hardly be any work at all.

Mostly a matter of either setting up a system to do the compile, 
or setting up a cross-compilation toolchain.

Me too. ARM is not a PC architecture, so there may be differences 
in the device drivers