AltME groups: search

I should update it soon. There have been quite a few changes since 
that version...

Guys - what is the reason of kind of slow R3 GUI progress? At least 
from external observer point of view? That is not complaint nor is 
it any kind of attack. It is just that I thought that you need R3 
GUI for a commercial project? And from external pov we could see:

- new resizing system
- some new higher-level systems (validation, tabbing/focusing)
- some news about low level tweaks
- Cyphre posting REP about new possible rich-text system
- some endless work on styles


However - from external point of view, and unless it all plugs together, 
Carl's original VID felt more concrete, more complete. Is there any 
estimate when stuff will plug together to form usable system? Simply 
put - maybe if system would be docced, ppl could start working on 
additional styles? Or is it still too early, and non-yet-finished 
subystems could break any such code?

Pekr, if you think Carl's version is more complete, then you can 
use it...AFAIK Carls version is simply incompatible with current 
R3 and doesn't work ;)

We are fighting on all fronts to get our stuff in better shape everyday. 
I must also note we are working on other things that needs to be 
done. The system is in final phase of stabilizing its internal parts. 
We are now focusing on a good way how to do automatic testing before 
we start doing more styles...

As always, you can wait for our stuff or be active on your own, use 
what we gave to the comunity and make everything better, faster, 
longer, stronger and quicker!

My whole point was, that Carl took some rewrite route back then, 
and in 2-3 months timeframe produced kind of basic, but working GUI, 
which could be demoed by 'demo function of R3, while with R3 GUI, 
we are not there yet. I don't need to be pointed out to such facts, 
that 2 years old GUI apparently does not work with latest R3 builds 
:-)


Also - "you can wait ... or be active on your own ..." is not an 
argument for me. Noone apart from maybe 1-2 guys here want to work 
on yet-another GUI project. The whole thing is about me (and maybe 
others) not seeing a "big picture" - things plugging-in together 
into useable form timeframe. I know that giving any terms is very 
tricky, but my point was not to get exact nor even estimated date 
- just some rough ideas about what's still left to be done ....

I'll post a small list...

I noticed visual representation for the focused button. Just curious 
- how is that done? Is that a part of a margin/border of the style? 
Simply - is it drawn inside the style, or outside of it?

Rebolek implemented it, so he knows that, although I suggested using 
a GOB.

Anyway: Just start using the GUI now. The style browser is built, 
I have a build system test GUI also and both work fine, so what we 
need is input on things that are silly or missing in the GUI now.

henrik,  it seem's that style doc have a problem  => ** Script error: 
text does not allow command! for its text argument

** Where: show foreach unless show-now view catch either either -apply- 
do
** Near: show f

re focus - It's not definite implementation, it's test of whether 
it's better idea to have some universal highlight mechanism or to 
implement highlighting on style level. I'm still not sure which approach 
is better, having system-wide mechanism is a good thing, but doing 
this on style level allows better implementation.

Pekr, what is the reason you don't help either by:

* wring tests for Parse
* writing test for Mold

* writing tests for CureCode tickets that don't have tests in the 
core-tests suite yet
* writing some GUI styles

* responding to user polls, letting us know what your preferences 
are

* reading the documentation and/or new proposals pointing out at 
the problems you are having with them
* doing other useful work to help R3?


That is not complaint nor is it any kind of attack. It is just that 
I thought you needed R3? And, from my point of view there is no obstacle 
you could not do any of the above? However, you have still a lot 
of stuff you can pick and help to make R3 better. Do you still not 
feel like wanting to do something? Simply put, there is enough oportunities 
for you to pick from, and the quantity is getting bigger over time. 
Or, is it still too early, and any effort from you can be expected 
only when none will be needed?

My take on focusing: I think ultimately only each individual style 
can know how best to represent its focus. Obviously consistency among 
the styles is a desirable quality, and to encourage that, the system 
should provide some functionality which each style can opt to use, 
to derive its focus functionality from, or not to use at all. That 
choice depends on the style, obviously.

I don't think it's a good idea to be too rigid and require all styles 
to use a single focus rendering functionality. That's just being 
short-sighted, presuming to know how all possible styles will be 
written, and will cause problems.

