AltME groups: search

Do you guys see the same result in this script:
do http://www.fys.ku.dk/~niclasen/rebol/test/transform.r

if you try it on Mac, Windows and Linux (or any other View version 
supporting the DRAW dialect). The circle, line and triangle should 
be lined up.

hmm, maybe I should try View 2.7.4 under Windows too though ...

Geomol: The behaviour of LINE you have spotted is not a bug. Try 
this code to see the difference:

Try the /show refinement.

Can I try it?

try one of the options like call/show

Hi Ladislav  welcome back 

I have no idea what curecode is ,  assume it is rambo5 or whatever

I don't need random numbers  myself at the moment  (I sometimes use 
hotbits )

I need to answer a homework question with something other than "don't 
know"  

I will go try to find out about curecode

Try to search using google: "rebol prototype based objects site:rebol.com"

You will find nothing apart "Core product information" and something 
on "Rebol/View" then only in the lower part of the page you will 
findd something in REBOL3 docs.

try call/show

Fish, try here.

try  "secure :b"

when I look in the script, there are load lines to uncomment depending 
on which version to load. it looks like this in my case:


imagemagicklib: %CORE_RL_magick_.dll          ; uncomment for windows 
version

imagemagickwandlib: %CORE_RL_wand_.dll          ; uncomment for windows 
version


; imagemagicklib: %/usr/lib/libMagick.so      ; uncomment for linux 
version, try to find where it is installed

; imagemagickwandlib: %/usr/lib/libWand.so      ; uncomment for linux 
version, try to find where it is installed

The cygwin version would try to load X11.dll. The native version 
wouldn't.

Try this: http://www.imagemagick.org/script/binary-releases.php?ImageMagick=m148pm1far9d2bsj0b5tpb9ui2#windows

Ok...I try to vote to...where do we do this voting?  :)

I am going to try and start it ...

Had to find an old version here with the *-reg funcs, which ended 
up being 2.5.6. Reading works fine. Didn't try writing. Of course 
XP x64 is basically Server 2003, which may behave very differently 
than Vista or 7, security wise.

full ack BC, graham if you need (like) zfs try freebsd, it's already 
there. 
better perfomance, cleaner handling and much faster than linux. 

if you need a wm try xfce or lxde. feels like running win 3.11 on 
a quadcore.


for rdbms look also at monetdb, in nearly all cases 5-10 times faster 
than mysql.

very advanced designed dbserver and a nice abstracted query layer 
for sql and xquery. 

if you need a good allrounder/workhorse try postgresql (scales good 
on multicore)

free- or netbsd is a solid base for this. (but only until a real 
smp ready microkernel
os like minix is finished :-)

interesting, will try this one. yes you are right multicore support 
makes sense.

I'll try sorting ..

I'll try that one

I'll try and remember that when I learn German :)

try 

suffix? myfile

try

print extension = %.pdf

That kind of change is not going into R2 - it's not backwards-compatible. 
Try R3.

Gregg, the problem is that the changed INDEX? would have the possibility 
of returning data that is not an integer. Most R2 code doesn't screen 
for that, so changing INDEX? in this way would lead to data corruption 
in existing code. Remember, compatibility with existing code is the 
highest priority in the further development of R2. Incompatible changes 
are reserved for R3 *only* - we try to not make them in R2, on principle.

ah well - it was worth a try.  Guess its break out the C++ after 
all ;)

ICarii, as mentioned, I made a floodfill in my paint program. You 
can try it with:

do http://www.fys.ku.dk/~niclasen/rebol/canvas099.r
(Works best under Windows.)


On a modern computer, it fill with about the same speed in REBOL 
as DPaint did on an A500 computer 20+ years ago. I also made a rebcode 
version, which fills the entire screen almost instantly. That version 
isn't out there.

Folder aliasing is there to make up for silly people who still write 
apps that try to write to their application path without sufficient 
rights. If people had paid attention to the rules in 2000, we wouldn't 
have this mess now - Windows apps would be acting like Linux or Mac 
apps, and putting their files where they should be.

I agree, as long as the rebol.r *enables* has final control and nothing 
requires to be stored in registry, its all good.


obviously, windows will want some stuff in the registry for its own 
management, but rebol should not peek there to try and determine 
anything.

