[ALLY] Re: Freeze Snapshot?

maybe you can use [load to binary!] ? i use enbase/debase without compression for pics. another: you can fake a ram-floppy by a little protocol. this gives you binary load from strings :) could also solve this 'load-thru ..versions, something like [load thru-net://my.jpg]. Volker

asynchronous, tasking, modular, whatever :-) agreed ...

I am fine with fonts. However - I very rare use default setting for fonts. Do you think it is really good to have shadowed fonts by default? I don't like them because of worse readability ...

Not sure it fits View philosophy - we have very core architecture - faces - and as I suggested, we could build menu plug-in, component, module, widget, call it whatever. But looking at matlab, their figures have possibility to have default os menus .... after all - we use default os window bars, right?

Hmm, if we are talking view - I will not more agree to such arguments :-) For me there is only one way for Rebol, or I would probably not use it .... e.g. if RT would not show me a signal having components, modularity, etc. is the way to go, REBOL would not be technology worth enough for me, as I know what Carl gave us by creating AmigaOS and what he has promissed to us - to bring us better system .... So, DB connectivity is case for separate component. Once we have dynamic components, you will be probably able to buy just what you need - I e.g. don't need /ODBC, /Oracle so why should I pay for it? It's also very limiting factor for RT itself. If someone has already Oracle, he/she can probably afford to pay some XXX or even XXXX USD for /Oracle. I can very easily imagine buying /Shell for 30 e.g. and /Library for 50 - 100 USD ... current state of things is something I can't understand - do you know language where you don't have shell by default, or you have to use special version to just call libraries? One and only core.exe and others as components (libraries) - it works that way in computing for ages ... But looking at practical usability, I would better welcome things as load/files, load/dirs, load/dir-tree, find/deep, native drawing lines, boxes, circles, ovals, filling the areas as effects to faces. They are small additions but can help so much to speed certain functionality. Also operations upon arrays is so slow. Why don't we have basic matrice operations? I've heard many things can be solved by matrices - e.g. own effects to faces ... Should I add, change of mouse pointer? Mouse is still the same thru all the states, it's sometimes confusing ... btw: why 'load doesn't allow us to load images from strings? Let's say I have packed image, will 'decompress it, but can't load it into image datatype. The only way seems to be to save it to file first ... Later, -pekr-

1) I am not sure if RT is sure about the same kind of licency as we have it with /Core .... but they imho should be :-) - what's more - once /View is just and only component to /Core, it should be regarded no separate product, but just some kind of library (component) needed to present your work ... or maybe not :-) Well, Carl & the gang surely knows where they want to go .... 2) as for freezing the product - yes, last experimental of /View (at least under Windows) seems to be pretty stable. RT should however fix what is fixable in short period of time ...Also look at Allen's rebolforces site for some issues to solve ... I would also like some small additions requested from early /View beta 1 version, as change of the state of mouse pointer (we can store bitmaps in system structure, right?), possibility to hide mouse pointer, transparency at top level, ability to open window in such mode, that it would stay always in front (imagine floating bars in Photoshop e.g.), some basic drawing primitives implemented as effects - line, oval, circle, box, filling of such areas, etc. stuff ... Of course, much of the requested stuff doesn't break current functionality in any way - it just does View more usable, possible faster. What I fear of more are changes to core - It would be good to have modules introduced soon. It would be also good to dynamic components ready soon and have one and only rebol.exe/Core. - it's stuff which can influence the style we design rebol apps. It's sad knowing rebol/apache with modules would rock, and see /Express developed upon current solution, while Carl posted his concrete description for modules functionality some half year(?) ago ... -pekr-

at

Hi Elan, Stable enough, Yes. It is getting very close to release, I think it is only one (or maybe 2) revisions away from being releasable. It is just a matter of refining what is there. ToDo... 1. Changes to ports to allow better backround asychronous events/downloading. 2. Minor cleanup in VID. Expansion of variety of VID gadgets. (some of this can be done by the REBOL community) 3. Consolidation of the various caching functions ( read-thru, read-via, load-image, load-thru, read-net) 4. As mentioned by Petr, stay on top windows and real modal popups. 5. Scaling & Font Rotation: Planned features, that could be dropped until v1.1 My Wishlist, 1. A way to create native Menus in the Windows. 2. DB connectivity... Cheers, Allen K

Modal popups are evil. I hope we all have the good sense to avoid using them.

My wishlist: 1. Scroll bars with both the buttons together at the bottom/right, and that don't snap back to their original position (as in windows - eugh! help me!) Anton. :)

make object! [ redraw: none detect: func [face event][ foreach evt-func event-funcs [ if not event? evt-func: evt-func face event [ return either evt-func [event] [none] ] ] event ] over: none engage: none event-funcs: [func [face event][ if all [system/view/focal-face event/type = 'down event/face <> system/view/focal-face system/view/focal-face/dirty?] [ do-face system/view/focal-face none] either all [event/type = 'key face: find-key-face face event/key] [ if get in face 'action [do-face face event/key] none ] [event] ]] ] The first event-func seems to be guilty of that behaviour; you could just remove it... HTH, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/