debugging Display. need an advice.

how can i debug a rountines which responsible for updating portions on
the screen?

When i simply trying to set a breakpoint on method (like a
#forceDamageOnScreen), screen stops drawing/updating anything and i
cant see anything, and even cant reverse back to normal drawing..

Im curious , what techniques can be used to debug a DisplayScreen
class or its subclasses?

On Apr 21, 2007, at 11:30 , sig wrote:

> how can i debug a rountines which responsible for updating portions on
> the screen?
>
> When i simply trying to set a breakpoint on method (like a
> #forceDamageOnScreen), screen stops drawing/updating anything and i
> cant see anything, and even cant reverse back to normal drawing..
>
> Im curious , what techniques can be used to debug a DisplayScreen
> class or its subclasses?

self doOnlyOnce: [self halt]. "self rearmOneShot"

- Bert -

Hi Folks --

I'm writing a document about Etoys on the OLPC machine and would like
to include a page on Squeak (mentioning that it is lurking underneath
Etoys, etc.).

So I'm looking for really nice looking screenshots of the most
esthetically pleasing "looks" that people have come up with for the
general IDE, windowing system, etc. I think we should restrict it to
looks that are currently in use and available.

Can you give me some pointers?

Cheers,

Alan

There are some screenshots at http://wiki.squeak.org/squeak/3480

Sophie has a fairly nice looking UI - though I have to admit that I  
find a lot of the HUD/dialogues a bit *too* subdued even for my  
minimalist tastes. www.sophieproject.org . I'm sure that if some  
money were available to fund the work then a lot of the Sophie css &  
UI stuff could be generalised.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- His shared libraries aren't installed.

Hi Alan,

I love the FreeType work by Andy Tween and Henrik Gendenryd:
http://www.zen61439.zen.co.uk/lcdOn.png .
Please note that regular sub pixel rendering is not useful on the OLPC
machine, for the kind of display used.

Cheers,
Juan Vuletich

Alan Kay escribió:

Thanks Juan --

I like this one the best so far -- not so much
for the antialiased fonts or subpixel rendering
(though that is nice) but I like the flatter look
gradient-use better than the more "dimensional"
(as they would say at Disney) looks. The OLPC
display has a kind of sub-pixel rendering built
in (because one writes to the actual pixels not
to the color blobs) and this could be taken
advantage of even more (and probably will be as a
version of Cairo is being worked on for the machine).

Any more interesting Smalltalk methods in a browser with a look like this?

Cheers,

Alan

At 12:24 PM 4/21/2007, Juan Vuletich wrote:

I like my image look

http://onsmalltalk.com/wp-content/MyImage.jpg

Ramon Leon пишет: How can I do such look? Is there any how-to?

No, I manually patched a stock 3.9 image to look like that, but you can
download my image from my blog at http://onsmalltalk.com/my-squeak-image/

Ramon Leon
http://onsmalltalk.com

Oleg Korsak wrote:
> Ramon Leon пишет:
>  
>> I like my image look
>>
>> http://onsmalltalk.com/wp-content/MyImage.jpg
> How can I do such look? Is there any how-to?
>  
To me, this looks like a standard 3.9 with larger scrollbars
(scrollBarNarrow not enabled in Preferences) and square corners
(roundedWindowCorners not enabled.) No?

Brad Fuller wrote: oppss... except the corner window grabs. That's different (and the
fonts, of course, but I'm not counting that.)

--
brad fuller
www.bradfuller.com
+1 (408) 799-6124

Sort of, I was doing this in 3.8 before 3.9 adopted LookEnhancements and I
was giving input to the guy who built look enhancements when he first did
it.

It has larger scrollbars, 2px borders all around(manual hack), rounded
corners disabled, and win32 native fonts(installer blows up but you can hack
past it) using verdana 12pt normal most everywhere(also needed a hack to set
fonts), and a patch to monticello to not use toolbuilder.

If anyone's interested, the changesets I use are attached.

Ramon Leon
http://onsmalltalk.com

Ramon Leon wrote: showSplitterHandles also looks disabled.



--
brad fuller
www.bradfuller.com
+1 (408) 799-6124

> showSplitterHandles also looks disabled.

Yes, though that preference seems to have no effect in 3.9 in my image

I do too, but the fonts aren't antialiased.

Cheers,

Alan

At 04:33 PM 4/23/2007, Ramon Leon wrote:

On 23-Apr-07, at 7:13 PM, Alan Kay wrote:

> I do too, but the fonts aren't antialiased.

Set all fonts to BitStream Vera Serif, I use use 12 & 13 pt normal.  
Except for balloon help font which can be left tiny.
Turn off rounded corners for windows & menus.
alternative scrollbar look
alternative window boxes look
alternative window look
gradient scrollbars
inboard scrollbars
turn off scrollbars on right (scrollbars on the right; whoever came  
up with such a silly idea?)
scrollbars without menu button
textured window frame
gentle mid-blue to light blue gradient background

reopen all windows to get the effect.

Restful, clean, tidy.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
It said, "Insert disk #3," but only two will fit!

tim Rowledge wrote:
>
> On 23-Apr-07, at 7:13 PM, Alan Kay wrote:
>
>> I do too, but the fonts aren't antialiased.
>
> Set all fonts to BitStream Vera Serif, I use use 12 & 13 pt normal.
> Except for balloon help font which can be left tiny.
> Turn off rounded corners for windows & menus.
> alternative scrollbar look

I don't see this in preferences v3.9

> alternative window boxes look
> alternative window look

neither this.

> gradient scrollbars
> inboard scrollbars

nor this
> turn off scrollbars on right (scrollbars on the right; whoever came up
> with such a silly idea?)
> scrollbars without menu button
> textured window frame

nor this

> gentle mid-blue to light blue gradient background
>
> reopen all windows to get the effect.
>
> Restful, clean, tidy.
>
>


--
brad fuller
www.bradfuller.com
+1 (408) 799-6124

On 23-Apr-07, at 10:23 PM, Brad Fuller wrote:

Ah, I guess that must be because I simply haven't moved to 3.9 yet.  
Sophie is built form 3.8.1, which occupies just about all my time and  
the one occasion I tried to do serious work in 3.9 (for making a  
better source access system) I got bitten by traits being  
incompletely integrated and not easily intuitable.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Oxymorons: Temporary tax increase

Might have one for you soon, need to clear with my employers!
It is possible that many people won't like that amount of modifcations that
were
required (fixes/hacks) but it gives us a nicer environment in which to
develop our
business solutions.


-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Alan Kay
Sent: 21 April 2007 6:37 pm
To: The general-purpose Squeak developers list; The general-purpose Squeak
developers list
Subject: Nice Looking Squeak IDE's?


Hi Folks --

I'm writing a document about Etoys on the OLPC machine and would like
to include a page on Squeak (mentioning that it is lurking underneath
Etoys, etc.).

So I'm looking for really nice looking screenshots of the most
esthetically pleasing "looks" that people have come up with for the
general IDE, windowing system, etc. I think we should restrict it to
looks that are currently in use and available.

Can you give me some pointers?

Cheers,

Alan

On 26/04/07, Gary Chambers <[hidden email]> wrote:
> Might have one for you soon, need to clear with my employers!
> It is possible that many people won't like that amount of modifcations that
> were
> required (fixes/hacks) but it gives us a nicer environment in which to
> develop our
> business solutions.
>

There are already something that allows to change visual appearance of
UI - called themes. But i didnt learned them yet. I tried to play with
them, but all what i get - broken scrollbars. they start to draw at
right side of lists, ignoring list bounds.

Im not sure if basic morphs designed in such way, that you can change
their appearance easily.
I can tell how i would do things if i'm willing to customize my
controls appearance.
First, all UI morphs have some abstract state - like item collection
for lists or pushed/unpushed/disabled/e.t.c states.
There can be infinite number of ways how we can draw a list or button.
One way - is to hack the #drawOn: method of morph we interested in.
Yes, this will change its appearance but at same time we will loose
previous appearance.
To avoid this, i think it will be better to remove appearance
responsibility from UI morph, and  pass it to another object, lets
call it MorphAppearance.
Then, for most UI morphs the #drawOn: method may look like:

drawOn: aCanvas
| appr |
   self myAppearance ifNotNildo:[ :appr |  ^appr drawMorph: self on: aCanvas ]
...
 default draw (if appearance not found)
...

The #myAppearance method must return instance of MorphAppearance,
which is actually draws our morph. It can be taken from some global
dictionary, which holds currently used theme, set by user or something
else.. It can be categorized by morph class (its obvious, you don't
want to draw buttons and lists with same draw functions) or any other
way , not really matters.
The matter that in result we'll get a set of UI morphs which
appearance can be changed by few clicks in menu. And no more
hacks/changes in morphs code, because in most cases all we want to do
is to change its appearance. - If we need new cool looking button -
just create new appearance subclass then create new or modify existing
theme/style set and apply it to World.
Please note, im talking about appearance as a whole data+drawing
method, not just data.
These are colors, border widths, e.t.c - all this is _data_ which are
parts of morph state, but  they do not dictate how it will be
visualised. Different appearance methods may use this data along with
other properties of morph or can totally ignore some of them - like
draw rounded corners or straight, draw borders or not, draw gradients
or plain background.. anything we want.

Please, let me know if anything similar to what i described already
exists. Definitely, there is no need to reinvent the wheel. :)

P.S. btw, such approach will substantially clean the morphs code. For
instance , i'm really curios why Canvas decides how to draw corners by
receiving #roundCornersOf:during: message instead of morph itself.