World: r3wp
[!REBOL3-OLD1]
older newer | first last |
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. |
older newer | first last |