I would probably agree, if I didn't have other experience with the 
VID Extension Kit. The trick is to make the focusing mechanism flexible 
enough to handle all situations. We are not building a GUI that handles 
specialized situations. We are building a GUI for large business 
applications with dozens of windows, hundreds of widgets and tons 
of forms. We absolutely do not want to have something like focusing 
being a special case per style as other than a special option.

I don't mind an on-focus handling, but there should really be a standard 
method.

I don't think we will have that many irregular styles. Besides, each 
style will have a click mask, which could be used for drawing up 
an irregular focus ring. The only problem is to draw the focus ring 
inherently as a part of the face, and not as a layer on top of all 
faces, otherwise there would be problems with partially or fully 
covered faces in, say, scroll-panels.


Also, having differently appearing focus rings per style will be 
confusing to end-users, if the style designer can decide his own 
look for focusing.

The patterns will be repeating for a good size of already existing 
styles, such as fields, buttons, so I don't agree with the current 
approach. It will also take longer to create the skin, when we get 
to that point.

We don't have some good model for this right now.

 - We have the VID Extension Kit. It's been doing focusing centrally 
 for two years now and it works quite well, sans some well-defined 
 problems, which we have a good chance of fixing for R3.

Ok, that will do. We just don't want to end up in a situation where 
a central mechanism for rendering the focus ring becomes impossible 
to do. we will have a similar situation with help bubbles. Perhaps 
it's best to have a general mechanism for generating a gob near any 
face. We can use that in the help system as well.

Then, at least initially, is it very difficult to render a gob with 
a colored 1-2 pixel edge and simply have it rendered with the same 
dimensions as the focal-face? Later, a more sophisticated drawing 
mechanism could be used.

if you do that, you're 80% done. that leaves a few problems to solve, 
but that can be done down the road.

To have event transparent gobs is on my wish list for a very long 
time already.

Are there any GUI tests available that will demonstrate all the various 
GUI features available in R3?


I'd like to know how complete my GUI port is for Amiga so I was hoping 
there was some benchmark to work towards. I imagine all the platforms 
will need such a test in the future to guarantee a certain level 
of basic functionality across all platforms.

the style-browser I have is a bit old, but it should work. There's 
a link earlier in the group.

It may be good idea to build new one. Keyboard navigation improved 
a lot and can be good for testing key events.

ssolie, if you instead of running the style browser try:

view [button]

Do you get a window with a button?

to the focus discussion. I don't know why, but I agree with Rebolek 
this time :-) I know that I am fan of concepts, and subsystems. IIRC 
VID2 used something like abstracted feel storage. Maybe it was initially 
a good idea, but how often were 'feel objects actually reused? This 
was imo an example of a concept, which did not live to its expectations.


I know that R3 GUI is abstracted in better way. But I also feel, 
that we more clearly kind of encapsulated styles - they have all 
those on-* actors, which let the style to react to various events 
in its own way.

So - stating above - are we really sure that:


1) having abstracted all-styles-related visual representation of 
focusing brings us an advantage? One advantage might be, that if 
it is not central, lazy style coder might not implement visual focus 
representation, and then half of styles might miss it, or we might 
face some weird situations, when the style author implements the 
visual focus representation a different visual way.


2) are we sure that one central system will work for e.g. for some 
complex styles, where some special tricks might be needed to display 
focus visual representation correctly?

I would try to build A110, but I am not able to get sources from 
Carl's git. I tried to download his .zip archive, changed to TO_WIN32 
in the .h config file, but it does not build - probably a linux distro 
...

Whenever you are creating a concept in a GUI, such as keyboard navigation 
and focusing, you immediately want to centralize it with the option 
of per-style overrides. This is the illusion of control in that you 
want to meddle, when in fact, you are moving toward a lack of control 
a lack of unification and opening up all sorts of opportunities for 
bugs.


It is *much harder* to develop large applications, when concepts 
are not centralized, in the same way if you don't have a single mechanism 
for help bubbles, for determining which button is default, have a 
single, unified resizing system (hello, RebGUI), have a standard 
method for exiting windows, have a standard method for creating and 
displaying any number of dialogs (hello, VID), have a standard method 
for validating forms, have a standard method for reading and writing 
face properties (hello again, RebGUI).


With all these things properly in place, GUI development is reduced 
from weeks to hours.


Of course the other method of thinking may prevail, if you have never 
coded a large GUI before, and therefore don't consider the testing 
process, which can take *weeks* and *costs money*, because you have 
to test every single implementation (N number of implementations) 
of the concept that would otherwise be done in a central system (1 
implementation). It's really the testing that constantly is underestimated.


One can only determine that something cannot be centralized if it 
will create too much code, compared to a per-style solution, but 
it will in general always cause the GUI developer to create functioning 
and *bug free* layouts with much less work.


In that same thinking, R2 View centralizes the generation of a face 
image gradient, background, text display and edge appearance. It's 
not flexible, but it makes it darned simple to skin and generally 
does not have bugs.


And you FEEL object question: Yes, they are reused a lot, otherwise 
VID would probably be 100 kb bigger.

Pekr, and all I'm saying is that the irreguarly shaped styles drawing 
can be solved with access to the face click mask, that either is 
or hopefully will be implemented by Cyphre. Therefore I find it pointless 
to work on a per-style solution.

that's all

 - and then you have to change it per new style and every time you 
 change a box rounding, etc.

and for cases where you use a highly irregular bitmap, you will have 
to use some kind of mask anyway.

does it currently fallback to a simple frame, if no highlight option 
is available?

does it currently fallback to a simple frame

 - It should, but border seems problematic somehow. I'm working on 
 the gob mask, you were talking about, it's just not finished yet.

Simple frame: OK.

Catching focus, yes, we agree.


Visual: I still think the visual representation could be done automatically. 
The ancient Deluxe Paint III on my old Amiga could do the same with 
brushes, in that it would draw a single-pixel wide line around the 
bitmap. Do that a few times with fading colors and you have the look. 
If they could do that 20 years ago on a simple 68k machine, we surely 
can do the same today in REBOL3, if we have the clickmask and perform 
a simple blur on it.

a small glitch with style browser - I do mouse over of preview tab, 
it crashes. In console I do unview none, but consecutive start of 
style browser fails. Ditto when I try to re-do r3-gui.r3

This is what I get for mouse-over upon the preview tab - it displays 
the preview and crashes with:

** Script error: tooltip: needs a value

** Where: either if function! all do-style either if either do-event 
do-event ei

ther -apply- wake-up loop -apply- wait do-events catch either either 
-apply- do
** Near: either arg [
    buttons: compound-face? face
    tab-box: c...

Pekr, if you've got some time to help, please, have a look at keyboard 
nav and post any problem you find to me personally to not polute 
this channel. This will help very much.

Dunno if it would be good concept (it might be confusing for user), 
but some time ago I was thinking about nested tab system. What I 
mean is - most of tabbing systems do work in a flat way. It is kind 
of primitive. But - sometimes you might want to use the same navigational 
keys for more complex styles, typically subpanels, grids.


What we recently got (and can be seen with e.g. style browser) is, 
that e.g. tab panel can be tabbed. Then arrow keys do switch between 
tabs. What I had in mind was to be able to press enter, to nest the 
tabbing, so that you "enter" the subpanel, and esc to escape back 
to the upper level (this part might be tricky for users, not sure 
about it - they might feel being locked inside of some style).

Any ideas?

btw - will there be added visual representation to field tabbing 
too? It feels a bit inconsistent the way it is ....

Cyphre: I'm willing to give it a try.. it is becoming some kind of 
patched up monster so I hope Carl passes over the official A110 soon 
;-)

We should make this a FAQ

You'll need a "/View" build of A110, such as:
http://94.145.78.91/files/r3/gui/r3.exe
http://94.145.78.91/files/r3/gui/r3lib.dll

ok, mine shows a window when using View, so I suppose it's the View 
version.

Henrik: I have style-browser.r3 running on Amiga now. It tends to 
stop running a lot with script errors... how complete is this app?

Doc can add it as a new project I guess.