if it really has to.. put that registry peeking in the rebol.r

well, they just relax the enforcement... the rest of the os is still 
there... they still support most of the old api, its still just a 
tack-on more stuff and try to make it compatible again.  I know some 
of the kernel changed, but that doesn't really affect applications 
that much, since that is mostly doing stuff behind the API wall.

if you try to change the read-only property of files/folders they 
aren't actually applied, it was listed as a bug on severl IT sits 
on the net.  

basically, many applications suddendly coudn't write to folders anymore. 
 I had problems with rebol in SOME paths.

I even had issues with xcopy!  


looking at the files in a shell, they where all listed as read-only 
and couldn't be set to anything else... (this wasn't within windows 
folders, but on a data disk, before you ask ;-)

Graham: re Linux font paths, that could be better solution than the 
current state. Though it is still not 'automatic' solution I can 
imagine that Linux users will be happier with that. I'll try to ask 
Carl what he thinks about it.

On my windows XP SP3 the VIEW is failing as invalid exe; the CORE 
is fine;  these are both numbered 3.1 for 2.7.8 and no change with 
fresh download; the inspected exe is not garbage but kicks this error 
whether in open cmd session console or fired by explorer - I did 
not try under Cygwin or MSys yet ...

Ok, so works on XP, fails on Linux and Wine. Will try Win7 later 
on.

Interesting, but that's a very empty example. Can you try with command 
parameters?

Let me try with 10 parameters each.

If I had more time, it would be good to try some zlib/gz scheme.. 
but that's not important for me at this moment.

I thought about user, downloading a distro. If those are not distinguished, 
I would try to DO each script, just to demo the REBOL. And doing 
a module usually does nothing more than loading the module = nothing 
visually usefull. So I would not mind having .r3, .rm, .rx

it goes beyond name clashes... R3 extensions have a specific duty, 
we are not loading OS libs directly within R3... import must not 
try to access these.


I would prefer to have a specific loader for extensions something 
like.

EXTEND my-extension

Damned by faint praise, but true. The real trick is to make sure 
that LOAD-EXTENSION doesn't try to load non-extension system libraries.

You can try them in the order the suffixes appear in system/options/file-types. 
That way your code doesn't have to special-case per platform; let 
the host code special-case it instead. Just in case .rx isn't supported 
on a platform, you might consider searching for 'extension and backtracking 
to get the file! suffixes.

You could try to have the progress callback in the cURL binding pass 
a series. cURL is singlethreaded, so this would establish whether 
it's a threading problem or an R3 memory management/callback problem

Can you try ensuring that the callback is initiated from the same 
thread the R3 host (interpreter) is running in?

There's a couple bugs in the REBOL portion of the ODBC extension 
mentioned above. I'll try to make a patching wrapper module.

To get that, you need to try xy times. Most of the time I am holding 
down the bottom-right corner, moving randomly the mouse (I remember 
REBOL in the past did not receive updated info about about size, 
unless mouse button is released), and it accidentally can end like 
that. Dunno if any such info is helpfull ...

Pekr, regarding your

lay: [

		when [load] do [print "Load trigger!"]
		clicker
		button "Do" alert "Button pressed!"

  button "Big Quit Button" maroon options [max-size: 2000x50] quit
		bar
		text "Toggle button..."
		t1: toggle "Toggle" of 'tog
		button "Set False" set 't1 false
		button "Set True"  set 't1 true
		toggle "Mirror" attach 't1
		toggle "Mutex" of 'tog
		bar
		text "Radios and check boxes"
		radio "Set above toggle on"  set 't1 true
		radio "Set above toggle off" set 't1 false
		bar
		check "Checkbox attached to above toggle" attach 't1


]

child: make-face 'vpanel []
set-panel-content child lay
view child


example - it is incorrect, since you try to give VIEW a HPANEL instead 
of a WINDOW, I suppose, that it was just a test, how it would look?

OK, leaving for a business trip, but one other question:


when I click toggle, it crashes. It seems to me, that the 'of reactor 
and namely exclude panel is not handled properly, but I will try 
later ...

Cyphre, thanks for the tips. If you will have any new release with 
some bugs fixed, please post it, so that I don't try to adapt already 
dated sources ...

