Hi, I’ve implemented user configurable looks. However when
changing I noticed that the window that I changed the looks from didn’t
change its look completely. I then tried changing looks via the Settings Tool. Interestingly, when you change the look and click Accept,
the settings view doesn’t change to the new look, whilst all other views
appear to. So this appears to be an underlying problem. Has anyone noticed this and is there a workaround? TIA, Stewart |
For “automatic” updating when the look changes, an ApplicationModel must implement this:
windowEvent: anEvent from: aWindow super windowEvent: anEvent from: aWindow. (#(#newGraphicsDevice #reopen) includes: anEvent key) ifTrue: [self reInstallInterface].
And of course you have to hand-write your own #reInstallInterface – look at existing implementers for hints. It’s not too bad – basically selected parts from ApplicationModel>>openInterface:withPolicy:inSession:.
The Settings tool doesn’t update itself (by design, I think). The RB and a few other basic tools do update, but by no means all tools.
Steve
-----Original Message-----
Hi,
I’ve implemented user configurable looks. However when changing I noticed that the window that I changed the looks from didn’t change its look completely.
I then tried changing looks via the Settings Tool.
Interestingly, when you change the look and click Accept, the settings view doesn’t change to the new look, whilst all other views appear to.
So this appears to be an underlying problem.
Has anyone noticed this and is there a workaround?
TIA,
Stewart |
Steven Kelly wrote:
> For “automatic” updating when the look changes, an ApplicationModel must > implement this: > > > > windowEvent: anEvent from: aWindow > > super windowEvent: anEvent from: aWindow. > > (#(#newGraphicsDevice #reopen) includes: anEvent key) > > ifTrue: [self reInstallInterface]. > > > > And of course you have to hand-write your own #reInstallInterface – look > at existing implementers for hints. It’s not too bad – basically > selected parts from ApplicationModel>>openInterface:withPolicy:inSession:. > > > The Settings tool doesn’t update itself (by design, I think). The RB and > a few other basic tools do update, but by no means all tools. > Couldn't help chiming in, but will Pollock address this at all? It seems odd that such an abstract thing as a "look" of an emulated UI can't be changed on the fly easily without developer intervention, doesn't it? Cheers! -Boris |
> Couldn't help chiming in, but will Pollock address this at all? It seems > odd that such an abstract thing as a "look" of an emulated UI can't be > changed on the fly easily without developer intervention, doesn't it? Yes, this is something Pollock does much more naturally. It has an 'artist' instance variable on each pane that can be hot-swapped any time. Each Look and Feel is implemented as a set of Artist's that get set when a Pane is created. To change the Look and Feel, it traverses the pane's and pokes in a more appropriate Artist for each widget on the fly. The only developer intervention that is required is if you make your own new kind of Pane, you'll have to be aware of this pattern and implement it correctly. Cheers, Michael > Cheers! > -Boris |
In reply to this post by Steven Kelly
Hi Steve, After a bit of experimentation I’ve
got this working fine. Thanks for the pointer. Cheers, Stewart -----Original Message----- For “automatic”
updating when the look changes, an ApplicationModel must implement this: windowEvent: anEvent from:
aWindow
super windowEvent: anEvent from: aWindow.
(#(#newGraphicsDevice #reopen) includes: anEvent key)
ifTrue: [self reInstallInterface]. And of course you have to
hand-write your own #reInstallInterface – look at existing implementers
for hints. It’s not too bad – basically selected parts from
ApplicationModel>>openInterface:withPolicy:inSession:. The Settings tool
doesn’t update itself (by design, I think). The RB and a few other basic
tools do update, but by no means all tools. Steve -----Original Message----- Hi, I’ve implemented user configurable looks. However when
changing I noticed that the window that I changed the looks from didn’t
change its look completely. I then tried changing looks via the Settings Tool. Interestingly, when you change the look and click Accept,
the settings view doesn’t change to the new look, whilst all other views
appear to. So this appears to be an underlying problem. Has anyone noticed this and is there a workaround? TIA, Stewart |
In reply to this post by Boris Popov-4
Boris,
>Couldn't help chiming in, but will Pollock address this at all? It seems >odd that such an abstract thing as a "look" of an emulated UI can't be >changed on the fly easily without developer intervention, doesn't it? Pollock will address this completely! In Pollock all panes know how to change their look dynamically whenever the look changes. No user code is required. None. Not one line. Pollock handles it automagically. And So It Goes Sames ______________________________________________________________________ Samuel S. Shuster [|] VisualWorks Engineering, GUI Project Smalltalk Enables Success -- What Are YOU Using? |
I've looked pretty carefully but I can't seem to find out how to draw
graphics using the XOR rule. -Carl Gundel, author of Liberty BASIC http://www.libertybasic.com |
I didn't find it on Windows either. XOR painting is needed for selection
tracking (inversion). The only workaround I could figure out is to redraw the whole object plus the selection background each time the selection position is changed, which is not very performant. Andre Carl Gundel wrote: > I've looked pretty carefully but I can't seem to find out how to draw > graphics using the XOR rule. > > -Carl Gundel, author of Liberty BASIC > http://www.libertybasic.com > > > |
In reply to this post by Samuel S. Shuster <sames@interaccess.com>
Hi Sames,
I'm glad to hear this - after I thought I had got it going as Steve outlined, I ran into problems when restarting the image. This was as a result of the hooked window event calling my reinstallation routine on start up - which fell over as I was attempting to capture the UI state before it was fully initialised. Simple things should be easy, hard things should be possible! Cheers, Stewart >-----Original Message----- >From: [hidden email] [mailto:[hidden email]] >Sent: Sunday, 4 June 2006 1:41 a.m. >To: Boris Popov >Cc: Steven Kelly; Stewart MacLean; [hidden email] >Subject: Re: [VW7.4] [Bug] Changing Look doesn't change look of Settings >View > >Boris, > >>Couldn't help chiming in, but will Pollock address this at all? It seems >>odd that such an abstract thing as a "look" of an emulated UI can't be >>changed on the fly easily without developer intervention, doesn't it? > >Pollock will address this completely! > >In Pollock all panes know how to change their look dynamically whenever the >look >changes. No user code is required. None. Not one line. Pollock handles it >automagically. > > And So It Goes > Sames >______________________________________________________________________ > >Samuel S. Shuster [|] >VisualWorks Engineering, GUI Project >Smalltalk Enables Success -- What Are YOU Using? |
In reply to this post by Andre Schnoor
Andre Schnoor,
>I didn't find it on Windows either. XOR painting is needed for selection >tracking (inversion). The only workaround I could figure out is to >redraw the whole object plus the selection background each time the >selection position is changed, which is not very performant. RasterOp class And So It Goes Sames ______________________________________________________________________ Samuel S. Shuster [|] VisualWorks Engineering, GUI Project Smalltalk Enables Success -- What Are YOU Using? |
In reply to this post by Carl Gundel
Carl,
>I've looked pretty carefully but I can't seem to find out how to draw >graphics using the XOR rule. XOR or other BitBlt drawing isn't Pollock specific. RasterOp is the class you want to look at. And So It Goes Sames ______________________________________________________________________ Samuel S. Shuster [|] VisualWorks Engineering, GUI Project Smalltalk Enables Success -- What Are YOU Using? |
...... Original Message .......
On Sun, 04 Jun 2006 13:37:53 -0500 Samuel S. Shuster <[hidden email]> wrote: >Carl, > >>I've looked pretty carefully but I can't seem to find out how to draw >>graphics using the XOR rule. > >XOR or other BitBlt drawing isn't Pollock specific. Yeah, but since I am trying to do this in my Pollock app I figured it should be made known in case it mattered. >RasterOp is the class you want to look at. Thanks. BTW, welcome back! How was your trip? :-) -Carl Gundel, author of Liberty BASIC http://www.libertybasic.com |
Carl,
> BTW, welcome back! How was your trip? :-) The trip was great. London was just plain fun. Scotland was just beautiful. Paris was pretty. St. Albens was a day of bucolic peace. And yes, I do have a picture of myself crossing Abbey Road :) And So It Goes Sames ______________________________________________________________________ Samuel S. Shuster [|] VisualWorks Engineering, GUI Project Smalltalk Enables Success -- What Are YOU Using? |
Free forum by Nabble | Edit this page |