[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] Heads-up to managed build developers
|
That looks very sharp. Submit it and
I will commit it.
Sean Evoy
Rational Software - IBM Software Group
Ottawa, Ontario, Canada
"Mike Charls"
<mcharls@xxxxxxxxxxxxxx>
Sent by: cdt-dev-admin@xxxxxxxxxxx
04/02/2004 02:20 PM
Please respond to
cdt-dev |
|
To
| <cdt-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| Re: [cdt-dev] Heads-up to
managed build developers |
|
Hi Sean:
Adding the browseType attribute is fine with
us.
one more thing (now that you are looking
at this area)... the Add, Remove, Move Up and Move Down buttons are
always off the screen for the File items. They are too far to the
right, so the user always needs to scroll over see the buttons. This
is a minor point, but still a pain for the end-user.
We changed this in our application to place
the buttons at the top of the file list (like a toolbar). Attached
is a screen snapshot. This approach is similar to how Windows handles
File lists.
We use these file list buttons for the include
Directories, Symbols, Libraries, and Other Options categories in the Build
manager properties.
If you would like to use this approach for
the user interface, we can send you a patch.
Regards,
Mike Charls
BitMethods, Inc.
----- Original Message -----
From: Sean
Evoy
To: cdt-dev@xxxxxxxxxxx
Sent: Thursday, April 01, 2004 8:25 AM
Subject: [cdt-dev] Heads-up to managed build developers
Hi Guys,
I just wanted to bounce a couple of ideas off the people who are looking
at, and working on, the managed build system. First, there has been an
endless stream of requests to put a browse button on path or file options.
Since an IOption does not know what type of list it contains, I am proposing
a new enumerated attribute in the option schema called "browseType".
It will contain "none", "file", or "directory"
so the UI can properly decide whether to display a browse button or not.
So far, the solution does not break existing manifest definitions and the
UI is working properly. I would like to know if anyone has a problem with
this solution or if it tramples on something you have already done.
What this does not solve is the problem where the SWT/JFace widgets answer
the file location or path location in the OS-appropriate format but the
tools require these specifications in a different format. For example,
imagine a cross-compiler hosted on Win32 not liking C:\foo\include, which
is what we get back from the browse dialog. This might require some further
tweaking of the toolchain model to get more information about the file
system type the hosted tools prefer to use. Notice how studiously I am
avoiding the term "target model" :-)
The window to propose alternatives is small, so if you have any strong
opinions on this, please let me know asap.
Sean Evoy
Rational Software - IBM Software Group
Ottawa, Ontario, Canada
Attachment:
IncludeFiles.jpg
Description: JPEG image