Henrik - don't even try the old crap on me again :-( The reason why 
Carl started new GUI was because of Gab's GUI was not all that easy. 
If I want 50x50 button, don't even dare to dictate me, that I can't 
easily have it. If I can't, I almost refuse to use such a system 
period.

will give it a try ...

Henrik - don't even try the old crap on me again :-( The reason why 
Carl started new GUI was because of Gab's GUI was not all that easy.


Henrik - I believe you will fail explain technical reason, why it 
prevents proper skinning


An exact failure in understanding why face hacking is not welcome. 
Gab's GUI was not easy due to a number of layers needed to describe 
the look and feel separately, as well as requiring you to handle 
GOBs manually. But it supported applying proper meaning of styles, 
because Gabriele had the same goal as me. Carls does too and RM Asset's 
does this even more. We just have to take advantage of it.


Have you never had to fix someone's MS Word document, so that TOC 
generation, links, indexes, headlines, etc. could be understood by 
Word, because they had resorted to manipulating the words directly 
with colors and style, instead of using Word's style system? This 
is exactly the same problem. You will be teaching beginners that 
their layouts won't scale properly for exactly the same reasons. 
Many people therefore never really learn to create correctly formatted 
Word documents.

the screen flashes if we expanded the window - i try hello-worl.r3

The outcome of the case not recalculating INIT-SIZE, MIN-SIZE and 
MAX-SIZE would be, that the panel would try to occupy the same space 
as before the change. That may be what the user wanted, if he had 
a specific idea, how large the panel should be, regardless of the 
contents he might add into it later.


The outcome of recalculating INIT-SIZE, MIN-SIZE and MAX-SIZE (on 
the other hand) is, that the panel dimensions are auto-changed after 
almost every change. It looks especially "ugly" in case dividers 
are used to change panel dimensions, since if you change the X dimension, 
and later the Y dimension, due to INIT-SIZE recalculation, your former 
change may become totally ignored.

So - one more note - if above would be wisely implemented, I am for 
auto-update with manual override not to update for the style author. 
But if I would get unexpected results, I prefer not to auto-resize 
probably (but not 100% sure, unless giving it a try for a while)

As you can see, I need an answer to above questions too. It is all 
about what is the most pleasan vs unnerving to use.

 - frankly, you can at least try the examples provided and see what 
 happens now; and, eventually, present your observations here

We need the ability to create events
 - so you should try make event!

Why does following does not work? I try to set the panel to the 'plain 
mode, but calling 'show crashes the code:


>> view [p: hpanel 200x200 [button do [set-facet p 'draw-mode 'plain 
show p]]]


So - how do I refresh/redraw the panel? Should I somehow call the 
'on-update actor?

Robert - I can't see any subsystems ready, other than proper resizing 
(which is really nice), and focusing system. How can you say 2-3 
styles are enough to judge the design? I would not call non-working 
styles being an eye-candy :-) This is all about architecture -  when 
porting demo, I meet the case when I am able to easily change e.g. 
color of the scroller with Carl's GUI, which does not seems to be 
a case with RMA's GUI, or I just don't know how to do it. As I did 
not want to bether you here with such simple stupid thing, I tried 
to study material-system myself. But - I can tell one thing - if 
those things are not simple on the surface, it is either - missing 
docs, or very wrong architecture.


You should really remember, why Carl decided to rework the GUI - 
to be the pleasure to use, kind like of Amiga AMOS Basic, yet still 
allowing more complicated designs. If that aspect will not be pursued, 
ppl will not like the GUI. And what is the system good for, if not 
liked to be used by ppl?


OK, at this point, with 2-3 styles in focus, I might postpone port 
of the demo, no? As the demo is surely done with more than 2-3 styles 
:-) I will soon finish it to the state, when clicking the left side 
list items will not crash the demo. Non working stuff will be commented 
out. Then others might try to get more complicated set-ups running 
...

There was very long discussion, towards if we should allow to change 
the size of the button to allow any size being set" - did you really 
mean it? One can easily make sure, that the init-size of the button 
is set as specified." - Yes, I meant it, because IIRC there were 
opinions, trying to suggest here, that it should not be allowed at 
all :-)


All stuff you write - I know. It is just that I might not necessarily 
agree with the outcome. I am trying to think form user's point of 
view. I wonder to what points you would agree, and to what not:


- Let's assume I set button in bounds (between what min-size/max-size 
allows): I tried various scenarios, and I almost never got button 
of requested size. The reason is in how resizing system works. In 
fact, when inspecting various sizes - init-size, min-size, max-size, 
those don't contain actual button size. Actual size is in face/gob/size. 
Button gets different size due to resizing system cell alignment 
imo. From the resizing system point of view, it is correct behaviour, 
but from the user's perspective, it is questionable, if the result 
is OK?


- In regards to above point, I really wonder, if buttons should be 
resizable at all. I said - resizable, not settable. I wonder, if 
I would like buttons to be of consistent size. I might try with face/resizes?: 
false, if that would make the trick.


- Then, in regards to above - I might think of init-size setting 
the requested button size


- Maybe (and I am not sure about that one), we could allow some debug 
info - "out of bounds", if my init-size value does not fit in between 
the min-size, max-size, as style author defined it. I have heard 
that guys are working on some field accessor functions - those might 
be able to print some debug info to console, at least when in interactive 
mode.


Othere than that - this one is a minor issue for me, I e.g. care 
more about architecture, and so far I can see materials having real 
low benefit, for how complicated it turns out ...

- In regards to above point, I really wonder, if buttons should be 
resizable at all. I said - resizable, not settable. I wonder, if 
I would like buttons to be of consistent size. I might try with face/resizes?: 
false, if that would make the trick.

 If you set the RESIZES attribute to OFF, you get a completely different 
 behaviour, than what you expect:


- the resizing algorithm will leave the button untouched, which means, 
that it does neither compute the position, nor the size, and the 
button would just "float" - the next version will contain more than 
20 different examples, Cyphre's visibility example manipulating the 
RESIZES attribute included


- if you just want the resizing algorithm to not change the size 
of an element, while allowing the resizing algorithm to compute the 
position of the element, you should do it differently. Just set the 
INIT-SIZE, MIN-SIZE and MAX-SIZE of the element all to the same pair. 
You will notice, that the size of the element will not change, no 
matter what, only the position may change.

try removing the "30"

Guys, I don't know how often I have to repeat it:


1. we get basic concepts implemented. All these basics are seperated 
as much as possible. That's why it will be totally incompatible to 
Carl's GUI. And, we don't try to be compatible. Our goal is to have 
an enterprise enabled GUI framework.


2. To do step 1, we just pick 1-2 styles, and enhance and change 
them exactly to just work with the concepts from 1. And, please see 
the plural in "concepts". We are doing step 1 & 2 by concept.


3. If this stabelized, we take the next style and adopt it. This 
might lead to some changes in 1. which than have to be carried forward 
again.

4. Then either next style or next concept.

It works for us for those things we focus on. Of course, if you try 
to do other things it won't most likely not.

Cyphre - just some friendly opinion exchange, hopefully you will 
be able to understand my explanations (which don't necessarily represent 
my exact point of view):


- most ppl here are well aware of the fact, that RMA is a business 
entity, and hence has absolute right to do what makes sense for its 
business. The trick is, that in the end, it does not work for ppl, 
I will tell why later.


- The point above is even more difficult to understand, as RMA is 
offering its work for free, yet ppl still complain to something (including 
me of course)


- What might have failed is, that ppl might think, that accepting 
SCRUM method will mean, that we have finally found a viable model 
for  general R3 development, which will allow Carl to stay available 
 to small agile team of developers, isolated from the noise.


- Ppl were expecting GUI to probably appear in 2-3 month period. 
Althought Carl's GUI worked mostly on the surface, it was something 
ppl could experience. RMA's aproach is much broader aproach to usability 
and architecture. But - that resulted into refusal to provide usable 
demo. There was some attempt to provide style browser, but it was 
highly unusable to attract ppl.


- RMA seems not to understand (or it is not its priority) the importance 
of visuals. You surely remember the "design sells" claims, which 
are know for ages. Do you remember your Rebcon AGG demo? So much 
joy, so much applause. The current look of the GUI and its metrics 
just ruined the "hmm, nice" first look experience, and for no apparent 
reason, then constantly repeating "the skin will be done later". 
If so, it should not have been changed in the first place. (After 
porting the demo, my next area to play with is to try to play with 
material system, etc., and box-model style metrics)


