Then we can remove the transparent color. Yuriy if you remove it you can also use versioner to make a new configurations for rubric and submit a bug report to integrate :)
Cheers, Andrei On Thu, Apr 30, 2015 at 5:25 PM, Alain Plantec <[email protected]> wrote: > > On 30 Apr 2015, at 16:16, Andrei Chis <[email protected]> wrote: > > Maybe Alain (in CC) can share some light on this :) > > > ah, strange behaviour and no original intent :) > thanks ! > > cheers > Alain > > > > Cheers, > Andrei > > On Thu, Apr 30, 2015 at 4:08 PM, Yuriy Tymchuk <[email protected]> > wrote: > >> I’d like to remove that, but I also want to communicate about what was >> the original intent. Because now before the styling takes place the text >> color is stored and set to transparent, and after the styling takes place >> the previous color is set. But if the styling is delayed because other >> processes are running - you end up with transparent text in your >> playground/inspector. >> >> Uko >> >> >> >> >> On 30 Apr 2015, at 16:04, Andrei Chis <[email protected]> wrote: >> >> No idea it that's a feature or not :) >> Feel free to remove it. >> >> >> On Thu, Apr 30, 2015 at 4:01 PM, Yuriy Tymchuk <[email protected]> >> wrote: >> >>> Ok, found the cause. By default the color of text is correctly set by >>> themer. But RubParagraphDecorator>>#next: sets the color to transparent >>> before the styling takes place. Does this make any sense? Because it’s >>> like: “you cannot see anything while I’m styling”. >>> >>> Uko >>> >>> On 30 Apr 2015, at 15:07, Yuriy Tymchuk <[email protected]> wrote: >>> >>> Oh, and one more snippet that blocks syntax highlight and puts you in >>> transparent text madness: >>> >>> GLMAsyncTask new >>> doInBackground: [ [ true ] whileTrue: [ ] ]; >>> execute >>> >>> Uko >>> >>> On 30 Apr 2015, at 15:02, Yuriy Tymchuk <[email protected]> wrote: >>> >>> Ok, I’ve manually tried to set the color to black for a >>> certain EditingArea and it works. Can anyone suggest me now can I put a >>> breakpoint that work on insVar access? Do I have to do something with slots? >>> >>> Uko >>> >>> P.S. I really don’t get why everyone is so ignorant… whole our team >>> suffers from not seeing text in rubric… >>> >>> On 28 Apr 2015, at 22:57, Yuriy Tymchuk <[email protected]> wrote: >>> >>> Look, the point is that if code styling is not happening, because higher >>> priority process is running, you can’t see what you are typing. There is a >>> cause for that. Also, is there a way disable styling? Just to see what >>> happens then? >>> >>> Uko >>> >>> >>> On 28 Apr 2015, at 22:50, Peter Uhnák <[email protected]> wrote: >>> >>> RubEditingArea allInstances collect: #textColor "{Color transparent. >>> Color transparent. Color transparent. Color transparent. Color black. Color >>> black. Color lightGray}" >>> >>> But I haven't seen any place that would be missing color. Maybe the >>> "EditingArea" color is not used in favor of selection/section color (or >>> whatever the name of it in rubric is)? >>> >>> Peter >>> >>> On Tue, Apr 28, 2015 at 10:31 PM, Yuriy Tymchuk <[email protected]> >>> wrote: >>> >>>> Guys, run please “RubEditingArea allInstances collect: #textColor”. >>>> Almost all rubric text areas have transparent text color. Is it something >>>> strange happening in my image, or you have the same? >>>> >>>> Uko >>>> >>>> >>>> >>>> On 20 Apr 2015, at 14:23, Peter Uhnák <[email protected]> wrote: >>>> >>>> This also happened to me several times when executing (do it and go) >>>> some Roassal example with error (=it opened debugger). However the >>>> occurrence is very inconsistent so I don't know what was the trigger. >>>> >>>> Peter >>>> >>>> On Mon, Apr 20, 2015 at 1:29 PM, Yuriy Tymchuk <[email protected]> >>>> wrote: >>>> >>>>> This was just an example. The question is how do I identify what is >>>>> blocking the highlighting. >>>>> >>>>> Uko >>>>> >>>>> >>>>> On 20 Apr 2015, at 12:19, Denis Kudriashov <[email protected]> >>>>> wrote: >>>>> >>>>> Hi >>>>> >>>>> Maybe highlighting is running in process with lesser priority than >>>>> default priority of #fork method. >>>>> >>>>> Code like "[ [ true ] whileTrue: [ ] ] fork" will block any processes >>>>> with lesser priority >>>>> >>>>> >>>>> 2015-04-20 12:51 GMT+03:00 Yuriy Tymchuk <[email protected]>: >>>>> >>>>>> Open a new pharo image (I’ve used latest 5, but on 4 it should work >>>>>> as well). Open playground and execute: >>>>>> >>>>>> [ [ true ] whileTrue: [ ] ] fork >>>>>> >>>>>> now open a new playground and start typing. Characters are invisible. >>>>>> Uko >>>>>> >>>>>> On 20 Apr 2015, at 11:14, Tudor Girba <[email protected]> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I did not see this before. Could you reproduce the issue? >>>>>> >>>>>> Cheers, >>>>>> Doru >>>>>> >>>>>> >>>>>> On Mon, Apr 20, 2015 at 11:03 AM, Yuriy Tymchuk <[email protected] >>>>>> > wrote: >>>>>> >>>>>>> Hi. >>>>>>> >>>>>>> Sometimes it happens that playground does not do the syntax >>>>>>> highlighting. This is especially frustrating when you open a new window >>>>>>> and >>>>>>> text is either white or transparent i.e. you cannot see what you are >>>>>>> typing. >>>>>>> >>>>>>> I guess this is because some process is blocked by another one. Is >>>>>>> there a way to check it? Because I want to understand whether it is >>>>>>> because >>>>>>> of me, or not. >>>>>>> >>>>>>> Cheers! >>>>>>> Uko >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> >>>>>> "Every thing has its own flow" >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >>> >>> >> >> > >
