Re: [Pharo-project] UIManager
On 06.12.2011 11:46, Henrik Sperre Johansen wrote:
Is it just me, or is UIManager gradually turning into a new SystemDictionary/Project?
Cheers, Henry And by that I mean equivalent to those classes in purity of purpose and simplicity; UIManager used to have a clear purpose - Provide a polymorphic interface for accessing common GUI dialogs for code which doesn't care which GUI framework is in use.
Right now, MorphicUIMananger also has methods for - Component building (a poor mans ToolBuilder, basically) - Global state accessor, not polymorphic (world and uiProcess handling ) - Debugger components building (!) - Accessing common Smalltalk tools (not necessarily a bad thing, but shouldn't that be the responsibility of ToolRegistry? IE a UIManager should install a proper ToolRegistry when activated, not provide an extra layer of indirection you HAVE to use if you say, want your app to work headlessly) - something called interactiveParserFor: I have no idea what means. - etc. etc. etc. Cheers, Henry
On Dec 6, 2011, at 12:30 PM, Henrik Sperre Johansen wrote:
On 06.12.2011 11:46, Henrik Sperre Johansen wrote:
Is it just me, or is UIManager gradually turning into a new SystemDictionary/Project?
Cheers, Henry And by that I mean equivalent to those classes in purity of purpose and simplicity; UIManager used to have a clear purpose - Provide a polymorphic interface for accessing common GUI dialogs for code which doesn't care which GUI framework is in use.
Right now, MorphicUIMananger also has methods for - Component building (a poor mans ToolBuilder, basically) - Global state accessor, not polymorphic (world and uiProcess handling )
- Debugger components building (!) yes I already filled in a issue on that
- Accessing common Smalltalk tools (not necessarily a bad thing, but shouldn't that be the responsibility of ToolRegistry? IE a UIManager should install a proper ToolRegistry when activated, not provide an extra layer of indirection you HAVE to use if you say, want your app to work headlessly) - something called interactiveParserFor: I have no idea what means. - etc. etc. etc.
If you have some proposal I'm all ears. Now I just do not have time for it.
Cheers, Henry
On Tue, Dec 6, 2011 at 12:30 PM, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
On 06.12.2011 11:46, Henrik Sperre Johansen wrote:
Is it just me, or is UIManager gradually turning into a new SystemDictionary/Project?
Cheers, Henry
And by that I mean equivalent to those classes in purity of purpose and simplicity; UIManager used to have a clear purpose - Provide a polymorphic interface for accessing common GUI dialogs for code which doesn't care which GUI framework is in use.
Right now, MorphicUIMananger also has methods for - Component building (a poor mans ToolBuilder, basically) - Â Global state accessor, not polymorphic (world and uiProcess handling ) - Debugger components building (!) - Accessing common Smalltalk tools (not necessarily a bad thing, but shouldn't that be the responsibility of ToolRegistry? IE a UIManager should install a proper ToolRegistry when activated, not provide an extra layer of indirection you HAVE to use if you say, want your app to work headlessly) - something called interactiveParserFor: I have no idea what means.
this method resolves if the UIManager is able to process questions from the parser/compiler on user (like warnings about unimplemented callss, undeclared instance variables etc.). -- Pavel
- etc. etc. etc.
Cheers, Henry
On 06.12.2011 18:42, Pavel Krivanek wrote:
On Tue, Dec 6, 2011 at 12:30 PM, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
On 06.12.2011 11:46, Henrik Sperre Johansen wrote:
Is it just me, or is UIManager gradually turning into a new SystemDictionary/Project?
Cheers, Henry And by that I mean equivalent to those classes in purity of purpose and simplicity; UIManager used to have a clear purpose - Provide a polymorphic interface for accessing common GUI dialogs for code which doesn't care which GUI framework is in use.
Right now, MorphicUIMananger also has methods for - Component building (a poor mans ToolBuilder, basically) - Global state accessor, not polymorphic (world and uiProcess handling ) - Debugger components building (!) - Accessing common Smalltalk tools (not necessarily a bad thing, but shouldn't that be the responsibility of ToolRegistry? IE a UIManager should install a proper ToolRegistry when activated, not provide an extra layer of indirection you HAVE to use if you say, want your app to work headlessly) - something called interactiveParserFor: I have no idea what means. this method resolves if the UIManager is able to process questions from the parser/compiler on user (like warnings about unimplemented callss, undeclared instance variables etc.).
-- Pavel
I assume that means these are not cases where input is not critical, and the compiler always has a backup path? Would that mean it might be an idea to instead use Notifications here, and let the caller handle them if necessary/appropriate? Cheers, Henry
I assume that means these are not cases where input is not critical, and the compiler always has a backup path? Would that mean it might be an idea to instead use Notifications here, and let the caller handle them if necessary/appropriate?
Yes I think so.
participants (3)
-
Henrik Sperre Johansen -
Pavel Krivanek -
Stéphane Ducasse