AltME groups: search

Gabriele is guru of modal system ... hey Gab, what's happening here? 
Can I twist even so short code or is that a bug? :-)

looks like a bug to me. try to make the example smaller first.

good observation. when i add a 'print in the quit-button, it shows 
that action is never called. so no quit too.

When a field is dirty? and you click on another button the action 
of the field is done. This is a side effect of system/view/screen-face/feel/event-funcs/1

A lot ot other companies have. Support for Adobe Reader left off 
at 5.0.5, Java at 1.3.1_11, etc. Even 98 is losing support, although 
98se still seems to be there for now.

lay1: layout [f: field [
		probe "Dirty!"
		;view lay2
	] btn "Quit" [probe "Bye?"]]
lay2: layout [text "just a try" btn "Return" [view lay1 focus f]]
view lay1

enable the 'view and the quit-button is not called. Not sure if thats 
buggy enough to be a bug thought.

shouldn't the 'run function be part of /view.  Looks like it requires 
a license to be used.

Gabriele: I don't understand what Romano says. As a average scripter, 
I really don't care about some dirty fields or other dependencies. 
From code provided, it is clearly a bug, so - fix it.

Gabriele - just looked at your fix - I can't consider it being a 
fix. It is like suggesting HTML coder to change something in DOM 
level.

in this case, move lay2 a bit ;) it gets not re-rendered, its a new 
window. lay2 now points to second lay2. you close that. you see the 
first window (but looks the same.. you unview lay2, but thats now 
the second, closed lay2, not the first you are really viewing.

Pekr>Try to press "Return" button on lay2 - it does not work anymore 
...


It still works back in View 1.2.47... (I'm sticking with this version 
for a short time longer.. )

as Cyphre suggested to me privately - first instance of lay2 looses 
reference to the window, as it is regenerated during second button 
press. But that "face" remember its parent face. Try to replace unview/only 
lay2 with unview/only face/parent-face .... the question is, if that 
is a bug or not - should we be able to create such wrong code using 
VID?

I am starting to think, that it can't be considered a rebol bug, 
but a programmer bug. In such case though, ppl have have knowledge 
about windowing system, how it is organised in pane, etc., so View 
internals - knowing just VID will not be enough ...

I guess you produce something like that by switching layout. usually 
both is called, the text-action because of dirty, then the button-action. 
but somehow view forgets to call the button when you switch layout 
and call focus. maybe because the layout with the button is not visible 
after the text-action? its a bug for me, but i guess it could be 
tricky to fix, lots of special case-code.

petr: it's not a trick. dirty? is there by "design", and it is handled 
by a event func. you need to handle it manually in cases like that. 
so, not a bug, just lack of proper documentation.

How do you make a shadow effect for a face, like Cyphre does in its 
menu style ?

So ignoring the button press in this special case is not a bug?

imo it is a bug, period :-)

Is your complaint then one of a lack of documentation?

So that we don't have this discussion again, why don't you draw up 
a critique of what you feel is bad design regarding 1.3, and then 
we can work from there?

It's hard for all of us to start from the same point unless all of 
us remember past discussions.  So, let's have a summary document.

Yes, maybe documentation. But I can still see a trouble with 'list 
and if 'field is similar, than our bad. VID is abstraction. It was 
meant to ignore errors in code if possible. It was meant to configure 
style using facets ... we started to expose more facets 'edge ,'font-size, 
etc., and if not sufficient, the last part is using 'with and directly 
accessing object values. But 'list goes even further, as 'supply 
block deal with variables like 'count ...

RT has a small habit of changing their minds.

Pekr, Docs are being worked on. VID update is also in the plan, SDK, 
other platforms etc There is a lot of work being done. Some of this 
is sequential some is in parallel.

Yes. But a lot of this was stated when the journey towards 1.3 started, 
http://www.rebol.net/article/0161.html

Perhaps it is time to consider a VID community documentation project 
?

The rebolfrance rebol dictionary is a good example of community documentation

But at least now, we as a community focus again on what needs to 
fixed in VID rather than native issues (and all the other bugs that 
got taken care of) This is a good thing.. If we are complaining about 
VID again, I think that is a sign that 1.3 has helped move us forward. 
And there is nothing in VID that can't be changed or replaced by 
something else as REBGui shows us.

Now that's the sign of a mature software project :)

it will be great if RT is ok to start a VID upgrade to show world 
how rebol is great and simple to use and progam.

it will be good for rebol and RT to have a link page on REBOL.COM 
to project like RebGui.

In the early days I wrote a few simple styles extensions as examples, 
and then doc brought his Win95 styles and then Ettiene came out with 
his style set. It really seemed like everyone understood how extensible 
it was.

Pekr: about dirty-flag: thats a cool trick for quick formulars. you 
put things in a layout with 
   field my-string [ my-string: face/text ]

and now you never have to worry aout saving face-content: when user 
changes field and leaves it (clicks outside), the action is called 
and 'my-string updated (or the database or whatever you do in the 
action). 

That storing happens only if /dirty? is set, else there is no change, 
so no store.

The problem with your code is, usually both happens, first field 
is stored, then the button. So field should be stored, then your 
quit-button called. You managed to write code which somehow forgets 
to call the quit-button. Somehow you confuse rebol by changing layout 
in field-action and focusing. That it gets confused is the problem/bug 
IMHO.

about list, thats a complicated issue IMHO, because list is heavily 
optimized to show very big lists with good performance and low memory 
use. Thats done by a trick (iterated faces). And that trick is hard 
to wrap in a generic way. 

The other option is to do it trickless, means put all in a big layout, 
one face for each row. thats like conference/messenger/altme do it. 
not that performant (all this programs restrict the number of messages, 
only the last n). but to do it, you only have to append vid-code 
like
 text (name) 100 text  (msg) 300 text (date) 100

for each line and layout that. most flexible way, you can even edit 
each field. but don't come back and tell me its hungry/slow! then 
you have to use that index count list - stuff, maybe somewhat better 
wrapped.

Pekr: It is a good time to start looking at the next VID, and see 
what else from the VID project can be used. You are in the best position 
to identify which of those pieces are finished or worth pursuing.

Whether this is a good design point of VID or not is a different 
issue. Personally, I used to disable this event func in my earlier 
apps; on later apps, i just change the field style to reset the dirty 
flag before calling the field's action.

Volker: using different methods to set style values is basically 
a wrong aproach imo, e.g. methods for automatic iteration and data 
collection are more difficult to do, as you have to inspect what 
style are you investigating, and what is the method to get the data.

btw - would it be good to have Desktop group here? I wonder if someone 
has some suggestions worth discussion first, instead of putting them 
directly into RAMBO as a wish? Cyphre just informed me, that he updated 
his old demos to be compatible with 1.3. Some of them worth inclusion 
in main Demo section imo ... Bouncing Demo, Cursors, Image Effect, 
Laser, Rotoobject  etc.

we need something like VID2, created from scratch (or almost), and 
strong enough to serve as a building base for applications.

it's not that VID is not good, it's that its purpose was not to be 
the ultimate gui framework, but more of an example of what you can 
do; indeed, now we have RebGUI too. but, the problem with that way 
of thinking, is that in practice developers need a solid base to 
start. so it's much better for everyone to provide it.

rather, i'd keep VID as is for compatibility and provide a brand 
new VID2.

Gabriele, thanks for clarification. You are not the only developer, 
who thinks so.IIRC during older 1.3 initiative, Romano expressed 
just the same. It is probably a little bit difficult to introduce 
some conceptual changes for current VID incarnation. But that should 
be stated oficially. There are several of you - gurus, who could 
outline in few paragraphs, what way should VID2 (or VID+) go. One 
of my friends suggested me looking into (was it?) Gnome UI guidelines, 
as an example of how complete definition of widgets, behavior, etc. 
of such framework should look like ...

There are several of you - gurus, who could outline in few paragraphs, 
what way should VID2 (or VID+) go

Actually, I think it would be easier to design and implement it than 
try to outline it in a few paragraphs. :-)

so... since talking is cheap, if you want i could talk about a lot 
of things. but, if you want to know what's going to happen, i can't 
tell you, since i don't know. maybe even Carl doesn't know: a lot 
of things were annunced but never materialized; it's much better 
to avoid annuncing something unless you know that you're going to 
deliver it :) (again, IMHO)

OK, understood now, thanks a lot .... but I can decide to save later 
on, e.g. when I leave screen, right?

accessors - i did not mean different methods as in "methods fr different 
faces". its different concepts. in old vid it works this way:

you put data in the face as in [filed "Hello" check on] etc. kind 
of set-accessor.

when data changes, you handle it in the action and pt it back in 
the db.

the action gets a parameter 'value, so instead of of field/text, 
check/data, text-list/picked/1 you can just use value. kind of get-accessor
  field record/name [ record/name: value ]
  field record/address [ record/address: value ]
  check record/iwantit [ record/iwantit: value ]
  button "send" [ send [me-:-here] mold record ]

and for a bit performance the field-action is not called on every 
key, but in the last moment. also more usefull if you want to convert 
it first to a number or such.

saving later - yes, the face keeps its value. you can as well get 
the value out of the face. only the action may be called sometimes 
in between and suddenly do something. in my example its just a store 
and each action overwrites the old value. if you change layout there 
or such it may led to surprises.

maybe we should have a way to disable that dirty-trigger on a per-face-basis?

.

vid2: Has somebody ever tried oberon/blackbox-builder? Thats the 
kind of layouting i like. They use text with "active-x-controls" 
inside (only better and simpler ;) . blackbox can do really windows-style 
guis that way. then while developing you can mark part of that gui 
and just copypaste it somewhere else. gives a lot easier control 
than typical gui-builders IMHO.

I noticed a change in image! type offsets in view 1.3 compared to 
e.g. the rwdraw57e.exe version. In rwdraw57e offset 1x0 was in the 
corner, now it's offset 0x0. Example:

>> bitmap: make image! 100x100
>> change/dup at bitmap 1x0 red 8x8
>> view layout [image bitmap]


That piece of code would put a red square in the corner of the bitmap 
in the rwdraw57e version of View. In View 1.3, the second line should 
be:

>> change/dup at bitmap 0x0 red 8x8


and I think, it's a good change. You could argue, that the offset 
should be 1x1 in the corner, like series are indexed from 1, and 
not zero. What do you think?

wouldn't the first method have a #000000 as the first hex value of 
the image?

I have posted this once while in the first REBOL world and up to 
now things are the same. The trouble is while I am posting this I 
notice the foreign characters under Linux are yet not supported by 
/View. I am using Debian Ubuntu with brazilian ABNT2 keyboard layout 
and I am not able to input some characters used in Portuguese such 
as ´a ´e ´i ´o `u `a ^o ~a .

I just cannot remember who at that time ( probably a french guy) 
mentioned a workround to trick /View but I think this is a bug that 
must be fixed

This is a View application .. and I see them

that´´s not what I mean. they are visible but the accents are misplaced. 
for instance in the word coraç~ao (heart in English) I should get 
the tild uppon the letter "a" and not before it. got it?

you wrote "a" with tilde  under Linux?

have u filed a Rambo report ?

Carl knows the problem ... well at least I had the chance to talk 
to him once trhu a feed back... and also there was a ticket in the 
past ... i remember... but then

allright guys I got a ticket:  RAMBO Ticket #-359 . Let´s see what 
happens. Thank you all

I'm probably going to write a game basedon it

Allen had mentioned using rate to handle forever loops in action 
blocks but my problem is that i have a while loop that executes a 
lengthy amount of functions before it even loops again.  I almost 
believe I need a multi-threading way of doing this.   I thought about 
it for awhile and think an enhancement would be nice where you can 
for example use launch function for executing additional threads 
but have a memory space for passing data between the threads.  Any 
of the REBOL gurus involved with RT know if something like this is 
capable?

dunno, probably not a bug, but at least a cache headache - imagine 
following scenario. Today I did small script for my friend. I created 
C:\app-name-here directory and put it inside, along with rebol/view. 
I then decided to install View, to get .r association, so that my 
small scripts could be put directly onto Window desktop (I don't 
need yet another desktop - View one, If I can't parametrise it further 
- buttons, removal of rebol.com etc.). So, after installation, I 
filled in network info, saved, and exited view. Then I could see, 
dirs like 'public, 'local 'desktop were created.  So I deleted them, 
to remove additional clutter they caused in my directory. To my surprise, 
View ignores the fact it is already installed, I choosed to not use 
desktop, yet I was brought to desktop once again.

desktop: none in user.r could work. would replace 'desktop-func with 
a nop. not tried.

;umm am I using Toggle wrong or is there a glitch in it?  This is 
View 1.3.1..


view layout [Tog1: toggle {First} Tog2: toggle {Second} btn {Pop} 
[Tog1/Data: Tog2/Data: false show [Tog1 Tog2]]]

Hi Gabriele, Is there a possibility of putting aliases put in place 
so View has that consistency across all the styles?  I think we also 
have /value and for a text face /text when I think it could always 
be /data

A puzzle this brings up; where is the 'value referred to by this 
function
>> layout [text-list with [print mold :update]]
func [/local item value][
    sld/redrag lc / max 1 length? data
    if item: find data picked/1 [
        sld/data: min 1 (index? item) / (max 1 lc)
        sn: max 0 to-integer sld/data * ((1 + length? data) - lc)
    ] [
        sld/value: 0.0    ; <----------- ?
        pane/offset: 0x0
    ]
    self
]
>> layout [scroller with [?? value]]
** Script Error: value has no value
** Where: ??
** Near: mold name: get name

sld is a scroller

