[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ptp-dev] use case question regarding JAXB launch tab configuration
|
----- Albert L. Rossi <arossi@xxxxxxxxxxxxx> wrote:
>
> > >
> > > However, I am thinking I prefer to implement advanced/basic mode as two
> > > separate resource managers to make the user's choice a little more
> > > explicit than relying on what tab is currently visible when the user hits
> > > apply/run to make the decision which mode to run. Particularly since I'm
> > > concerned that the user may not remember whether the run configuration was
> > > last used in basic or advanced mode when he hits the 'run' icon to run the
> > > last selected run configuration instead of hitting 'run configurations'
> > > and making an explicit choice. So with my current thinking, I probably
> > > wouldn't use case 3.
> >
>
> This is where having a script is advantageous. The user can click "view script" to make sure the values are what she expects. I suppose eventually we could add something similar for "inspect launch command".
Instead of inspect launch command, what about a button which prints the current configuration values? That could be included on every tab.
Al
>
> Al
>
> > OK. But I agree that the option, if it exists, should be based on an explicit superset.
> >
> > If Greg gives me the go ahead with the XSD/Java binding change for this one class API, the internal changes are all in place. I've made the changes locally and am getting ready to test it.
> >
> > Thanks for the feedback,
> >
> > Al
> >
> > > Dave
> > >
> > >
> > >
> > > From: "Albert L. Rossi" <arossi@xxxxxxxxxxxxx>
> > > To: Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
> > > Date: 05/23/2011 11:38 AM
> > > Subject: [ptp-dev] use case question regarding JAXB launch tab
> > > configuration
> > > Sent by: ptp-dev-bounces@xxxxxxxxxxx
> > >
> > >
> > >
> > > I have been reviewing the "shared/not shared" switch on the launch tabs,
> > > and have a question about the resulting configuration.
> > >
> > > To remind you what this is all about. Say we define three separate
> > > top-level controllers for a given RM. Call them A, B, C. Now, let's also
> > > say that T, the complete set of attributes, is defined as {t0, t1, t2, t3,
> > > t4, t5, t6}.
> > >
> > > Case 1: shared = false for all three.
> > >
> > > This means that these are independent subsets in terms of what goes into
> > > the Launch Configuration. For instance, let's say that:
> > >
> > > A = {t0, t1, t2}
> > > B = {t0, t1, t3, t5}
> > > C = {t0, t1, t2, t3, t4, t5, t6}
> > >
> > > If the use is working with A, and does Apply or views the script or
> > > chooses Run, the Launch Configuration will only have values t0, t1, t2
> > > defined. If the user launches from tab C, the Launch Configuration will
> > > have all of them, etc. Note, however, that since the three tabs represent
> > > different subsets of T, the values of t0, t1, etc. are nonetheless shared
> > > between A, B, and C, so that if the user sets t0 in C and then flips over
> > > to A, any previous value for t0 set through A will have been overwritten
> > > and the user will see the new value for t0 there as well.
> > >
> > > Case 2: shared = true for all three.
> > >
> > > This means that no matter which tab the use hits Apply or Run from, the
> > > entire set of values for T are written to the Launch Configuration. This
> > > use case makes most sense when you have partitioned T among the tabs,
> > > e.g.,
> > >
> > > A = {t0, t1, t2}
> > > B = {t3, t4}
> > > C = {t5, t6}
> > >
> > > but will still pertain if there are intersecting values. This leads me to
> > > my first question. Does Case 2 ever make sense in a non-partitioned case?
> > > If so, then I believe I need to fix one thing: currently, if there is a
> > > value set in more than one shared environment tab, it is not necessarily
> > > the visible value which gets saved, but the value on the last tab (C in
> > > this case), because the parent updates the tabs in order. In order to
> > > make this intuitive, I would need to change this update to do the rotation
> > > modulo the number of tabs beginning with the tab just after the visible
> > > one and ending with the visible tab.
> > >
> > > Case 3: A & B shared, but C not shared (or some combination of on/off).
> > > This doesn't work quite as one would expect. If the user clicks Apply or
> > > Run from A or B, the Launch Configuration gets the values on A,B _and_ C,
> > > but if the user is working from C, the Launch Configuration gets only the
> > > values in C. While this makes sense from one standpoint, it may not be
> > > intuitive to the user, who probably thinks that A and B should not include
> > > the values in C which are not in the intersection of A,B, and C.
> > >
> > > All of this may seem like a silly set-theoretical game, but the two basic
> > > scenarios were meant to support cases which already exist:
> > >
> > > 1 = an RM like PBS, where we wish to present the user with a set of tabs
> > > moving from basic to more inclusive.
> > > 2 = an RM like OpenMPI or PE (?), where the tabs represent categories of
> > > attributes.
> > >
> > > I guess my question is: should I go ahead an make the two changes I have
> > > suggested here? That is, ensure that the values on the visible table
> > > overwrite any other tab values, and fix the way that the shared/not shared
> > > flag works so that it works as in Case 3 (a little more complicated)?
> > >
> > > One last thing: I have fixed a little bug that existed in the restoration
> > > of default values. This button now applies _only_ to the current tab,
> > > regardless of whether the tab's shared property is true or false.
> > >
> > > Al
> > > _______________________________________________
> > > ptp-dev mailing list
> > > ptp-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/ptp-dev
> > >
> > >
> >
>
> _______________________________________________
> ptp-dev mailing list
> ptp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ptp-dev
>