[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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 -----
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