that's most likely a bug. should be sld/data

i think /value is the remains of a very old scroller style :)

I'm too tired right now to do a more full analysis unfortunately.. 
but I'll submit at least.

yes, just a reminder about this problem. replacing that with data 
will fix it.

so looks like someone changed that code while being a bit distracted 
:)

oh my god ! I just fixed a bug of mine like that earlier today. :) 
It survived a couple of days before I noticed it.

View 1.3 bug!?:

>> img: to-image layout [slider with [data: 0.5]]
>> view layout [image img]


I see a black square at the top of the slider. Can others confirm 
this?

Confirmed. I think something similar (a problem rendering without 
diplsaying) came up recently.

I've made a quick list of the VID-styles found in REBOL/View 1.3. 
Some are explained with a definition, some by an image showing the 
style in use. The list can be found here:
http://home.tiscali.dk/john.niclasen/

Geomol, I think the problem is because the dragger is only correctly 
positioned in feel/redraw. See the feel:
	layout [slider with [?? feel]]

This means that the dragger is only set in the correct position when 
there is a redraw event, and the face must be viewed in order to 
receive events. The initial position ( layout [slider with [?? init]] 
) does not take into account that DATA may be non-zero.

I have a problem with the arrow style. It's default pointing up, 
but should be able to be rotated (according to the old REBOL/View 
Developer's Guide) like:

view layout [arrow effect [rotate 90]]


I can't get it to work in View 1.3 or View 1.2 for that matter. Is 
it a real old not found bug, or am I doing something wrong?

there is a bug somewhere ...

yes there was a bug

I'll probably add circular movement too - but IMO mouse really not 
suitable for circular movements (try to paint a circle with mouse...)

Pekr, there's a reason why up/down is the preferred way. It's weird 
to start with but it's better control in the long run. The hand is 
more precise in just one direction of mouse movement than two (or 
more, as you might like to see it).

Kru, nice demo ! :) Incidentally, this is just what I have been working 
hard on the last couple of days. Now I must post a demo :)

Anton I'm working on a french rebol software witch names is FaireBo 
it's a weather dashboard  based on METAR/TAF information so I need 
a kind of widget like  the ones you give in your demo to symbolise 
the wind direction  ;)

Is it really close to what you need ? If you can show me a picture 
of how the widget should look, I can see if rotate-knob can do it.

what I would like is a cardinal roze of the wind with a dynamical 
arrow that symbolise the wind direction according to the data comming 
from the weather station in the airports

or I make one image and I make a dynamic arrow using draw effects

in all cases your code is a good example  and a usefull working pass 
for me

My idea was to make a images that symbolise the cardinal direction 
(rose of the wind) and using draw effect over draw information like 
arrow or text :)

Kru and Anton. Both excellent demos! Should we add a folder on Viewtop 
for custom styles?

Yep, but :
- Not easy to set value by mouse (as said before).

- Effect (fill-pen) is not "mathematicaly" link to stick angle (don't 
find a formula), so hard to do for any value.

there is a tiny bug in your algo didec

some configuration range too instead of having a silder and a progress 
bar

It's not a bug but an intented behavior : it's a pair input style. 
There is for steps, each step can add any value to the pair. The 
repeat speed is also a parameter.
ie:

 stick-style speed 8 steps [1 2 5 10] ==> 8 is the repeat speed (rate) 
 and 1, 2, 5 and 10 are the values added to the pair!, depending how 
 you move the stick.


 stick-style value-mode decimal! ==> value is a block of 2 decimal! 
 values rather than a pair!

And feel/redraw is a nice place to detect changes to the face, eg. 
when face/data changes, you can update the visual state of the face.

You can also do face/action when face/data changes. However, I found 
that it is *not* a good place to use TO-IMAGE (which might be in 
the face/action), because the latest image of the face has not been 
rendered yet.  Redraw's 'draw action occurs just *before* the face 
is rendered. So to get a chance to make a snapshot of the face using 
TO-IMAGE, I propose a  new redraw action, 'view, be sent after the 
face has fully rendered, allowing TO-IMAGE to be used at the right 
time.

Here is a demo showing the problem:

view layout [
	pic: image
	b: box 100x100 sky with [data: 1] effect [draw []] feel [
		redraw: func [face action position][
			?? action
			if action = 'draw [
				insert clear face/effect/draw compose [
					fill-pen navy
					box 10x0 (as-pair 30 face/size/y * face/data * 0.01)
				]
				pic/image: to-image face
				;show pic ; causes a stack overflow
			]
		]
	]

 btn "change" [print "change" b/text: form b/data: random 100 show 
 b show pic]
]