Pekr, does it work with the spacebar? There could be a collision 
when using Enter, because it may be used to confirm the default button, 
which may not be the same one as the one in focus. That depends on 
keyboard shortcut layout, though.

The same goes for default Windows dialogs, and it is imo good behaviour. 
Simply put -enter stays as a default action for the form's default 
hilighted button, unless another button is tabbed. It unifies enter 
| space-bar behaviour for button types. If we stay with current behaviour, 
users might be confused, as enter will fire action on different button 
than the tabbed one. Of course it depends, and I would like to know, 
what is the functionality on non-Windows platform?

If you are able to move the default button using tab focusing, then 
IMHO, default no longer makes sense, because it overlaps tabbing. 
This is one thing that OSX does quite well and the idea is taken 
from there.


The alternative is to get rid of the default action and simply place 
the focus where default would be, but that means potentially lots 
of tabbing, if you need to activate a specific field.

Activating a specific field would also occur in validation, when 
focusing an invalid field, so it would disrupt default functionality, 
if they are one and the same.

I aven thought about possibility to link to native widgets, but just 
to mimick skin parameters. I am not sure it is possible, but when 
you e.g. create skin, which looks like OS native one, then users 
will be confused, if you set OS native feel differently. Under windows, 
there's not much of possibilities, except for some Windows bar size/decoration, 
or font size. But under AmigaOS and e.g. MUI, you can change the 
look of widgets quite a lot. The question is, if someone would be 
willing to simulate such a complex system as MUI is, and define all 
the skins. The app would also have to be notified, that user changed 
central setting, to readjust ...

if we do that, there might be a need to define a behavioral model 
as part of the skin, but I'm not sure how much it encompasses. There 
are some little details that I expect to work in a specific way in 
OSX, which don't work in Windows, and vice versa. This means that 
styles may not implement these behaviors directly, but that is probably 
difficult to avoid.

I think we should categorize typical differences, such as:


- whether certain buttons are activated on mouse-down or mouse-up.

- whether a button action is activated when dragging out of a button 
and releasing.
- whether default follows tab focus.
- etc.


Then these could possibly be implemented in styles and abstracted 
away from the style as a behavioral profile for a specific OS.

Mozilla apps are not a good place to observe native system behaviour, 
because they use their own toolkit

Small status:


The Internet these days seems to be composed of a series of disk 
crashes (instead of tubes). Both Robert and Rebolek are suffering, 
which slows down communications, so no updates lately.

as we get a better arrangement on how to do that properly, yes. I 
think we can do this by pushing nightly from the server.

nice! that's the way. just made a similar setup with SSD/PCI-SSD 
and a spacious raid 5 for the data storage.
for ultimate speed I can recommend PCI-SSD Instead SATA SSD.

We have a big project that needs Android TabletPC and Phones to run 
on.

How difficult would it be to have a an R3 GUI for these touch based 
devices ?

At this point it would be easier to use R3 as a preprocessor to generate 
apps that are implemented in Java than it would be to use R3 directly.

Ok, I have understood we should talk about REBOL on Android in a 
couple of years from now.

But to break it down, assuming you want R3-only apps, we would need
- A native C compiler for the platform

- A rewritten host for the Android application model to support native-only 
GUI apps (are those possible?)
- An AGG port to the hardware/os
- Some tweaks to the event model to support touch and multi-touch
- Some tweaks to the R3 GUI that deal with the new form factor
- A new set of styles that are designed for touch

At this point, the only plans I have heard people making for Android 
were to make an R3 host that would act as a plugin for the Android 
native API model, so that R3 would be a native library to supplement 
apps that are primarily written in Java. No talk of AGG yet in those 
plugins though.

