February 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Question about Morphic

by Igor Stasenko

2009/2/22 Alexandre Bergel <alexandre(a)bergel.eu>: >> Canvas has the clipping capabilities. >> So, you can send a command to render a rectangle (-1000 @ -1000) >> corner: (10000 @10000) >> but depends on canvas clipping area, it will render only part of it. >> >> Also, for displaying morphs withing area with scrolling - use a >> TransformMorph to apply clipping & sroll in view. >> There are another morphs , ready for use , like ScrollPane > > I exactly use a ScrollBar. Here is a code excerpt: > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > | window pane | > window := SystemWindow labelled: 'Mondrian Canvas'. > window model: self. > window extent: 640 @ 480. > pane := ScrollPane new. > > canvas := MOCanvas on: self root. > pane scroller addMorph: canvas. > window > addMorph: pane > frame: (0 @ 0 corner: 1 @ 1). > window openInWorld. > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > MOCanvas is a subclass of Morph that is resized on some point. > > Apparently, this incantation does not activate this clipping. > Well, i'm not sure how to use ScrollPane properly.. look for examples of it in other morphs. > Alexandre > >> >> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Feb. 22, 2009

Re: [Pharo-project] Shadow in Watery2

by Gary Chambers

Yeah, the ordinary drop shadow was quite simple to implement. Hand-grabbed drop shadows are altogether much nastier! Not impossible but would require some evil hacking. Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Saturday, February 21, 2009 1:58 PM Subject: Re: [Pharo-project] Shadow in Watery2 > 2009/2/21 Marcus Denker <denker(a)iam.unibe.ch>: >> Gary, >> >> Watery2 looks better and better :-) Great! >> >> One question regarding the shadow: Now the active window has >> a translucent shadow (like macos), very nice. >> >> But it's turned off and replaced with the hard non-translucend >> Morphic shadow while moving the window. >> Would it be possible to render the same shadow, even wen picking >> up windows? This would result in a much smoother apperance, and I >> think it even would feel faster. >> > Good luck with that.. For shadow when picking up responds the hand morph.. > There is quite sophisticated logic which caching the morph appearance > when its in hand.. along with shadow. > I tried to reproduce this effect on my GLCanvas, but found it > impossible to do without support of render buffers extension :) > >> Marcus >> >> -- >> Marcus Denker -- denker(a)acm.org >> http://www.marcusdenker.de >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 22, 2009

Re: [Pharo-project] Question about Morphic

by Igor Stasenko

2009/2/22 Alexandre Bergel <alexandre(a)bergel.eu>: > Thanks to all of you for your prompt answer. > >> You could test before drawing if the shape is visible at all, however >> in my experience you do not gain any speed because the graphic engine >> is much faster at performing such tests. At some points I also >> experimented with R- and Generalized Search Trees, but I figured out >> that in most cases it is not worth the troubles. For Mondrian >> visualization the whole dataset is normally displayed anyway. These >> kind of trees only bring speed improvement, if typically only a >> fraction of a huge amount of data is visible, like this is the case in >> a game world or a CAD application. > > This is also what I would expect. But Apparently, displaying a lot of > nodes outside the window slow the whole thing down. > > I get this profiling: http://bergel.eu/Picture1.png > For this window being displayed: http://bergel.eu/Picture2.png > > I think I will try to the display boxes that I am sure they are > contained in the visible part of the window. The polymorph extension > seem to ease this. > you can test whether you drawing primitive is visible on the screen: canvas isVisible: aRectangle > Thanks again, > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Feb. 22, 2009

Re: [Pharo-project] Automatic focus on column upon moose enter

by Gary Chambers

Just to make clear... Polymorph introduced a MouseWheelEvent class, instances of which are generated from the HandMorph if the key combination matches what the VM currently passes (ctrl+up/down). These new events are handled based on mouse pointer location and not keyboard focus so providing mouse scrolling without disturbing the keyboard focus. Of course, should the VM's change to generate "proper" wheel events, much of Morphic handling is now already in place. So, with mouseClickForKeyboardFocus enabled the Gnome behaviour should apply, barring morphs deliberately changing keyboard focus without regard for that setting ;-) (which is where this all started...) Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Saturday, February 21, 2009 1:20 PM Subject: Re: [Pharo-project] Automatic focus on column upon moose enter > Gary, > > Of course :) You guys are doing a great job! I just replied to Sig, > emphasizing the Gnome/Windows split on scrolling based on cursor position > while leaving the focus alone. Gnome has it right. However, I would give > priority to consistent focus before worrying about sending the wheel input > where it belongs. Sounds like we need to add wheel events to the VM; then > it should be easy to handle both (control-up/down for older vms, and wheel > events doing exactly what is desired by the user). > > Bill > > > ---- > Wilhelm K. Schwab, Ph.D. > bschwab AT anest DOT ufl DOT edu > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr > [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Gary Chambers > [gazzaguru2(a)btinternet.com] > Sent: Saturday, February 21, 2009 8:02 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Automatic focus on column upon moose enter > > Which is handled in Polymorph of course. > > Regards, Gary > > ----- Original Message ----- > From: "Igor Stasenko" <siguctua(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Saturday, February 21, 2009 3:59 AM > Subject: Re: [Pharo-project] Automatic focus on column upon moose enter > > >> Concerning keyboard focus and mouse scroll. >> (sorry, if it was already noted in this discussion, i didn't read it >> fully). >> >> VM does not have a mouse wheel events. Instead, it generates ctrl-up / >> ctrl-down key combinations. >> I think that this hack is the root of all problems: >> - if focus doesn't following the mouse, you need additional hacks in >> image to treat ctrl-up / ctrl-down keys to generate scroll events for >> morph which is currently under the mouse, not the morph which is >> currently having an active keyboard input focus. >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 22, 2009