- Ppl are well aware, that RMA is mostly on its own, and that even 
SCRUM methog did not work in regards to keep Carl attracted to such 
method in the long run. We are now facing the worst ever period of 
R3 development, where Carl apparently has some other projects, and 
R3 is almost stalled. Ppl are clever enough to realise, that we are 
being fed with some mid-time blogs, which should keep us distrated 
from the facts (huh, rebol file suffix importance anyone?), and we 
are also facing rushed releases as A111 is, and 2.7.8. was. You are 
free to not agree, but that is how I personally feel about the situation 
towards the RT. In the past I would probably write some letter to 
Carl, but I am at the point where I think, that RT is effectively 
burrying R3 under month by month. So - Carl is not able to find free 
time to continue with R3 development on a regular basis, and noone 
is denying his right to personal life, but - the fact is, that R3 
situation is at least - worrying. We wait for the beta plan for more 
than 4 months! If someone does not have time to even think how to 
proceed, then it is probably time to close the shop ... or open-source 
... but that will not happen. So - welcome the Amiga fate ... 


- And before someone else adds it, I will add it myself, as I believe 
I have my points right :-) Amen! Could I be wrong? Of course I could. 
You can easily state - hey, the situation is not like that, we know 
Carl works on this or that. Well - RMA knows, but that's it - the 
rest of the community is kept in information embargo from Carl. And 
that is difficult to deal with for many of us, who really like REBOL, 
and would like to see some coordinated development and the light 
in the end of the tunel once again ....

Ladislav, are you now forbidding me to speak on publicly available 
projects that I tried?

 - no, I am just suggesting that you are trying to speak publicly 
 about project you *did not try*

Next time when we try to promote someone's project, we'll have them 
sign a contract in advance stating that they want it

To recap:

- Kaj has reported crashes of a111 on WINE, both RMA's and Jocko's 
builds. He doesn't use Windows, the supported platform.

- RMA needs to update its modified date for r3-gui.r3 when it changes 
its component parts.

- Jocko now knows his build was outdated, and has likely updated 
it. This will solve the additional Jocko build problems.


- Ladislav, please note that Kaj's crashes with the RMA build were 
WINE-related. Only later did he try Jocko's build. Testing on WINE 
might help.

- Kaj, please try demoing on Windows if possible, and if you aren't 
too annoyed to demo the RMA GUI stuff.

view [progress 50% slider scroller] - try this code to see what I 
mean ... and try the same code in Carl's gui. What is wrong with 
his scroller? It looked much better.

it should work. I would try replacing each part with simple colored 
boxes, so you know where the boundaries are.

Rebolek - thanks for the info. I would try to change it even if it 
was your implementation, just as an excercise to become familiar 
with draw blocks for the first time. Henrik's suggestion was to use 
plain colored boxes, to become better familiar with borders, margins, 
paddings, edges and all that stuff :-)

You're of course free to write new skin for scroller or any other 
style, because we're not going to do much about it right now. You 
can also try to write scroller as coumpound style of two arrows and 
one slider but I do not recommend this overkill.

I have just checked, the new version (1993) is released http://www.rm-asset.com/code/downloads/files/r3-gui.r3
. I will try it

i try to put a table in a tab

Following few things:


- why is "custom" include needed? We should either user R3 native 
facilities, or include an include as a standard into R3 :-) (this 
is no real question, just a remark that if we find it usefull, then 
why notto make it part of R3?)

- RMA does not work with CureCode tickets. It would be good to either 
dismiss/close or resolve them? E.g. I find renaming of do-style and 
do-face to do-action, do-reaction a good tip to implement


- we should resolve the size of buttons vs scroller vs tabs. In Carl's 
GUI, button is 28 pixels tall, and it feels OK. Our's here is 22, 
I have no preference here, but could be those 28 pixels. Scroller 
is only 16pix - not acceptable imo. It should be of the size of the 
progress. Tabs are proportionally too tall.

- tabs should have line removed for actual tab. I suspect it might 
be more difficult to draw the container then.

- there seems to be someone at RMA liking Old aqua interface of MacOS. 
Tabs, buttons and scrollers are a good example ... of how to not 
do visuals anymore :-)

- area - enter few lines, go to bottom, and try to hilite the text 
by keyboard (shift plus arrow-up). It always hilites only actual 
line

- info areas, labes, etc., should prohibit display of caret, maybe 
allow hilighting, but allowing to have caret in "disabled" area is 
not looking nice

- text-table buttons are Excel filter inspired, but looking strange 
- some more thoughts needed
- select-an-option does not allow keyboard navigation

- text-list does not scroll, when navigated by keyboard, ditto text-table

- tabbing feels strange for text table. I alway said, that we need 
nested tabbing. I can imagine tab stopping on table, but next tab 
moving away, not actually going into tabbing in terms of the hilited 
widget. Enter should enter the more complex style, escape move away. 
That is not typical also at OS level, but then - everybody has it 
wrong :-)

- between the text-list and text-table, I have to press tab three 
times -visually I am not sure, "where" hilite disappears

- is text-table a compound style? What sense does it have to have 
buttons hilighted, not being able to enter the action? Why are not 
arrows tabbable? Table headers cells should be one style, not two.

- text-table is the weakest "grid" we ever had. Comparing to Cyphre's 
style pack, and rebgui grid. This is like 5% of functionality, not 
thought out style, useless for any serious data. I want to see the 
display of infiinte amount of data, proper caching.

- tab should be tabbable, ctrl-tab allowed to switch between the 
tabs  


I find the styles/gui inconsistent. There should be someone defining 
the styles, their behaviour to keyboard navigation, tabbing, etc. 
So far it seems like style being put together with no deeper thought 
about the end result of the whole GUI.

As for the consistency, and my complaint that the whole gui is not 
build with unifying idea - it has NOTHING to do with the skin. Just 
look at arrows:

- arrow button
- arrow button of scroller
- arrow button of drop-down
- arrow button of text table


Those are all different, and this is exactly the reason why some 
ppl try to do comound styles - to have just one arrow. If you are 
not carefull, you end up with above different arrow representations 
...

I'll wait for next relase. For me, the person who mostly uses keyboard, 
the demo shows it is very broken in that regard. Maybe I might try 
to catch few bugs here or there with simpler set-up than 'all-styles. 
But then Rebolek knows about the bugs, so I don't know if the experimentation 
would not be wasted?

In the case of 

hpanel [] options [framed?: no]

I think that someone might want to create a shortcut:

stylize [hpanel-frame: hpanel [] options [framed?: no]


... so in the end ppl would try to come up with new name anyway? 
Just thinking lound, not having particular preferences here, but 
still not sure about #FRAME, as it introduces new way of how to parametrise 
the style?

I have problem accepting result of examples:

15, 23, 24, 25, 26, and I stop here, probably many others ...


The problem I see is,that I don''t want elements to jump during resizing 
the way it does. Please try form example 15. IMO if we don't support 
scaling, the text and its spacing should not change at all. I would 
expect panel being enlarged, but all it does is the panel moves down, 
and GUI creates space between the header text and the consecutive 
text.


Also - look at example 26 - why the last line of boxes is shifted 
down the window from all the rest of the boxes?

Panel example #35 - I just wonder, how many ppl will feel lost the 
same way as I feel. The naming terms in regards to results are difficult 
for me to resolve. As for alignment, there is several way of how 
to name things:

halign, valing


left , right, center (vleft, vright, vcenter, hleft, hright, hcenter)


left, right, center, top, middle, bottom (or the corner alignment 
-  top-left, top-right, buttom-left, bottom-right - if those would 
be used, I would immediatelly understand it)


But - let's try to think about it a bit - we have some alignements 
in various GUI levels. If possible, let's stay consistent (e.g. it 
is enough that low-level text handling uses MS Word like terms, which 
don't relate to the rest of the gui)

E.g. try also panels-26.r3 - why the last line of boxes stays "attached" 
to the bottomof the window, causing a space?

#[[Pekr

E.g. try also panels-26.r3 - why the last line of boxes stays "attached" 
to the bottomof the window, causing a space?

Pekr]] - that is an example "inherited" from Carl, and it behaves 
as it should, taking into account, how it was defined. You need to 
take a look at the code

And, especially from you, it is unfair, taking into account, how 
many times you did not put to use the oportunity to present your 
preference in various user polls. 'The informations about user preferences 
were much needed then, and it is a pity you, instead of helping us 
to know user preferences in many cases, try to dishonest our efforts 
publicly by misrepresenting it as "cooking behind the closed doors".

