Status of Morphic?
Locked
 
|
I've been testing some of my code after migrating to the local
coordinate system and am running into a few things: 1) Morph stepping appears to be non-functional (at least in terms of running the code as-is from Cuis 4.0) 2) Halos are behaving badly on occasion... drawing artifacts, problems resizing, experiencing the odd image crash here and there. 3) Specifically related to OpenGL support code, it wants to get the global coordinates of the morph before the morph is actually displayed to set up the OpenGL view. However, morphBoundsInWorld returns nil if the morph has not been opened... is this still possible via a different method perhaps? Overall, I'm pleasantly surprised that things are working as well as they are given the minimal amount of rework I've had to do so far given how significant the changes under the hood are. I just wanted to see if any of these items are already known issues / are already being worked on or if I should start digging in to either try to help fix and/or report bugs via github? Thanks, Phil _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
On Mon, 2015-03-09 at 05:54 -0400, Phil (list) wrote:
> 1) Morph stepping appears to be non-functional (at least in terms of > running the code as-is from Cuis 4.0) Figured this one out... #step appears to be obsolete, use #stepAt: instead. In some cases now need to override #wantsSteps to return true (the default implementation now always returns false. This is an issue only for some of my animated morphs.) _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
Created https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/48 for this.
On 3/9/15, Phil (list) <[hidden email]> wrote: > On Mon, 2015-03-09 at 05:54 -0400, Phil (list) wrote: >> 1) Morph stepping appears to be non-functional (at least in terms of >> running the code as-is from Cuis 4.0) > > Figured this one out... #step appears to be obsolete, use #stepAt: > instead. In some cases now need to override #wantsSteps to return true > (the default implementation now always returns false. This is an issue > only for some of my animated morphs.) > > > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
Phil,
could you please provide an example code snippet (Morph class). Version 4.0 vs Version 4.2 ? On 3/10/15, H. Hirzel <[hidden email]> wrote: > Created https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/48 for > this. > > On 3/9/15, Phil (list) <[hidden email]> wrote: >> On Mon, 2015-03-09 at 05:54 -0400, Phil (list) wrote: >>> 1) Morph stepping appears to be non-functional (at least in terms of >>> running the code as-is from Cuis 4.0) >> >> Figured this one out... #step appears to be obsolete, use #stepAt: >> instead. In some cases now need to override #wantsSteps to return true >> (the default implementation now always returns false. This is an issue >> only for some of my animated morphs.) >> >> >> >> _______________________________________________ >> Cuis mailing list >> [hidden email] >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >> > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
Hannes,
On Tue, 2015-03-10 at 06:56 +0000, H. Hirzel wrote: > Phil, > > could you please provide an example code snippet (Morph class). > > Version 4.0 > vs > Version 4.2 > ? > Will do (I'll add details to the issue referenced previously)... I just need to spend a bit more time trying to understand when #wantsSteps is needed so that hopefully the snippet accurately reflects what I'm seeing. > On 3/10/15, H. Hirzel <[hidden email]> wrote: > > Created https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/48 for > > this. > > > > On 3/9/15, Phil (list) <[hidden email]> wrote: > >> On Mon, 2015-03-09 at 05:54 -0400, Phil (list) wrote: > >>> 1) Morph stepping appears to be non-functional (at least in terms of > >>> running the code as-is from Cuis 4.0) > >> > >> Figured this one out... #step appears to be obsolete, use #stepAt: > >> instead. In some cases now need to override #wantsSteps to return true > >> (the default implementation now always returns false. This is an issue > >> only for some of my animated morphs.) > >> > >> > >> > >> _______________________________________________ > >> Cuis mailing list > >> [hidden email] > >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > >> > > > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by Phil B
Hi Phil,
(inline) On 3/9/2015 6:54 AM, Phil (list) wrote: > I've been testing some of my code after migrating to the local > coordinate system and am running into a few things: > > 1) Morph stepping appears to be non-functional (at least in terms of > running the code as-is from Cuis 4.0) You already found #stepAt: . In any case, the "message names" tool is your friend. > 2) Halos are behaving badly on occasion... drawing artifacts, problems > resizing, experiencing the odd image crash here and there. Please, steps to reproduce. > 3) Specifically related to OpenGL support code, it wants to get the > global coordinates of the morph before the morph is actually displayed > to set up the OpenGL view. However, morphBoundsInWorld returns nil if > the morph has not been opened... is this still possible via a different > method perhaps? Well, until the morph is inside some owner, its coordinates are meaningless. This is different from Squeak, I know. And it might require a bit more of thought. I had to fix many places where coordinates were set before adding the morph to some owner... If you can send me an image with preloaded code, or rather specific instructions to build one, I'd like to think about this together with you. It is quite likely that we tweak something or add some helpers to Cuis base. > Overall, I'm pleasantly surprised that things are working as well as > they are given the minimal amount of rework I've had to do so far given > how significant the changes under the hood are. I just wanted to see if > any of these items are already known issues / are already being worked > on or if I should start digging in to either try to help fix and/or > report bugs via github? > > Thanks, > Phil Bug reports are most welcome. But (as in 3) if the problem is that you don't find the "obvious" way to do something, then working together on the code will most likely give all us better results. Cheers, Juan Vletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
On Tue, 2015-03-10 at 10:37 -0300, Juan Vuletich wrote:
> Hi Phil, > > (inline) > On 3/9/2015 6:54 AM, Phil (list) wrote: > > I've been testing some of my code after migrating to the local > > coordinate system and am running into a few things: > > > > 1) Morph stepping appears to be non-functional (at least in terms of > > running the code as-is from Cuis 4.0) > > You already found #stepAt: . In any case, the "message names" tool is > your friend. > As was FrameRateMorph. > > 2) Halos are behaving badly on occasion... drawing artifacts, problems > > resizing, experiencing the odd image crash here and there. > > Please, steps to reproduce. > Working on narrowing down. > > 3) Specifically related to OpenGL support code, it wants to get the > > global coordinates of the morph before the morph is actually displayed > > to set up the OpenGL view. However, morphBoundsInWorld returns nil if > > the morph has not been opened... is this still possible via a different > > method perhaps? > > Well, until the morph is inside some owner, its coordinates are > meaningless. This is different from Squeak, I know. And it might require > a bit more of thought. I had to fix many places where coordinates were > set before adding the morph to some owner... > > If you can send me an image with preloaded code, or rather specific > instructions to build one, I'd like to think about this together with > you. It is quite likely that we tweak something or add some helpers to > Cuis base. > I suspected that might be the case... I'll need to rework the OpenGL / Morphic integration code. This is an issue specific to OpenGL which needs to fake integration of a hardware-backed view in the Squeak environment so I'm not sure it warrants doing much on the Cuis side as it can probably be worked around. IIRC, the issue is that the code this is based on sizes the OpenGL view to fit in a Morph rather than wrapping the Morph around the OpenGL view. Logically simple and it will just take some work to flip it around. > > Overall, I'm pleasantly surprised that things are working as well as > > they are given the minimal amount of rework I've had to do so far given > > how significant the changes under the hood are. I just wanted to see if > > any of these items are already known issues / are already being worked > > on or if I should start digging in to either try to help fix and/or > > report bugs via github? > > > > Thanks, > > Phil > > Bug reports are most welcome. But (as in 3) if the problem is that you > don't find the "obvious" way to do something, then working together on > the code will most likely give all us better results. > Fair enough, I just thought I'd ask about these specific issues to see if I was missing anything obvious first. > Cheers, > Juan Vletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
An old issue with some new info...
On Tue, 2015-03-10 at 15:11 -0400, Phil (list) wrote: > On Tue, 2015-03-10 at 10:37 -0300, Juan Vuletich wrote: > > Hi Phil, > > > > (inline) > > On 3/9/2015 6:54 AM, Phil (list) wrote: > > > I've been testing some of my code after migrating to the local > > > coordinate system and am running into a few things: > > > > > > 1) Morph stepping appears to be non-functional (at least in terms of > > > running the code as-is from Cuis 4.0) > > > > You already found #stepAt: . In any case, the "message names" tool is > > your friend. > > > > As was FrameRateMorph. > > > > 2) Halos are behaving badly on occasion... drawing artifacts, problems > > > resizing, experiencing the odd image crash here and there. > > > > Please, steps to reproduce. > > > > Working on narrowing down. At least the drawing artifacts issue doesn't appear to be Halo specific. I've been seeing it on occasion with other kinds of Morphs. Today it finally dawned on me what is going on: Morphs are drawing outside of their bounds. I think I have a reproducible scenario: in the Workspace type ReparseAfterSourceEditing, select and right click->Smalltalk Options->Method Source with it. On my computer, the default window size results in the title text being drawn well outside of the Morph so there's no mistaking what's going on. Drag the window around and notice the artifacts. I think Halos and other Morphs are doing the same thing though less obviously. _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
Not sure if this is related but InspectorWindow does not cut off the text in the title bar of the window eagerly enough. Take an inspector whose title is too long for the window and see how the text is cut off mid-character at the right border of the window. Move the window around and it leaves a trail, exactly where the character pixels touch the side. BTW, the devoweling of inspector titles I strongly dislike. If that could be taken out, great. Or perhaps someone has real good use for that? Thanks, Peter On Tue, Jun 30, 2015 at 3:27 AM, Phil (list) <[hidden email]> wrote: An old issue with some new info... _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
On Wed, 2015-07-01 at 22:20 +0200, Peter van Rooijen wrote:
> Not sure if this is related but InspectorWindow does not cut > off the text in the title bar of the window eagerly enough. > That's exactly the issue I'm referring to (though it is larger in scope than just title bars.) > > Take an inspector whose title is too long for the window > and see how the text is cut off mid-character at the right > border of the window. Move the window around and it leaves > a trail, exactly where the character pixels touch the side. > Yup. > > BTW, the devoweling of inspector titles I strongly dislike. > If that could be taken out, great. Or perhaps someone has > real good use for that? > I'm not wild about it either but in many cases I think it is probably better than just truncating the string. I think that's one of those things where a better approach would be nice but so far no one has come up with one... > > Thanks, Peter > > On Tue, Jun 30, 2015 at 3:27 AM, Phil (list) <[hidden email]> > wrote: > An old issue with some new info... > > On Tue, 2015-03-10 at 15:11 -0400, Phil (list) wrote: > > On Tue, 2015-03-10 at 10:37 -0300, Juan Vuletich wrote: > > > Hi Phil, > > > > > > (inline) > > > On 3/9/2015 6:54 AM, Phil (list) wrote: > > > > I've been testing some of my code after migrating to the > local > > > > coordinate system and am running into a few things: > > > > > > > > 1) Morph stepping appears to be non-functional (at least > in terms of > > > > running the code as-is from Cuis 4.0) > > > > > > You already found #stepAt: . In any case, the "message > names" tool is > > > your friend. > > > > > > > As was FrameRateMorph. > > > > > > 2) Halos are behaving badly on occasion... drawing > artifacts, problems > > > > resizing, experiencing the odd image crash here and > there. > > > > > > Please, steps to reproduce. > > > > > > > Working on narrowing down. > > At least the drawing artifacts issue doesn't appear to be Halo > specific. > I've been seeing it on occasion with other kinds of Morphs. > Today it > finally dawned on me what is going on: Morphs are drawing > outside of > their bounds. I think I have a reproducible scenario: in the > Workspace > type ReparseAfterSourceEditing, select and right > click->Smalltalk > Options->Method Source with it. On my computer, the default > window size > results in the title text being drawn well outside of the > Morph so > there's no mistaking what's going on. Drag the window around > and notice > the artifacts. I think Halos and other Morphs are doing the > same thing > though less obviously. > > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
On Wed, 01 Jul 2015 16:30:01 -0400
"Phil (list)" <[hidden email]> wrote: > > BTW, the devoweling of inspector titles I strongly dislike. > > If that could be taken out, great. Or perhaps someone has > > real good use for that? > > I'm not wild about it either but in many cases I think it is probably > better than just truncating the string. I think that's one of those > things where a better approach would be nice but so far no one has come > up with one... I find it much more helpful than truncated strings. FYI, -KenD _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
|
|
On 1 Jul 2015 at 13:35, Ken.Dickey wrote:
> On Wed, 01 Jul 2015 16:30:01 -0400 > "Phil (list)" <[hidden email]> wrote: > > > > BTW, the devoweling of inspector titles I strongly dislike. > > > If that could be taken out, great. Or perhaps someone has > > > real good use for that? > > > > I'm not wild about it either but in many cases I think it is > probably > > better than just truncating the string. I think that's one of > those > > things where a better approach would be nice but so far no one has > come > > up with one... > > I find it much more helpful than truncated strings. > > FYI, > -KenD > +1 Best regards, - Dan _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by Hannes Hirzel
Hannes,
Sorry for the delay... it's taken me longer than expected to get back to it. I really don't have any simple examples of porting as my stuff is fairly involved (i.e. drawing and keyboard handling as part of a larger OpenGL project etc.) However, I do have more specifics re: what needed to be done. On Tue, 2015-03-10 at 06:56 +0000, H. Hirzel wrote: > Phil, > > could you please provide an example code snippet (Morph class). > > Version 4.0 > vs > Version 4.2 > ? > > On 3/10/15, H. Hirzel <[hidden email]> wrote: > > Created https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/48 for > > this. > > > > On 3/9/15, Phil (list) <[hidden email]> wrote: > >> On Mon, 2015-03-09 at 05:54 -0400, Phil (list) wrote: > >>> 1) Morph stepping appears to be non-functional (at least in terms of > >>> running the code as-is from Cuis 4.0) > >> > >> Figured this one out... #step appears to be obsolete, use #stepAt: > >> instead. In some cases now need to override #wantsSteps to return true > >> (the default implementation now always returns false. This is an issue > >> only for some of my animated morphs.) > >> Morphic (continuous) animation previously: #step now: #stepAt: (just rename #step to #stepAt: milliseconds) #wantsSteps (^true) Notes: 1) If this change isn't made, you may get what appears to be animation, but it's just the morph redrawing after damage. 2) Be sure to call #truncate on bounds etc. if your code can't handle floats. 3) I used to have several direct Morph subclasses, but it appears that they now need to be RectangleLikeMorph subclasses to maintain similar behavior. Keyboard focus handling previously: #handlesKeyboard (^ true) #keyboardFocusChange: (call any code needed to deal with getting/losing focus such as drawing a focus indicator) #handleKeystroke: (when morph has focus, will receive keystroke) now: This is my best guess... are there any examples of working Morphs that deal with keyboard focus but do *not* have text morphs? #handlesKeyboard (no change) #handlesMouseOver: (^true to get #mouseEnter: & #mouseLeave:) #mouseEnter: event event hand newKeyboardFocus: self #mouseLeave: event event hand newKeyboardFocus: nil #keyStroke: event (receives the keystroke when focused, some event accessors no longer exist) Thanks, Phil _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
On Mon, 2015-07-06 at 04:01 -0400, Phil (list) wrote:
> Hannes, > > Sorry for the delay... it's taken me longer than expected to get back to > it. I really don't have any simple examples of porting as my stuff is > fairly involved (i.e. drawing and keyboard handling as part of a larger > OpenGL project etc.) However, I do have more specifics re: what needed > to be done. > <snip> > > Keyboard focus handling > One additional thing related to keyboard focus that should probably be handled by Morphic: various mouse (mouse wheel) and trackpad (gesture) events get sent as keyboard events and should probably be (at least optionally?) intercepted from the event stream and sent as distinct events such as #scroll: etc. No idea how multi-finger touch screen gestures are handled by the VM these days but that is yet something else to think about... > > Thanks, > Phil _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
Phil,
thank you for answering three months later. That is fine, I'd like to distill from our conversation some upgrade notes from Cuis Morphic 4.0 to Cuis Morphic 4.2. I created an issue for this for the documentation of Cuis https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/65 Quite a number of issues are piled up there and I want to work on them in batch mode in one go sometime in the upcoming months. So if this thread goes to sleep for three more months I do not have any problem with it ... :-) The documentation of course is related to the issue of having release version numbers you can refer to. Ideally we have release notes from time to time which list the changes and test reports which packages work with which release. --Hannes On 7/6/15, Phil (list) <[hidden email]> wrote: > On Mon, 2015-07-06 at 04:01 -0400, Phil (list) wrote: >> Hannes, >> >> Sorry for the delay... it's taken me longer than expected to get back to >> it. I really don't have any simple examples of porting as my stuff is >> fairly involved (i.e. drawing and keyboard handling as part of a larger >> OpenGL project etc.) However, I do have more specifics re: what needed >> to be done. >> > <snip> >> >> Keyboard focus handling >> > > One additional thing related to keyboard focus that should probably be > handled by Morphic: various mouse (mouse wheel) and trackpad (gesture) > events get sent as keyboard events and should probably be (at least > optionally?) intercepted from the event stream and sent as distinct > events such as #scroll: etc. No idea how multi-finger touch screen > gestures are handled by the VM these days but that is yet something else > to think about... > >> >> Thanks, >> Phil > > > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
On Mon, 2015-07-06 at 15:00 +0000, H. Hirzel wrote:
> Phil, > > thank you for answering three months later. That is fine, I'd like to > distill from our conversation some upgrade notes from Cuis Morphic 4.0 > to Cuis Morphic 4.2. > Apologies for taking so long... I figured better late than never. > I created an issue for this for the documentation of Cuis > > https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/65 > > Quite a number of issues are piled up there and I want to work on them > in batch mode in one go sometime in the upcoming months. > > So if this thread goes to sleep for three more months I do not have > any problem with it ... > > :-) > I'll try to stop being such a troublemaker... (promises, promises :-) > > The documentation of course is related to the issue of having release > version numbers you can refer to. > Ah, now I understand why you're asking for version #'s/tags/something. > > Ideally we have release notes from time to time which list the changes > and test reports which packages work with which release. > The reporting part sounds like Continuous Integration testing to me... > --Hannes > > On 7/6/15, Phil (list) <[hidden email]> wrote: > > On Mon, 2015-07-06 at 04:01 -0400, Phil (list) wrote: > >> Hannes, > >> > >> Sorry for the delay... it's taken me longer than expected to get back to > >> it. I really don't have any simple examples of porting as my stuff is > >> fairly involved (i.e. drawing and keyboard handling as part of a larger > >> OpenGL project etc.) However, I do have more specifics re: what needed > >> to be done. > >> > > <snip> > >> > >> Keyboard focus handling > >> > > > > One additional thing related to keyboard focus that should probably be > > handled by Morphic: various mouse (mouse wheel) and trackpad (gesture) > > events get sent as keyboard events and should probably be (at least > > optionally?) intercepted from the event stream and sent as distinct > > events such as #scroll: etc. No idea how multi-finger touch screen > > gestures are handled by the VM these days but that is yet something else > > to think about... > > > >> > >> Thanks, > >> Phil > > > > > > > > _______________________________________________ > > Cuis mailing list > > [hidden email] > > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
«
Return to Cuis Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |