r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3-OLD1]

shadwolf
9-Apr-2009
[13078]
the actual situation is a pain R2 doesn't evolve and R3 is not stable 
and evolve so much that it's hard to base any serious developement 
on it yet .Where is the point if you have to restart your project 
from scratch every weeks because all changed
Pekr
9-Apr-2009
[13079x2]
Shadwolf - I am not blaming anyone. Font ugliness has something in 
common with font hinting. Cyphre told me, that such code in AGG is 
licensed (or patented?), and that we will have to find some other 
way around. But you would have to ask Cyphre, I don't remember exactly 
what was the reason ...
as for rich-text - you don't have to use VID at all, just gobs. Besides 
that, VID 3.4 (Carl's VID, Gab's was VID 3.3) is the official one, 
and although we expect some further additions/changes, basic principles 
are in there and they will not imo change much ...
shadwolf
9-Apr-2009
[13081x2]
PEkr hum gtk+  lol
no i'm kidding around ...
Pekr
9-Apr-2009
[13083]
Don't understand gtk+ joke .... (probably because I know little about 
gtk itself :-)
shadwolf
9-Apr-2009
[13084x2]
but having a VID 3.4 means we got a VID 3.0  a VID 3.2 a VID 3.3 
and those free where abandonned how can i be sure in the 6 month 
to come carl won't change again his mind
and since text editing is related to UTF-8  better to get all the 
things ended to not have to constantly have to redo part of the job
Pekr
9-Apr-2009
[13086]
all previous VID's were Gabriele's implementations of Carl's/Cyphre's/Gabriele's 
discussions/specs. But for some reason Carl was not satisfied and 
decided to go with other design. And as it is Carl himself we are 
talking here, I would bet that the design will stay :-)
shadwolf
9-Apr-2009
[13087]
Pekr > you said we need to find a better way to handle fonts in AGG 
cause part of it was pattented (or OSE related) and i sugested GTK+ 
 with is os independent and GPL 2.0 (pango is a heavy but really 
complete way to handly richt text rendering )
Pekr
9-Apr-2009
[13088]
btw - once we have plug-ins/dll back (integration methods being stronger 
hopefully), I wonder if anything prevents us from not using View 
at all, and linking Core to stuff like SDL, Qt?
shadwolf
9-Apr-2009
[13089]
but gtk+ is 10 time the  size of a rebol VM ...
Pekr
9-Apr-2009
[13090]
:-)
shadwolf
9-Apr-2009
[13091x4]
maybe doing a server/client style project ... but even then we need 
 people to maintain that solution to fit the gtk+ cahnges through 
the time
but the thing is i really like VID
for me VID from far the best  graphical library ever made
even if it lack functionnality even if it's a raw ...  when you find 
a raw diamond you don't throw it away just because it's not polished
Pekr
9-Apr-2009
[13095]
I agree. So - let's wait for VID 3.4 to be finished to certain state. 
We still miss on some concepts there ..
shadwolf
9-Apr-2009
[13096]
the day Carl say R3 is stable get it I spend the 100% time I have 
to port area-tc that's a fact
Oldes
9-Apr-2009
[13097]
Again.. when talking about fonts.. I want bitmaped font support. 
For example I create font's for my Flash apps in Rebol using simple 
image where I draw pixel precise glyphs:
http://box.lebeda.ws/~hmm/fonts/fixedsys.png
And provide the needed informations in Rebol format:

http://box.lebeda.ws/~hmm/fonts/fixedsys.png.txt(using UCS2 to map 
the glyphs)
Then I use my vectorizer to get the Flash font format.

The last step could be skiped in Rebol. And just the bitmaps could 
be used. So as in my Flash apps I can be sure, that the font will 
looks like I really want it!

But first we must have the R3 core stable and opened host sources. 
I will wait:)
shadwolf
9-Apr-2009
[13098]
but using font bitmap doesn't that will be slower than normal font 
/ text anti-aliased ?
Oldes
9-Apr-2009
[13099]
I think it could be faster if you bypass the fon't engine. At least 
I suppose that font engines are using bitmap caches to speed up the 
rendering anyway. But of course it should be used to render in the 
size for which the font is created.
shadwolf
9-Apr-2009
[13100]
the means you need to create a font for each use that's a pain no 
?
Oldes
9-Apr-2009
[13101]
How often do you change font in your text editor?
shadwolf
9-Apr-2009
[13102x5]
never
because to make it easier to handle the tete live motion we decided 
to fixe the size once for all
since that's do the makes the rest of the work more easy to grow
tete = text
and that's mainly because of a lack of a suitable fast way to determine 
size of a bunch of text (we can use a face dummi and sizetet to calculate 
but that not fast
Cyphre
9-Apr-2009
[13107]
Shadwolf, R3 have rich text dialect built in so it should be much 
easier to write RichTextEdit widget.
shadwolf
9-Apr-2009
[13108x5]
hum having the dialect doesn't' means you have teh proper low level 
set of drawing function to handle properly the text rendering
well i imagine that since the TDM (Text  Dialect Markup ) exists 
than AGG will follow and offer brand new things to handle conveniently 
the texte (and please please forget once for all about teh caret 
system please i beg you T___T)
what is in my opinion import in text handeling is to be able to get 
heigh and width taken be each letter or each set of letter (can be 
a word or a line ...
for example actually we are able to handle properly the text motion 
because we use fie font with a fixed size but this because what we 
want is to handle text in color and not mixe differnt kind of font 
styles and size like it would be the case for a MakeDoc format richtext 
rendering /editing widget
sure in our area-tc taht would be a plus to be able to handle ctrl+wheel 
action to grow shrink the text size (like you can do in any modern 
web browser for example) or to be able to set through a config panel 
the font size and type of your choice
Henrik
9-Apr-2009
[13113x3]
Solved the other bug by commenting out one line of code. :-)
do http://rebol.hmkdesign.dk/files/chat.r
If I can get a couple of confirmations that the bugs are gone, I'll 
submit them to curecode.
PeterWood
9-Apr-2009
[13116x2]
I haven't been able to generate the segfault with your version in 
the way that I could with the live version.
and the "more 3365" bug is gone too.
Henrik
9-Apr-2009
[13118x2]
Interesting. The changes are quite small.
actually, it could be because mine is not compressed.
PeterWood
9-Apr-2009
[13120]
That's a possibility. I'll try to compress your script tomorrow if 
I have time (it's late here) and see if it segfaults.
Nicolas
9-Apr-2009
[13121x3]
I'm trying to sort files by modification but it's not working.  sort/compare 
files: read %/c/ by-date: func [a b] [to-logic attempt [greater? 
modified? a modified? b]]
sort/compare files :by-date
does anyone use this type of code?
Henrik
9-Apr-2009
[13124]
What exactly does Pending mean in Curecode?
kcollins
9-Apr-2009
[13125x2]
Nicolas, sort/compare does not work in R3. This bug is in Curecode: 
 http://curecode.org/rebol3/ticket.rsp?id=161&cursor=8
It would be nice to see that one fixed, especially if it is easy 
to fix.
BrianH
9-Apr-2009
[13127]
Pending means someone (me, usually) has already written a fix and 
submitted it to DevBase, but it's not built into R3 yet.