Hi Sean:
Good one. (reminds me of Johnny
Cochran... "If the glove doesn't fit, you must acquit"... have you thought
about becoming a lawyer? :-)
We will send it next week. We need a few days
to integrate it with the head.
Regards,
Mike Charls
BitMethods, Inc.
----- Original Message -----
Sent: Friday, April 02, 2004 12:36
PM
Subject: 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
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
|