It might be nice that we have some more paint rules in BitBlt. A "fuzz/blur" effect would be nice and take the load off the Squeak code for such things.
Just wanting to get more contemporary with the ui look without large performance penalties.
Not quite liking the way that effects are hidden behind canvas (leading to a bloated interface, perhaps (c.f. #drawImage... #drawTranslucentImage...)). Not sure where the balance should be. Looks like a choke-point that is too useful to bypass on a case-by-case basis.
Anyway, just a few thoughts.
Gary.
On Thu, Apr 17, 2008 at 5:15 AM, Gary Chambers gazzaguru2@btinternet.com wrote:
It might be nice that we have some more paint rules in BitBlt. A "fuzz/blur" effect would be nice and take the load off the Squeak code for such things.
Just wanting to get more contemporary with the ui look without large performance penalties.
Not quite liking the way that effects are hidden behind canvas (leading to a bloated interface, perhaps (c.f. #drawImage... #drawTranslucentImage...)). Not sure where the balance should be. Looks like a choke-point that is too useful to bypass on a case-by-case basis.
If you were to implement some more interesting effects in BitBLT, how would you make sure that Morphs that use this code will still work on other targets such as Rome, Postscript Canvases, VNC etc?
Gulik
2008/4/18 Michael van der Gulik mikevdg@gmail.com:
On Thu, Apr 17, 2008 at 5:15 AM, Gary Chambers gazzaguru2@btinternet.com wrote:
It might be nice that we have some more paint rules in BitBlt. A
"fuzz/blur"
effect would be nice and take the load off the Squeak code for such
things.
Just wanting to get more contemporary with the ui look without large performance penalties.
Not quite liking the way that effects are hidden behind canvas (leading to
a
bloated interface, perhaps (c.f. #drawImage... #drawTranslucentImage...)). Not sure where the balance should be. Looks like a choke-point that is too useful to bypass on a case-by-case basis.
If you were to implement some more interesting effects in BitBLT, how would you make sure that Morphs that use this code will still work on other targets such as Rome, Postscript Canvases, VNC etc?
1. BitBlt already contains many blitting rules which is problematic to support on different back ends. 2. In future, i suppose, we need a more functional approach how to define drawing operations. To describe a blitting/drawing operations with classes/objects not with integer numbers, like we currently have, which is meaningless and hard to determine how they working.
Drawing operation should be represented by object - a function(source, destination, arguments..), where function is fully reflected in language.
Gulik
-- http://people.squeakfoundation.org/person/mikevdg http://gulik.pbwiki.com/ _______________________________________________ UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
-----Original Message----- From: ui-bounces@lists.squeakfoundation.org [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Igor Stasenko Sent: 18 April 2008 7:32 AM To: Squeak's User Interface Subject: Re: [UI] Just a thought...
2008/4/18 Michael van der Gulik mikevdg@gmail.com:
On Thu, Apr 17, 2008 at 5:15 AM, Gary Chambers
wrote:
It might be nice that we have some more paint rules in BitBlt. A
"fuzz/blur"
effect would be nice and take the load off the Squeak code for such
things.
Just wanting to get more contemporary with the ui look without large performance penalties.
Not quite liking the way that effects are hidden behind
canvas (leading to
a
bloated interface, perhaps (c.f. #drawImage...
#drawTranslucentImage...)).
Not sure where the balance should be. Looks like a
choke-point that is too
useful to bypass on a case-by-case basis.
If you were to implement some more interesting effects in
BitBLT, how would
you make sure that Morphs that use this code will still work on other targets such as Rome, Postscript Canvases, VNC etc?
Would need to have fallback options for backends that do not directly support any new features. Sig, below, seems on the right track in terms of refactoring.
- BitBlt already contains many blitting rules which is problematic to
support on different back ends. 2. In future, i suppose, we need a more functional approach how to define drawing operations. To describe a blitting/drawing operations with classes/objects not with integer numbers, like we currently have, which is meaningless and hard to determine how they working.
Drawing operation should be represented by object - a function(source, destination, arguments..), where function is fully reflected in language.
Agree about the operation being properly represented *but* still need the extra performance of a backend (primitive) operation. People are complaining enough that Morhpic is slow...
Gulik
-- http://people.squeakfoundation.org/person/mikevdg http://gulik.pbwiki.com/ _______________________________________________ UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
Backwards compatability is always an issue, especially here. Wondering if we can really move things onwards now... -----Original Message----- From: ui-bounces@lists.squeakfoundation.org [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Michael van der Gulik Sent: 18 April 2008 4:44 AM To: Squeak's User Interface Subject: Re: [UI] Just a thought...
On Thu, Apr 17, 2008 at 5:15 AM, Gary Chambers gazzaguru2@btinternet.com wrote:
It might be nice that we have some more paint rules in BitBlt. A "fuzz/blur" effect would be nice and take the load off the Squeak code for such things.
Just wanting to get more contemporary with the ui look without large performance penalties.
Not quite liking the way that effects are hidden behind canvas (leading to a bloated interface, perhaps (c.f. #drawImage... #drawTranslucentImage...)). Not sure where the balance should be. Looks like a choke-point that is too useful to bypass on a case-by-case basis.
If you were to implement some more interesting effects in BitBLT, how would you make sure that Morphs that use this code will still work on other targets such as Rome, Postscript Canvases, VNC etc?
Gulik
-- http://people.squeakfoundation.org/person/mikevdg http://gulik.pbwiki.com/
i just discovered something which may be of you interest :) http://wiki.squeak.org/squeak/3269 See 'melt' filter. I think you can use it for smearing background
2008/4/19 Gary Chambers gazzaguru2@btinternet.com:
Backwards compatability is always an issue, especially here. Wondering if we can really move things onwards now...
-----Original Message----- From: ui-bounces@lists.squeakfoundation.org [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Michael van der Gulik Sent: 18 April 2008 4:44 AM To: Squeak's User Interface Subject: Re: [UI] Just a thought...
On Thu, Apr 17, 2008 at 5:15 AM, Gary Chambers gazzaguru2@btinternet.com wrote:
It might be nice that we have some more paint rules in BitBlt. A
"fuzz/blur"
effect would be nice and take the load off the Squeak code for such
things.
Just wanting to get more contemporary with the ui look without large performance penalties.
Not quite liking the way that effects are hidden behind canvas (leading to
a
bloated interface, perhaps (c.f. #drawImage... #drawTranslucentImage...)). Not sure where the balance should be. Looks like a choke-point that is too useful to bypass on a case-by-case basis.
If you were to implement some more interesting effects in BitBLT, how would you make sure that Morphs that use this code will still work on other targets such as Rome, Postscript Canvases, VNC etc?
Gulik
-- http://people.squeakfoundation.org/person/mikevdg http://gulik.pbwiki.com/ _______________________________________________ UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
Sorry Sig, thought I'd replied to this...
Appears to be juan's old work... Looks a bit heavyweight and not addressing translucency blending into a "destination".
Won't worry about it for now, FuzzyLabelMorph will do. :-)
Regards, Gary
-----Original Message----- From: ui-bounces@lists.squeakfoundation.org [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Igor Stasenko Sent: 24 April 2008 11:18 PM To: Squeak's User Interface Subject: Re: [UI] Just a thought...
i just discovered something which may be of you interest :) http://wiki.squeak.org/squeak/3269 See 'melt' filter. I think you can use it for smearing background
2008/4/19 Gary Chambers gazzaguru2@btinternet.com:
Backwards compatability is always an issue, especially here.
Wondering if we
can really move things onwards now...
-----Original Message----- From: ui-bounces@lists.squeakfoundation.org [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of
Michael van der
Gulik Sent: 18 April 2008 4:44 AM To: Squeak's User Interface Subject: Re: [UI] Just a thought...
On Thu, Apr 17, 2008 at 5:15 AM, Gary Chambers
wrote:
It might be nice that we have some more paint rules in BitBlt. A
"fuzz/blur"
effect would be nice and take the load off the Squeak code for such
things.
Just wanting to get more contemporary with the ui look without large performance penalties.
Not quite liking the way that effects are hidden behind
canvas (leading to
a
bloated interface, perhaps (c.f. #drawImage...
#drawTranslucentImage...)).
Not sure where the balance should be. Looks like a
choke-point that is too
useful to bypass on a case-by-case basis.
If you were to implement some more interesting effects in
BitBLT, how would
you make sure that Morphs that use this code will still work on other targets such as Rome, Postscript Canvases, VNC etc?
Gulik
-- http://people.squeakfoundation.org/person/mikevdg http://gulik.pbwiki.com/ _______________________________________________ UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
Gary asked on #Squeak IRC for other UI enhancement requests:
I have found it would be nice sometimes to be able to copy the complete line/lines of text from the upper pane of the debugger for such as pasting into an email asking for help with some problem or other. At the moment, the copy to paste buffer non-intuitively only gets the method name text. 'Copy text' gets way too much.
On Mac, doing cntl-click in the method pane of OB Package Browser, I see 'copy to paste buffer', but it does not appear to copy anything.
Also, couldn't that just be 'copy' in the menu?
Thx, Ken G. Brown
-
Gary Chambers -
Igor Stasenko -
Ken G. Brown -
Michael van der Gulik