Merlin: a library to build Wizards
Locked
 
|
Hi everybody,
Just send this email to inform you that I have developed a small library ( called 'Merlin' ) that provide a simple structure to build Wizards. It is available on squeaksource at: http://www.squeaksource.com/Merlin.
You will find a small example in the class side of 'WizardControl'. I have been making this library to build a Moose wizard that enable to select packages and some importations informations.
Therefore, you can see this other example by loading Moose with: 'ConfigurationOfMoose loadDefault '. It will load all required classes. The Moose Wizard will be in the package Moose-Wizard. So, feel free to test it or use it if needed :) _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Merlin: a library to build Wizards
|
|
Thanks for tackling this; wizards can be
very useful, and Pharo should have an easy way to create them. So far, I
have only loaded the package, run the example, and glanced at the
hierarchy.
Purely cosmetic, it would be good to defaullt to "<< Back" and
"Next >>" for the buttons. There will always be other buttons to add
in weird cases, but the first/last/middle panes can do reasonable things unless
customized.
Is there a way to fix a size for the wizard? Changing to the
size of the current pane is powerful, but also looks
strange.
I am
suspicious of the WizardPart heirarchy. Are they controls that can only
work in a wizard? It seems unlikely, or perhaps that there should be a
more generic hierarchy of controls/presenters that work in wizards and anywhere
else. Put another way, I fear that their existence highlights something
missing in Pharo. TEasilyThemed gets close to providing ways to create
useful controls, but it IMHO falls short on the presenter/model side. Gary
didn't like the idea of default models, but I still think there is room for
improvement. A list shoud have something that provides its needed
selection index aspect, allowing one to think in terms of the object
corresponding to the selection. Value models and adapters (particularly
aspect value adapters) offer a great view from the top of the
learning curve.
One
thing that I like about Polymorph (and Magritte and Seaside) is that domain
objects get a active say in their graphical representation. Dolphin's MVP
framework typically forces a GUI onto the model rather than letting the model
grow one to suit it. A good compromise might be to create analogs to
Dolphin's presenters with those (rather than the controls themselves) being
produced by something like TEasilyThemed. The Smalltalk code creating the
presenters could include just enough layout objects and methods to do the job of
the Dolpin view composer and layout managers. At least I _think_ it could
work that way - great stuff if I'm at all close to thinking
straight.
Bill
From: [hidden email] [mailto:[hidden email]] On Behalf Of Cyrille Delaunay Sent: Friday, November 20, 2009 10:06 AM To: pharo-project Subject: [Pharo-project] Merlin: a library to build Wizards Just send this email to inform you that I have developed a small library (
called 'Merlin' ) that provide a simple structure to build Wizards.
It is available on squeaksource at: http://www.squeaksource.com/Merlin.
You will find a small example in the class side of 'WizardControl'.
I have been making this library to build a Moose wizard that enable to
select packages and some importations informations.
Therefore, you can see this other example by loading Moose with:
'ConfigurationOfMoose loadDefault '. It will load all required classes. The
Moose Wizard will be in the package Moose-Wizard.
So, feel free to test it or use it if needed :)
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by cdelaunay
Hello,
I test it. It is quit good. Just wondering why user have to say a pane is the first pane, dans another pane is the last. Could not the framework find it by itself ? The first one is a FirstPane and the last one when it is launch is a LastPane ? a+ Vicnet |
Re: Merlin: a library to build Wizards
|
|
If I understand you, that's not a good idea: the last pane in the sequence is not necessarily the last step in the wizard. I have examples in Dolphin that branch depending on user's choices along the way, and sometimes it reaches a close with additional panes remaining in the list, but those are for "the road not taken."
Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of vicnet Sent: Monday, November 23, 2009 8:21 AM To: [hidden email] Subject: Re: [Pharo-project] Merlin: a library to build Wizards Hello, Cyrille Delaunay wrote: > > Just send this email to inform you that I have developed a small > library ( called 'Merlin' ) that provide a simple structure to build Wizards. > I test it. It is quit good. Just wondering why user have to say a pane is the first pane, dans another pane is the last. Could not the framework find it by itself ? The first one is a FirstPane and the last one when it is launch is a LastPane ? a+ Vicnet -- View this message in context: http://n2.nabble.com/Merlin-a-library-to-build-Wizards-tp4038238p4051036.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Hi,
Thanks for your comments. I have changed the default buttons to 'Next >>' and '<< Back'. I have not yet find how to fix the same size to all panes. For the moment I'm using a 'PluggableDialogWindow' that I open in a StandardWindow (StandardWindow new openModal: dialogWindow). Doing this, the pane is automatically resize according the elements of the dialogWindow.
But indeed, it would maybe be more usefull for the user to click the next buttons one after the others without moving the moose according the resized pane. WizardPart is not so specific to the wizard hierarchy:
-> There is the two methods 'outputValue' and 'retrieveInputRequired' that make the link with a cooresponding wizard pane , but they are abstract methods. Therefore, you can retrieve the inputs in the way you want and make what you want with the output.
-> The other link is a kind of control for enabling the next button of the wizard pane. By default, it's an instance variable set to true, so you can not take care of that. A lot of subclasses of WizardPart I made don't retrieve any input and don't care about the next button. You can create instances and directly have the morph contents (with the method 'contents').
I agree for the LastPane. For example, in the addition, soustraction, ... wizard example, a LastPane could have been the selection of the last element of the operation, and after that we could have a pane that simply display the result (without any control). However, the first pane diplayed in a wizard will allways look like a FirstWizardPane (or maybe a customized version of it).
2009/11/23 Schwab,Wilhelm K <[hidden email]> If I understand you, that's not a good idea: the last pane in the sequence is not necessarily the last step in the wizard. I have examples in Dolphin that branch depending on user's choices along the way, and sometimes it reaches a close with additional panes remaining in the list, but those are for "the road not taken." _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Merlin: a library to build Wizards
|
|
Keeping a desired size might be as simple as adding a
surrounding container, but hopefully Gary can provide a #preferredExtent or
something, that when notNil fixes the size of a window w/o the need to "waste a
widget." It took a little while to get it right, but Dolphin has long done
a nice job of that - no great surprise really. As a grateful friend, not
only does the current situation force the user to chase the buttons between
panes, it also looks like we don't know how to fix the size (which
coincidentally is the case, however temporary it might be<g>).
Having views that _can_ size themselves is great; we should not need
to rely on it when building for end users.
I have not had much time for
GUIs in Pharo, but I already miss MVP. Gary is probably the best person to
comment on whether your data manipulation methods are redundant or belong at a
more abstract level. I think it has to be one or the other, as getting
data into and out of controls is not specific to wizards. If you have done
it well, we should probably spread it around; if there are better ways to do the
job, we should note that and you should eventually/gradually move toward the
better approach. Repeating myself a little, I really like value
models and adapters for matching domain objects to controls.
Thanks
for doing this!
Bill From: [hidden email] [mailto:[hidden email]] On Behalf Of Cyrille Delaunay Sent: Monday, November 23, 2009 9:23 AM To: [hidden email] Subject: Re: [Pharo-project] Merlin: a library to build Wizards Thanks for your comments.
I have changed the default buttons to 'Next >>' and '<<
Back'.
I have not yet find how to fix the same size to all panes. For the moment
I'm using a 'PluggableDialogWindow' that I open in a StandardWindow
(StandardWindow new openModal: dialogWindow). Doing this, the pane is
automatically resize according the elements of the dialogWindow.
But indeed, it would maybe be more usefull for the user to click the
next buttons one after the others without moving the moose according the resized
pane.
WizardPart is not so specific to the wizard hierarchy:
-> There is the two methods 'outputValue' and 'retrieveInputRequired'
that make the link with a cooresponding wizard pane , but they are abstract
methods. Therefore, you can retrieve the inputs in the way you want and make
what you want with the output.
-> The other link is a kind of control for enabling the next button of
the wizard pane. By default, it's an instance variable set to true, so you can
not take care of that.
A lot of subclasses of WizardPart I made don't retrieve any input and don't
care about the next button. You can create instances and directly have the morph
contents (with the method 'contents').
I agree for the LastPane. For example, in the addition, soustraction, ...
wizard example, a LastPane could have been the selection of the last
element of the operation, and after that we could have a pane that simply
display the result (without any control). However, the first pane diplayed in a
wizard will allways look like a FirstWizardPane (or maybe a customized version
of it).
2009/11/23 Schwab,Wilhelm K <[hidden email]> If I understand you, that's not a good idea: the last pane in the sequence is not necessarily the last step in the wizard. I have examples in Dolphin that branch depending on user's choices along the way, and sometimes it reaches a close with additional panes remaining in the list, but those are for "the road not taken." _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |