AltME groups: search

This project deserves a seperate group.

Yeah, we were starting to clutter up the View group a bit.

It could be a good idea to insert here all the futur widgets we want 
to see in REBGUI ;)

A terminology question. If you were trying to explain basic View 
concepts to someone who wasn't familiar with View, what words would 
you use:

	Window or dialog?
	Face or graphical object?
	Facet, attribute, property or descriptor?
	Style, widget or template?

Louis: because of the clean seperation between display engine and 
widgets, it's ready now. What's missing is a good widget set to make 
it *usefull*. ;)

Ashley that depends on the level of knowledge the interlocutor has 
in computing if it's a totally newbie I would take easy  images (button, 
lable, fields, images etc..) If he is more skilled i would use Widgets 
beacause widgets can have différents styles styles the common VID 
denomination is related in fact on customized face so the equivalent 
in vid for widgets is faces

Louis I think that depends on how many people work on widgets set 
and what capabilities and imaginativ they are  :) (Cyphre style with 
AGG are trully a good research way )

We can't make  layout transparent but we can make inside window transparenc 
level maybe this coud be a good thing to dig on

Definitions of widget on the Web:


    A standardized on-screen representation of a control that may be 
    manipulated by the user. Scroll bars, buttons, and text boxes are 
    all examples of widgets.
    www.redhat.com/docs/glossary/


    A set of clickable, graphical element in a user interface. This includes 
    buttons, radios, checkboxes, and scroll bars. Widgets vary in appearance 
    and dimension from platform to platform.
    www.gerbilbox.com/newzilla/glossary.php


    n. 1. A meta-thing. Used to stand for a real object in didactic examples 
    (especially database tutorials). Legend has it that the original 
    widgets were holders for buggy whips. "But suppose the parts list 
    for a widget has 52 entries...." 2. [poss. evoking `window gadget'] 
    A user interface object in {X} graphical user interfaces.

    www.worldwideschool.org/library/books/tech/computers/TheHackersDictionaryofComputerJargon/chap55.html


    (n.) In a window system, a reusable user interface component such 
    as a button, scrollbar, control area, text edit area, and so on. 
    When an X Toolkit Intrinsics function creates a widget, it is returned 
    as an opaque data handle and assigned to a variable called a widget 
    identifier. See also OLIT.
    docs.sun.com/db/doc/805-4368/6j450e610


    – A graphical user interface programming object (button, scrollbar, 
    radio button, etc.) for the X Window System. (Also, see X Window 
    System.)
    www.newtolinux.org.uk/glossary.shtml

Ashley, widget is a good term as long as you explain what one is. 
 :>)

IMHO you have a tendancy to confuse a user if switch lingo in the 
middle of something so you might as well begin with the lingo that 
you want to use for the entirety of your docs and provide definitions...

...With the definition of each of them somewhere near the top of 
the document or easily accessible.


Yes, please give a clear defination and example for every term.  
Do not asume that anyone already knows the meaning of a term.  The 
fact that a term can have different meaning in rebol can cause a 
lot of confusion sometimes.  For example from the Core manual, "The 
copy word as used in parse is different from the copy function used 
in REBOL expressions. Parse uses a dialect of REBOL, and copy has 
a different meaning within that dialect."

Ashley, what is the point of only using positional references to 
sub-faces?  The whole reason that I started creating my styles was 
because I found the positional references of VID to be too restricting 
and difficult to deal with. IMHO, just making subfaces a facet of 
the style face increases the usability of VID at least 10 fold.

Louis, agree totally. Witness the confusion between Anton and myself 
in the View group about what a facet is (and throw into the mix View 
facets, VID facets and Style facets). I also don't like the close 
visual and phonetic similarity between face and facet ... it's just 
too easy to mistype / misread (with a single "t" to distinguish the 
two). Another term to consider:

	Feel, behaviour, action or event handler?


The very first section of the document will be a concepts / terminology 
section which will have a simple table that maps View terms / concepts 
to their RebGUI equivilents. Thereafter the RebGUI terms will be 
*consistently* used.