Of course that would depend on what native plugins are allowed to 
do on Android. I haven't even heard of a fully native GUI app for 
Android (they might exist but I haven't heard of it), only CLI apps.

and they dare to call it a platform? Without a free GUI?

They do have a free GUI. It's just that it's written in Java.

We are planning an Order Entry application which needs a tablet/mobile 
phone and a Server counterpart.

The R3 GUI will eventually need multitouch support and support for 
modern touch-screen devices (meaning: not treating touch like a mouse). 
That support would be portable to a variety of devices, some of which 
would be running OSes that the R3 GUI already runs on.

Whether you reimplement in Java or port the host kit, you would need 
the same mapping from the Java semantic model to the REBOL semantic 
model; they have little in common. That will probably be the hardest 
part to get right, especially if we do a native r3lib port and just 
rewrite the host.

Brian, this cuts the wings of a REBOL based order entry for mobile 
devices.

Later in development it is planned to use static touch screen based 
PC. This could be done in REBOL but the other part needs to be programmend 
in a solid, tested and rich enviromnent.

Maybe release 3.0 of the order entry project will be in our beloved 
language.

It looks like you might be able to use a combination of the standard 
NDK and a third-party cross-compiler to make fully native GUI apps. 
You would get the libraries from the NDK, including SGL (that's Skia 
Graphics Library, not SDL, it owns the framebuffer). I haven't seen 
anyone try to do this yet but since it may be possible then it might 
have been done already by someone.

I'd guess that if R3 was a viable way to develop for Android, we'd 
see a higher uptake of the language than from any of the other (non 
mobile) platforms.

there's a gold rush in mobile app development (still) happening

I had quick glance at the Android examples....it seems my guessing 
was not too off. Also it looks like the android developement is very 
simmilar to the J2ME stuff  in the basic sense so I might give it 
a try in their emulator to see what is possible ;)

You need to get a GUI build and download Henrik's compiled R3 GUI 
code. Look above here for the links.

I also see as a priority to fix the status of gui :

- declare publicly if r3-gui is the official gui development or not
- then fix the load-gui call function
- and finally update the gui official documentation page.

It should not be too difficult, and, to my opinion, it it really 
important and urgent, because it prevents to develop experimental 
visual applications.

Could the gui development team meet Carl in order to convince him 
to take a decision ?

Carl is currently only observing, but I've not seen any comments 
from him on GUI development. But at this time, the number of RM Asset 
programs and tools that requires the R3 GUI is growing, so we are 
not in a position where we can hand things over to Carl and expect 
him to evaluate, rewrite and finish it.

Kaj: months= month's - a typo, and maybe even then incorrect wording 
...

Henrik - public channels are all dead though. Twitter, blogs, and 
even R3 Chat last login is 15 Nov. Hopefully Carl is taking a break 
to refresh, and to do some beta decisions ....

And I agree, it is a one way ticket. Carl was way too long away from 
the GUI topic. RMA surely is going to use its own gui for its own 
apps. And the official R3 GUI? Who knows, but I bet ppl will prefer 
RMA's work, than having nothing in the end ....

I wouldn't say that about VID. VID is simply incomplete. A completed 
VID would not be much more complex.

That doesn't make sense... The VID Extension Kit won't entirely prove 
simplicity, because it needs to work around a buggy View, but when 
building all the necessary subsystems, the principle of VID is sound 
for highly scalable apps.

Since there are so many questions, here is a group for those who 
want help with R3's new module/script system. If you need help with 
LOAD, SAVE, IMPORT, DO-NEEDS, Needs header syntax, the new binding 
conventions or the new semantic model of scripts and modules in R3, 
ask here!

Or write them, for that matter. I lost track of where the docs were 
in the various wiki reorganizations. Right now the definitive docs 
on the subtleties of the module system (beyond the official docs 
Carl wrote) are still in the CureCode tickets related to them, and 
their comments. I'll try to track down a list of the relevant tickets 
and post them here.

Everything specified, as of alpha 97, even the 'export keyword Carl 
requested. Compressed scripts/modules have been submitted and are 
being reviewed now.

What doesn't work:

- Selective import is possible but needs mezzanine wrappers (and 
a model for their behavior).

- Delayed init is just a dream now; Carl hasn't even elaborated on 
what he means by that.

- System modules might need a little tweaking to the model (by Carl).

- We need better checking of extensions before loading (authenticode?).

- A module-aware version of prebol is still needed (it's on my list).

Extensions contain a regular or isolated module in them that acts 
as the wrapper for them, so once loaded they are treated like any 
other module, seamlessly. Not sure if that embedded module could 
be compressed using the standard code - I doubt it because of the 
wrapping process.

Even script-in-a-block works :)