Re: [Pharo-project] Question about Morphic

by Alexandre Bergel

Thanks to all of you for your prompt answer. > You could test before drawing if the shape is visible at all, however > in my experience you do not gain any speed because the graphic engine > is much faster at performing such tests. At some points I also > experimented with R- and Generalized Search Trees, but I figured out > that in most cases it is not worth the troubles. For Mondrian > visualization the whole dataset is normally displayed anyway. These > kind of trees only bring speed improvement, if typically only a > fraction of a huge amount of data is visible, like this is the case in > a game world or a CAD application. This is also what I would expect. But Apparently, displaying a lot of nodes outside the window slow the whole thing down. I get this profiling: http://bergel.eu/Picture1.png For this window being displayed: http://bergel.eu/Picture2.png I think I will try to the display boxes that I am sure they are contained in the visible part of the window. The polymorph extension seem to ease this. Thanks again, Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 22, 2009

Re: [Pharo-project] Question about Morphic

by Alexandre Bergel

> Canvas has the clipping capabilities. > So, you can send a command to render a rectangle (-1000 @ -1000) > corner: (10000 @10000) > but depends on canvas clipping area, it will render only part of it. > > Also, for displaying morphs withing area with scrolling - use a > TransformMorph to apply clipping & sroll in view. > There are another morphs , ready for use , like ScrollPane I exactly use a ScrollBar. Here is a code excerpt: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | window pane | window := SystemWindow labelled: 'Mondrian Canvas'. window model: self. window extent: 640 @ 480. pane := ScrollPane new. canvas := MOCanvas on: self root. pane scroller addMorph: canvas. window addMorph: pane frame: (0 @ 0 corner: 1 @ 1). window openInWorld. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= MOCanvas is a subclass of Morph that is resized on some point. Apparently, this incantation does not activate this clipping. Alexandre > > >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 22, 2009

Re: [Pharo-project] Question about Morphic

by Lukas Renggli

> canvas being actually displayed. It simply try to render everything. > Is my guess right? Can anyone confirm please? > Is there a way to turn this on? In the original implementation whenever a shape was draw, all child shapes were clipped according to the bounds of the parent shape. So the root shape clipped to the bounds of the window. You could test before drawing if the shape is visible at all, however in my experience you do not gain any speed because the graphic engine is much faster at performing such tests. At some points I also experimented with R- and Generalized Search Trees, but I figured out that in most cases it is not worth the troubles. For Mondrian visualization the whole dataset is normally displayed anyway. These kind of trees only bring speed improvement, if typically only a fraction of a huge amount of data is visible, like this is the case in a game world or a CAD application. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 22, 2009

Re: [Pharo-project] Question about Morphic

by Igor Stasenko

2009/2/22 Alexandre Bergel <Alexandre.Bergel(a)inria.fr>: > Dear All, > > I know some of you are morphic expert :-) > I am still on the quest to make Mondrian usuable in Squeak/Pharo. The > situation is the following: I have a window having scrollbar, and I am > trying to render (using Balloon) something bigger than what the window > can actually display. Balloon seems to not be aware of the part of the > canvas being actually displayed. It simply try to render everything. > Is my guess right? Can anyone confirm please? > Is there a way to turn this on? > Canvas has the clipping capabilities. So, you can send a command to render a rectangle (-1000 @ -1000) corner: (10000 @10000) but depends on canvas clipping area, it will render only part of it. Also, for displaying morphs withing area with scrolling - use a TransformMorph to apply clipping & sroll in view. There are another morphs , ready for use , like ScrollPane > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Feb. 22, 2009

[Pharo-project] Question about Morphic

by Alexandre Bergel

Dear All, I know some of you are morphic expert :-) I am still on the quest to make Mondrian usuable in Squeak/Pharo. The situation is the following: I have a window having scrollbar, and I am trying to render (using Balloon) something bigger than what the window can actually display. Balloon seems to not be aware of the part of the canvas being actually displayed. It simply try to render everything. Is my guess right? Can anyone confirm please? Is there a way to turn this on? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 22, 2009

Re: [Pharo-project] [update] #10241

by StÃ©phane Ducasse

Adrian in 10241 when i did Smalltalk condenseChanges I got a ClassDescription syntax error on the license " use and modification subject to a liberal open source license. See the main Squeak website for details. Unless stated to the contrary, works submitted for incorporation into or for distribution with Squeak shall be presumed subject to the same license. Portions of Squeak are: Copyright Nothing more expected ->(c) 1996 Apple Computer, Inc. Copyright (c) 1997-2001 Walt Disney Company, and/or Copyrighted works of many other contributors. All rights reserved. ' " I think that fixing the condensing is the next key items since now we cannot work with Moose anymore. The changeset is getting too close to the limit. Stef On Feb 21, 2009, at 3:10 PM, Adrian Lienhard wrote: > #10241 > > Issue 167: > - Traits implementation refactoring (no sharing of compiled methods > and source) > - New tests for Traits MOP > > > Since this changes the handling of sources, the following issues with > condensing changes may be resolved: > http://code.google.com/p/pharo/issues/detail?id=466 > http://code.google.com/p/pharo/issues/detail?id=470 > > Can somebody check these issues? > > Adrian > ___________________ > http://www.adrian-lienhard.ch/ > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 22, 2009