Ammon, positional references should only be the concern of the widget 
designer (ie. its not a user-code level concern). If a complex widget 
needs additional facets to control its appearance and behaviour then 
I'm all for it. Once we get a widget or two under our belts, we can 
write a "Widget Designer's Guide" to at least have common accessors. 
(there's another term we need to nail down).

Yeah, the accessors...  Not sure I really got the complete concept 
of accessors.  IMHO, it is just extra work and the developer not 
the end user who puts the widget in an application generally has 
to build those unless the end user starts digging deeply into the 
style.  This IMHO, is a MAJOR problem.  If you make the sub-faces 
a facet of the style then the end user can always access the sub-faces 
of the style and do as they like with them AND DO IT EASILY.  And 
the developer gets the benefit of not having to guess at all the 
ways that the end user may want to access the sub-faces!  That in 
and of itself is a goldmine, to me.

Terms: I'm all for using "standard" terms. I must say that View always 
forces me to map the words and rethink them. I would like to see:
	Window
	Canvas instead of face

 Attribute instead of facet (please keep non-native speakers in mind)
	Action instread of feel
	Widget instead of style

For me a Widget can have different styles: Windows, Mac etc.

in C widget libraries the names are quite the same but with a prefix

that's a suggestion nothing more

It's not a commandement ;)

Ashley!
Reading this page http://www.dobeash.com/it/rebgui/facets/
I see you have put a "?" for edge/image.
You can simply use an image as an edge :

Henrik, I think, supporting PS is a good thing! (TM) And we can still 
have PDF for those, who likes that. Has anyone done some work on 
PS in REBOL so far? Any scripts anywhere?

I saw that MS Paint is receiving a technological upgrade in Vista: 
The palette has been moved from the bottom of the window to the top.

When it can display a Workbench screen then I'll be impressed.

Henrick print PS files only works if the printer has PS support. 
Not every printer has this, and Apple move NextStep from PS to PDF 
because the PS rendering engine of Adobe is expensive. So PS printing 
will only work for PS printers. I think that is sort of ok, but not 
sure everyone has a PS printer.

Also OSX can print PDFs directly, it can even render directly to 
any media, because it includes a PDF render in the OS.

I lean toward PDF too, but the dialect is not much fun to use, it 
can take a long time to load, and you have to preview it before printing, 
not too mention versioning issues. Thats why I had been looking for 
a BMP printing solution. I was considering using PS for printing 
only images directly to printers, which would still be nice--mainly 
for non-win OS's. I think this would be much easier to impliment. 
I dont know squat about post script, but it could potentially be 
just a hack.

As I said in the pdf maker group ... postscript is a much easier 
thing to do than pdf.  I could then do high resolution graphs in 
postscript, and then use ghostscript or other utilities view and 
print.  Conversion to pdf is another possibility.

This is the unix way - lots of utilities to massage a format from 
one to another .. and not necessarily have the one product that acts 
as a swiss army knife.

this is a simple guide to postscript .. I read this the other day, 
and was programming in postscript the next.

I have no wish to defend my desire to see a postscript emitter.  
I only wish to see it done by people who have a mutual interest. 
 If you don't think it is of interest, please do not post negative 
comments.

Here's a first attempt at drawing postscript and then converting 
to pdf ... http://www.compkarori.com/emr/growth.pdf

why negative. It is because you read is as a negative. My reaction 
translates to - if PS is good thing to have, then let's have it, 
but then it would be good to have native rebol ps viewer (in AGG) 
or there will be a trouble, if such a thing is dependant upon external 
viewer. And that is my experience here and I can guarantee you, that 
in terms of our big corp it would be a problem. But enough, do what 
you think is best ...

If I get time, I'll see if I can create a web service that turns 
growth data into CDC chart.

Both PostScript and PDF ref. manuals are found on www.adobe.com. 
I took a quick look and found out, that PDF is mainly a document 
format incl. things as hypertext links and logical structure information 
for document interchange. Postscript's primary application is to 
describe the appearance of text, graphical shapes, and sampled images 
on printed and displayed pages. It makes good sense producing PostScript 
from REBOL to enhance printing abilities, and if it's much easier 
than pdf (as Graham points out), there is good probability of success. 
And supporting PostScript doesn't exclude pdf. We can have both, 
and it's two different things with different goals.

(as a world master here) First, Pekr, I can see how Graham interpreted 
some of your comments as negative ("Graham - either give me native 
rebol post script viewer, or forget it. I will not install ghost 
script..."), and I don't think he's being arrogant. I understand 
your point about wanting people to spend effort on things that are 
valuable to REBOL, but what's valueable to each of us is *completely* 
different in many cases. 


I hope you two can stay on good terms, because you're both valuable 
to the community.

(as a regular REBOLer) I've thought about doing the PS thing, because 
I hoped it would help printing support (and OSX uses DisplayPS, right? 
NeXT did too.). I also thought it would be a cool example, because 
of REBOL's Forth heritage that is very PS like (though I think someone 
once said that PS was *not* based on Forth..whatever). 


It shouldn't be too tough--I even have a couple PS book on my shelf 
if people need something looked up--but, like Pekr, I doubt the general 
practical usefulness for the average REBOL app user without a "full 
stack" of PS tools. That doesn't matter if you want it for yourself 
though, or we can bundle things into a distro for those who want 
it.

Gregg, OSX moved from PS renderer of NeXT to a PDF one. This was 
to save money from licensing the PS engine from Adobe. Currently 
PS is converted to PDF by third party tools. PDF on the other hand 
is direct.

Gregg, it's like cgi... unless you've got a web server, cgi is a 
waste of time for you.  If I have a web service that uses a postscript 
dialect to create a postscript image, and then uses ghostscript to 
convert to pdf .. well, that is useful to those running web services, 
but a waste of time for those who don't.

pekr, reading your comments seem to focus on a PS viewer. This is 
completely uninteresting to me. I want tools that are native to REBOL 
to allow me to print graphics directly to a printer with the fewest 
amount of 3rd party tools. How many shrinkwrapped apps out there 
need third party tools for something as basic as printing?

I've got a colour laser printer on my network which I think supports 
postscript.  I presume to print a postscript file, I just send it 
to the ip address of the printer?

I have a jetdirect usb print server at 192.168.1.253

>> port: open/direct tcp://192.168.1.253:9100
>> insert port read %boys-0-36-length-weight.ps
>> close port

the fastest route definitely. a PS -> DRAW thing would be a nice 
thing to have but DRAW -> PS is the most important right now

So, for example, if we used to plot dialect to draw a graph, we can 
then emit postscript and send directly to the printer.

yes, I think it should work like the DRAW function, but instead of 
producing an image it produces a string! value to be used however 
you want it

Or, perhap a block! for further processing?

An eps file is just a postscript file which is written in a special 
way ...

I also tried it with a pdf, as the printer supports direct pdf printing, 
but nothing happened.

DRAW -> PS is one possibility. Should we on a longer term also have 
a dialect or set of functions, than can produce PS?

DRAW is also a function used like:
img: make image! 100x100
DRAW img <some draw commands>

With PostScript, I'm thinking something like:
ps-output: ""
POSTSCRIPT ps-output <some PS commands>


ps-output could then also be a file! or port! and send the output 
directly to the destination.

<some PS commands> in the above is a block of commands with arguments.

Is the aim to take a draw block and process it so that postscript 
is produced.

It's one way of doing it, and maybe not so bad. I don't know enough 
about PS to see, if DRAW is too limited. Maybe PS has a lot other 
stuff, you wanna do, that is difficult to do in DRAW.

as far as I recall, it has quite a limited command set.

The DRAW approach is, that if you can produce your output in a DRAW 
block, then you can also print it using PS. My approach is to make 
a PS dialect, and keep DRAW out of is. With my approach, you can 
print from REBOL/Core too. I guess, we can have both approaches without 
problem.

but using a draw dialect is possible in core .. u just can't render 
it.

but let's start with a postscript dialect and then see if we can 
retrofit draw to it.

Then I just need a list of PS commands to get started on the dialect.

this has a reference at the end : http://www.cs.indiana.edu/docproject/programming/postscript/postscript.html

PostScript dialect test ready. Try this:
do http://home.tiscali.dk/postscript/postscript.r
s: postscript [font ["Times-Roman" 20] ["Hello World!"]]


s is now the PostScript output, that can be saved to a PS-file or 
sent to a printer.

no,it's a 404 response.

must be a case problem.

works here ok, must be a connection problem

Now it works. It seems, it take a little time, before tiscali makes 
content reachable.

It's a start.
What happen, if you leave out that part?

there's also a postscript preamble or header.

this ..  .75 setgray uses a gray colour for the text.

This is a good start though.

so, you need also the %! at the beginning, and a showpage at the 
end.

things like 'box can be defined as a function in postscript.

Desitions have to be made about the dialect structure. Should the 
outer block consist of font-specifications and pages, or isn't that 
structure the best for PS? A better understanding of PS is needed 
to answer.

I would aim for an implementation of PS functionality as a REBOL 
dialect. Nothing to do with draw yet.

we have Gabriele's pdf dialect to use a model.

his dialect must cover the same problems .. as pdf is a subset of 
postscript.

I'll look at all the PS operators to get a view of the whole thing. 
Then define a structure for the dialect (probably top-concept of 
a page), and then implement the operators most needed.

I wonder if we can't just use Gabriele's dialect and build a different 
emitter.

New version. The postscript block consists of font definitions and 
pages. A page consists of paths and transformations. Try:
do http://home.tiscali.dk/john.niclasen/postscript/postscript.r

print postscript [font [Times-Roman 20] page [path [at 72x72 rotate 
45 "Hello World!"]]]

A postscript block can have several pages, and every page can have 
several paths.

PostScript has a lot of operators (commands). For this REBOL dialect 
to be usefull, we should keep the number of features at a minimum. 
It's always hard to learn something new, and if the number of commands 
is too big, less will use it. I would like feedback on, what features 
should be supported in the dialect for a first version. This dialect 
can then be used in REBOL programs, that would like to do PostScript 
output. And I could make a PostScript output from my NicomDoc format. 
And then we could also have a DRAW -> PS converter.

I don't want to interrupt your concrete talk here, but I think I 
was a bit misunderstood. By "or forget it" I did not mean forget 
bringing PS to rebol, but "it" was pointing to ghostviewer. I am 
the last, who would not want to do everything in Rebol. So Henrik 
actually contradicts himself a bit stating that he wants to limit 
number of external apps = bring PS to rebol, but then how to do a 
preview?

In fact - my question could be just simplified - how do we do print 
preview without GhostView or other PS viewer tools? If that is "somehow" 
possible, then it is only good. That is why I referred to the need 
of AGG based preview, to actually save third app usage - a PS viewer.

OK, enough, and now something at least a bit more constructive:

I think, what Henrik is thinking about is, that if he already has 
something on his screen produced in REBOL, e.g. something from DRAW, 
then he just want to print it easily. But you're right, if we get 
all different PS-files in REBOL, how do we preview them then? I don't 
want to, I want to easily print a NicomDoc document, I alread see 
on my monitor.

One thing that may become an issue on the future is syncronization 
of Color Profiles. Different display and printing devices hace different 
gamma curves. This should be an issue for black and withe and vector 
graffics, put if you are printing a rebol screen. Then you may need 
to take the color profiles into consideration.

However, my point is that for printing PS is not the universal solution, 
but having a partial  solution is better than having none.

well we can convert a draw block to-image and then send that out 
directly.. but its very slow to print... I mean sending 300 dpi or 
more bitmaps to a printer is tedious.

300dpi = 300 ticks in an inch.  if you know the printer edges to 
be 1/2 inch, then you can juste calculate a 2250 wide bitmap (using 
US letter size paper)  and send it .  this works.  simple math .

one of the reasons also for a DRAW block is that you can preview 
your output first. Not so easy with PDF Maker...

a good solution might be to use decimal 0-1 values and just recompute 
them to whatever output you are using (so adapt to any paper/bitmap 
size)

Ok, text and vector graphics ... and some grey-tone/colour for a 
start. And then the rotate, scale and translate, that's already included 
in my postscript dialect.

for line elements, and text, that should not be a problem ( given 
the same fonts ).

that should be very easy to do with a postscript dialect.

I've seen a problem with a barcode reader that could not read codes 
printed from one expensive printer and it would read them fine if 
printed from another cheap printer

turned out the expensive printer was able to separate two parallel 
lines just by a hair's width, where they should appear as a single 
line at double width of one line. that made the barcodes unreadable.

it relied a printer deficiency to work.

and it looks correct when viewed in a PDF Viewer

like a test suite for any dialect that is written.

Funny, I was just thinking about that. I think, I'll just make the 
first dialect being a small subset of PS, and then license can be 
the one, Carl talked about in a blog. Was it BSD?

graham, even if I take a good PDF viewer and zoom all the way in

so it's probably a problem with the printer, but still one that should 
be solvable by setting the width of the line jsut a few hair's width 
thicker