These docs don't yet include the real subtleties of when to use IMPORT, 
when to use DO and when to use Needs. In particular, they don't say 
when *not* to use IMPORT directly and why, what the difference is 
between named and unnamed modules, or any kind of hints about overall 
program structure. This is partly because the docs were written (by 
Carl) before the module system was finished (by me) so that info 
simply wasn't known at the time, and partly because I could use some 
help with writing docs about those issues that don't read like a 
CS paper.

Brian - could you describe the phases we run thru? I mean - first 
you "include" a module, extension, it (maybe) gets into module list 
(catalogue), but still not loaded ... and now - what happens next? 
Is there anything like loading a module, but still not binding it 
for e.g.? And if so, what advantage does such phase have? Maybe it 
would be handy to have a process diagram of how modules work ...

Mixins have such a use case for delaying that I almost want to make 
that the default behavior.

The discussion in bug#1625 is turning into a fairly deep explanation 
of the R3 script and module bbinding models, the meaning of FUNCT 
and why we have it, and the inherent limits of REBOL that were why 
we did things the way they are now. Take a look, it could be an eye-opener 
to anyone interested in this group.

Holy gotcha's Batman! Take a look at bug#1628 and make your comments, 
we need to decide this soon!

BrianH: I am not sure I like Carl's comment re 'what showing the 
non-exported functions too. It is not about 'what for me, but why 
should non-exported functions be available? In following Carl's example, 
I see the only advantage of exported vs non-exported function being 
a binding control, but I thought we get encapsulation too. Was is 
intended that way? For me there is very little advantage in calling 
'init-subsystem vs m/init-subsystem ....

m: import 'my-graphics
m/init-subsystem
m/set-resolution 1600x1200
draw drawing

except that "init-subsystem" requires no lookup (fast) while "m/init-subsystem" 
requires a lookup (slow)

Gab, you did prot -http as a module.  Should all protocols be modules?

Pekr, I answered your question in the blog. But in short, exporting 
is about exporting, not about hiding what isn't exported. Exporting 
means adding a word to the (closest thing that R3 has to a) "global" 
context. Otherwise, the word is just available in its local context. 
Modules are there for code organization, not encapsulation. Encapsulation 
is a separate process, and only rarely needed.

Nonetheless, we will be making it easier on a module basis by supporting 
a 'hidden keyword, similar to the 'export keyword.

We don't want to overload the word 'show because there are SHOW functions 
in common use that get exported from modules, and these keywords 
get *removed* from the source during their processing. Also, exposed 
by default was a deliberate design choice.

There are 3 levels of visibility:

- Exported to system/exports, or directly into the requesting context 
if the module is a mixin. Note that it is the value that is exported, 
not the word.

- Visible (or exposed, or shown, if you prefer), but not exported 
(the default)

- Hidden, meaning it can't be bound beyond code that has been bound 
to it already, usually just the module.


There is no point to an 'expose or 'show keyword, because words are 
exposed/shown by default. Hiding words is generally only done for 
security.

From the loading modules doc: "...if a version number appears before 
any module name, it is assumed to be the REBOL system version.

  Needs: [3.0.2 mysql 2.3.0 http-server 1.0.1]

 Is there an explicit alternative? And how would you specify that 
 you need View or Command rather than Core?

And for checksums, would 
 it make sense to allow a keyword before the checksum, so you could 
 choose md5, sha1, or something else in the future? An unmarked binary 
 could still be sha1. I know it maps to the /check refinement on IMPORT 
 as well. I'm just thinking of implicit meaning versus long lifecycles.

Hidden words can't be exported, because the export process has to 
see the words to export their values. This means that the 'export 
and 'hidden keywords will conflict. I can resolve that conflict by 
having one take precedence over the other, but that just seems like 
a hidden gotcha. It seems to me that triggering an error if both 
keywords try to modify a word would be the best approach. What do 
you think?

I tried that, as a 'core key as well, but it was too difficult to 
resolve potential conflicts with some module of that name. There 
is a complexity budget for the import process.