report towards panel #32 - make the window so large, that on Y axis 
(vertical), the scroller is 100%. Then try to move the scroller (or 
press its arrow). The panel jumps in a strange way?

I just got crash, when clicking into the field, R3 vanished.I will 
try with new session.

Henrik, other than that, marking the text is really buggy. Here's 
few things RMA needs to look into:


- go to the area, type enough text, sot  that it scrolls, and then:

        - when you are at the bottom of the area, just press shift + up arrow, 
        to hilite the text - only one line is hilited -  the alghoritm is 
        buggy

        - go to the top. Try the reverse - shift + down arrow - it hilites 
        the text correctly, unless you hit bottom, then it starts to hilite 
        from the beginning, and cycles forever. It should just stop at the 
        bottom


- the most troublesome behaviour though is, that when you move out 
from the bounds of the style, it stops hilighting. Simply an event 
flow is bad here. We should treat it like pop-up menus - receiving 
events even if outside of the window, while in mouse-down mode. That 
is absolutly needed, or the experience is highly uncomfortable - 
just try to hilite the field - once your mose goes away, it stops 
the hilite. That might be the reason why you think it is slow ...

Is anyone willing to try to develop a tree style?

Well, we all have a hell lot to do. There are just a some simple 
facts:


- making public releases cost us time. Not horrible lot but anyway...

- people are interested to take a look at the code and run the tests...
- maybe we get some feedback

All nice, but it doesn't move us forward faster.


I'm not frustrated I'm just wondering.... there are still a lot of 
excuses why R3 can't be used (which is wrong) but only a very few 
people try to build something with it.

I understand that you are focusing resources as much as possible, 
otoh it is a bit dangerous aproach - R3 GUI saw rather intense concept 
changes during last year. Anyone eventually willing to give it a 
try once time permits will think twice, as recent public release 
could be pretty much outdated in few weeks, API wise, etc. There 
should imo be a way, that upon some request or bunch of requests, 
public release is done e.g once in few months?

Anyone eventually willing to give it a try once time permits will 
think twice
 - excuses?

to give it a try once time permits

 - It didn't in the past, so high chances are that it won't in the 
 future too. Further it might be 1-2 persons. I take the risk of loosing 
 those...

You may try to put each windows into separate objects to make all 
the set-words are local. Then set them none manually when the window 
closed then call recycle. This may work?

But I guess we could at least try, if you have a particular hotfix 
in mind.

My approach was, instead of doing what many others do (try to remove 
things from the HTML that are known to be "bad", eg. use regexps 
to remove anything that starts with "javascript:" or anything between 
<script>...</script> etc.), was to only pass what was known to be 
good, and ignore everything else. This is a bit more limiting but 
I consider it to be safer (you don't have to play a game with attacker 
where every time they find a new vector, you have to add it to the 
"bad" list).

wow, thank you a lot! I knew this was to obvious "bug" to be real 
and I am probably doing something wrong. GREAT!


I initially imported only needed modules but got errors .. ( I will 
try and report ) the errors went away as I manually imported them. 
Just a second

It's possible to do such a test... just to compare the performance 
with ansi strings only and with strings which contains non ansi chars 
as well (so are stored as wide char internally). I can try it once 
I will have some time again.

maybe it works only with my messages...should I try again? ;)

I was going to try using the i686 build (on this machine) of MinGW-64 
in Cygwin as my only Windows x86 compiler. Then I'd only need to 
add the Android ARM and x86 cross compilers to cover what I currently 
need to compile, and be able to make 64bit apps when I get my Win7 
machine rebuilt.

Alas, that kind of problem is exactly why you don't want to rely 
on the implementation model of the GC. One thing we know about the 
GC is that it is the stop the world type. If we need to solve the 
problem you mention, we would have to completely replace the internal 
memory model with a different one and use a GC with a completely 
different algorithm (generational, incremental, parallel, whatever). 
That means that all of your code optimizations would no longer work. 
If you don't try to optimize your code to the GC, it makes it possible 
to optimize the GC itself.

No prob, I already overpower parse In My not so Humble Opinion.

I already have many attempts with incremental parsing, even with 
R3.
I just try to come with the best design.