J and K doing GUI / Ferrari and Porsche displayed through windows 
Author Message
 J and K doing GUI / Ferrari and Porsche displayed through windows

Quote:

> As several have pointed out, my formulas were wrong (that won't > surprise Roger):

>        w.F..d:"32+C*9%5"
>        w.F..t:"C:(5%9)*F-32"
>        w.C:0.

> w is a dictionary containing two variables, F and C.  F..t is the
> trigger attribute of F:  when F is assigned, F..t is evaluated in
> F's name-space (i.e., w).  F..d is the dependency attribute of F:
> when any variable used in F..d is assigned, F is invalidated.
> When reference is made to an invalid variable x, x is validated by
> evaluating x..d in the name-space of x.

This looks interesting !

I have never seen anything about K before.

How is the window defined in K ?

Most of the script I sent in on J was just defining the window

From my script:

e1=:":32+9*5%~".e0
e0=:":5*9%~_32+".e1

Are fairly similar to the above mentioned lines but they are a bit {*filter*}
without the definitons of the triggering operations and definition
of the window.

--

http://www.*-*-*.com/ ~gosi
http://www.*-*-*.com/



Wed, 16 Sep 1998 03:00:00 GMT  
 J and K doing GUI / Ferrari and Porsche displayed through windows

Quote:


>How is the window defined in K ?

Any K variable x (including dictionaries, which are variables
whose parts are variables) can be displayed using the function
`show$; e.g.,

                v:10 20 30
                `show $ `v

When v changes, the display of v is updated; when the display
of v is edited, v changes.  This logic connects each variable
in an application to its display.

If v has a trigger, then that code is executed whenever v is
assigned, either directly or by typing into its display.  If v
is a dependency on x, y, z, ..., then whenever x or y or z or ...
changes, v becomes invalid.  Validation involves setting the
value of the variable to the result of executing its dependency
definition.  These two bits of logic connect the variables in
an application to one another.

These ideas are implemented in the K interpreter, but they can
be modelled and explored in any array language containing facilities
for drawing on the screen and taking events.  

Quote:

>Most of the script I sent in on J was just defining the window

Yes.  Well, I'm suggesting that GUI should be thought of as an
extension to quad.  I mean, for years all you had to do to display
a variable in APL was <quad> <assign> v.  APL took care of formatting
things for you.  APL knew how to format a matrix, so you didn't have
to.

sa



Wed, 16 Sep 1998 03:00:00 GMT  
 J and K doing GUI / Ferrari and Porsche displayed through windows

Quote:

> Any K variable x (including dictionaries, which are variables
> whose parts are variables) can be displayed using the function
> `show$; e.g.,

>                 v:10 20 30
>                 `show $ `v

> When v changes, the display of v is updated; when the display
> of v is edited, v changes.  This logic connects each variable
> in an application to its display.

> If v has a trigger, then that code is executed whenever v is
> assigned, either directly or by typing into its display.  If v
> is a dependency on x, y, z, ..., then whenever x or y or z or ...
> changes, v becomes invalid.  Validation involves setting the
> value of the variable to the result of executing its dependency
> definition.  These two bits of logic connect the variables in
> an application to one another.

> These ideas are implemented in the K interpreter, but they can
> be modelled and explored in any array language containing facilities
> for drawing on the screen and taking events.

> >Most of the script I sent in on J was just defining the window

> Yes.  Well, I'm suggesting that GUI should be thought of as an
> extension to quad.  I mean, for years all you had to do to display
> a variable in APL was <quad> <assign> v.  APL took care of formatting
> things for you.  APL knew how to format a matrix, so you didn't have
> to.

> sa

This looks good and interesting but I am missing something.

How do you define the window ?

Where are the contents of the nouns (variables) placed in the
window ?

I assume K does allow you to create windows and place out static
text as well as creating places where nouns are displayed.

I like the idea of a triggering between a change in a noun and
its display in a form.

So when defining a form it would be a nice feature to be able to
define a connection to items in a locale. It need not be a noun.
It could be a verb. Either showing changes in the display of a verb
or displaying its results. Even in a debugging sence it would be
interesting to be able to see intermediate results like stepping
through a verb.

In J3 the new debugging features would be nice in a form connected
to the displayable items. They can be quite complex to analyse if
you are working with verbs calling verbs calling verbs... with lots
of localised nouns.

Obviously having this as a part of the J engine would be good but I
think we can easily create utilities in J to do these things and
try out these ideas before putting them out as wishes to J itself.

--

http://www2.simi.is/~gosi
http://www.jsoftware.com



Sat, 19 Sep 1998 03:00:00 GMT  
 J and K doing GUI / Ferrari and Porsche displayed through windows

Quote:


>> Any K variable x (including dictionaries, which are variables
>> whose parts are variables) can be displayed using the function
>> `show$; e.g.,

>>                 v:10 20 30
>>                 `show $ `v

>> When v changes, the display of v is updated; when the display
>> of v is edited, v changes.  This logic connects each variable
>> in an application to its display.

>> If v has a trigger, then that code is executed whenever v is
>> assigned, either directly or by typing into its display.  If v
>> is a dependency on x, y, z, ..., then whenever x or y or z or ...
>> changes, v becomes invalid.  Validation involves setting the
>> value of the variable to the result of executing its dependency
>> definition.  These two bits of logic connect the variables in
>> an application to one another.

>> These ideas are implemented in the K interpreter, but they can
>> be modelled and explored in any array language containing facilities
>> for drawing on the screen and taking events.

>> >Most of the script I sent in on J was just defining the window

>> Yes.  Well, I'm suggesting that GUI should be thought of as an
>> extension to quad.  I mean, for years all you had to do to display
>> a variable in APL was <quad> <assign> v.  APL took care of formatting
>> things for you.  APL knew how to format a matrix, so you didn't have
>> to.

>> sa

>This looks good and interesting but I am missing something.

>How do you define the window ?

I don't.  I just define the variable and display it.  The only handle
on the window is the variable name.

Quote:

>Where are the contents of the nouns (variables) placed in the
>window ?

The derived function `show$ recursively places the contents of
the variable shown onto the screen.  For example, if w is a
dictionary containing vector a and dictionary b, and b contains
atom c and button d, then `show$`w displays w as a form containing
list a and form b, where b contains entry field c and button d.
(These are the defaults in K.)  The structure of a display is
determined by the structure of the variable.  Data at the leaves
("content") is mapped to particular display-forms, determined
by characteristics of the data, such as type and depth.

Quote:

>I assume K does allow you to create windows and place out static
>text as well as creating places where nouns are displayed.

Yes.

Quote:

>I like the idea of a triggering between a change in a noun and
>its display in a form.

In K, triggers and dependencies connect variables one to another.
The update connections between a variable and its display are
implicit:  show a variable, and the interpreter will always keep
it and its display in sync.

- Show quoted text -

Quote:

>So when defining a form it would be a nice feature to be able to
>define a connection to items in a locale. It need not be a noun.
>It could be a verb. Either showing changes in the display of a verb
>or displaying its results. Even in a debugging sence it would be
>interesting to be able to see intermediate results like stepping
>through a verb.

>In J3 the new debugging features would be nice in a form connected
>to the displayable items. They can be quite complex to analyse if
>you are working with verbs calling verbs calling verbs... with lots
>of localised nouns.

>Obviously having this as a part of the J engine would be good but I
>think we can easily create utilities in J to do these things and
>try out these ideas before putting them out as wishes to J itself.

>--

>http://www2.simi.is/~gosi
>http://www.jsoftware.com



Sat, 19 Sep 1998 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. JS-EAI with *JS*-callback

2. js.exception 3279.js

3. Vrml to Window.open (JS)

4. Script error: c:\windows\repair\rollback.js ??

5. Display RGB pixel data in a display window

6. Win a Porsche 911

7. ferrari signs, logos, emblems wanted !!!

8. Displaying Uincode characters in a VW GUI

9. How To Display GUI in Linux shell ?

10. GUI suggestions to display FAXes please

11. Question to the Tk/whatever GUI gurus: displaying trees

12. ** APS (GUI) opportunity ** APS (GUI) ** APS (GUI) Experience required

 

 
Powered by phpBB® Forum Software