[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[cdt-dev] build ui thoughts
|
Sean,
As for the UI, I was thinking of using something similar to the run/debug buttons, where clicking on the button allowed the user to execute the last build and clicking on adjacent down arrow allowed the user to pick from a menu. The main application menu bar could also have a menu with similar contents. I'm guessing that once the user configures the workspace for a build, changing build goals won't be a frequent occurrence but building will be, so allowing the user to quickly build "the same way as last time" sounds like the right thing to do.
This model, however, does not map nicely to the system model, as the user could have different build goals or each project, so a menu of what would be shown to the user? I think creating another layer of indirection by allowing the user to define a sequence of build goals stored as a "workspace build goal" would be overly cumbersome for most usage patterns.
That takes us back to a build goal view. I guess similar functionality could be offered by showing the user a view containing the population of build goals for the workspace, grouped by project, and allowing the user to select one from each project as the default build goal. This would be a lot less intimidating for users and the project creation wizard could event have the user select the default goal. If we got especially motivated, we could allow the user to name sets, akin to the idea in the former paragraph.
Another problem is persisting this data. I'm not sure if this is something that we want to persist as part of the project or the user's workspace.
>> It would be helpful to me if you and I could discuss further what the make target view could be used to display.
I can hold my ideas until the next conference call or continue thinking out loud via e-mail if this works for you and the other folks working on the project. :-)
gene
-----Original Message-----
From: Sean Evoy [mailto:sevoy@xxxxxxxxxx]
Sent: Wednesday, July 23, 2003 10:31 AM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] RE: [cdt-patch] CView update
Gene,
No cowering necessary. We really have not had a lot of time to think
through how the build model (interface) will interact with UI clients like
the make target view, so your implementation makes sense given our
silence. I don't have a problem with the way you extracted the information
from the build model, but it might be better if I provided you with a list
of targets in the format you need on demand just in case I need to change
the methods you used.
At a higher level, we have not closed on a clean way of showing the user
which configuration they are currently building for a managed build
project. As you saw, each project may have more than one target, and each
target can have more than one configuration. Up until now, we have simply
taken the last target-configuration the user was editing in the property
page as the default "build goal" to generate makefiles for and build, upon
receiving the build command. Perhaps we could use the make target view to
select/change the build goal if there was some way to highlight the
current configuration for the project.
In the short-term, I can give you a better interface to the managed build
information so we can both be protected if the build model manager
changes. As the client of this information, you can let me know what you
need. Presumably, this is another interface we should think about adding
to the build model interface we discussed in the con-call last week.
It would be helpful to me if you and I could discuss further what the make
target view could be used to display.
Sean Evoy
Rational Software - IBM Software Group
Ottawa, Ontario, Canada
cdt-patch-admin@xxxxxxxxxxx wrote on 07/22/2003 10:57:18 PM:
> >> Gene, are you coordinating with Sean on this?
> <cowering> No. <double cowering> Sorry.
>
> The documentation was great, I read it and was able figure out the
> right thing to do. If a project does not have associated managed
> build data, the UI operates the same way it did before, so I'm not
> breaking any functionality that's already there. Only projects with
> managed build data have another menu generated.
>
> I will need to coordinate with Sean to get the run build code
> completed, as the code necessary to execute a build didn't look
> complete from the managed build perspective. I'll move this
> conversation over to the CDT-Dev list.
>
>
> gene
>
> -----Original Message-----
> From: Douglas Schaefer [mailto:dschaefe@xxxxxxxxxx]
> Sent: Tuesday, July 22, 2003 2:26 PM
> To: cdt-patch@xxxxxxxxxxx
> Subject: Re: [cdt-patch] CView update
>
> No problem. The patch is in the wrong format and I can't apply it
anyway.
>
> The references to Managed Build scared me, though. Gene, are you
> coordinating with Sean on this?
>
> Thanks,
> Doug
>
>
>
>
> "Alain Magloire" <alain@xxxxxxx>
> Sent by: cdt-patch-admin@xxxxxxxxxxx
> 07/22/2003 11:08 AM
> Please respond to
> cdt-patch@xxxxxxxxxxx
>
>
> To
> cdt-patch@xxxxxxxxxxx
> cc
>
> Subject
> Re: [cdt-patch] CView update
>
>
>
>
>
>
> >
> > Hi Thomas,
> >
> > If the patch has your oki-doki (sp?), I can take care of it.
>
> Wait, I'll take ownership of this one. The patch is going through
> some work that hoda was working on.
>
> Sorry gene, for the delay (vacation days ... good times 8-)
>
> FYI, I'm off Fridays/Mondays so the response time may be a little slow.
>
> I will take a look at the patch this week.
>
>
> _______________________________________________
> cdt-patch mailing list
> cdt-patch@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-patch
>
>
> _______________________________________________
> cdt-patch mailing list
> cdt-patch@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-patch
> _______________________________________________
> cdt-patch mailing list
> cdt-patch@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-patch
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev
