Re: A couple more possible bugs
Re: A couple more possible bugs
- Subject: Re: A couple more possible bugs
- From: Scott Tooker <email@hidden>
- Date: Sat, 1 Nov 2003 20:58:24 -0800
On Nov 1, 2003, at 4:07 PM, Brian Barnes wrote:
> On Nov 1, 2003, at 1:45 PM, Scott Tooker wrote:
>
> Thanks for the reply Scott (on a weekend!) Some more info:
>
>>> 2) Get Info and Show Inspector *always* seem to do the same thing
>>> for every item in the groups and files
>>
>> What do you mean by "the same thing". These menu items are designed
>> to be similar to the Finder's implementation of the same menu items.
>> 'Get Info' brings up a normal window focused on the selection, and
>> doesn't track selection changes. 'Show Inspector' brings up a
>> floating utility window that tracks selection changes.
>
> OK - I get it (though I've never seen "show inspector" in the finder
> ....) I'd never pick it anyway when (1) is fixed! I get the general
> idea; I'm just not sure about the UI ... it's a minor complaint, but
> you bring up an inspector, then you have to click back to refocus the
> project window, then click somewhere, then click the inspector again.
> It'd be easy just to get info on each separate thing, but that's IMHO
> and the complaint is rather minor :)
The reason we went with both, is the same reason that the Finder did,
some people want a 'Get Info' window and others want a floating
inspector. This is one of those cases where it is best to support both
workflows. AFAICT, users mainly stick to one mode or the other (for
example, I pretty much just use 'Get Info').
>
>>> 3) When doing get Info on the project, and changing the "place build
>>> products in:" unnecessarily changes the "place intermediate build
>>> files in". I want those to stay the same, and I have to re-edit
>>> them
>>
>> My guess is that you have "place intermediate build files in" set to
>> "Build products location" instead of "Separate location".
>
> Whatever this is it's *really* weird. Here's one way to recreate it.
> Take a project where both are on "default location". Change "build
> products" to "separate location", fill some path in the path box.
> Close the info window. Open it back up, and now "intermediate" path
> is different (it's attached from the top build products.) Maybe this
> is the way it's supposed to work, but it's kind of weird, IMHO, and
> isn't what I want to happen (the docs say default is what's set by the
> xcode default, and this isn't what happens.)
>
> The fix is to make them BOTH separate locations.
The problem is that the default location for intermediates build files
is "a build folder inside the location for the build products" :)
>
>>> Quick question: For the "place build products in" and "place
>>> intermediate build files", the paths are complete; is there a path
>>> variable that I can use to say "current project folder?" I want to
>>> pass out some of the code, and this will just serve to confuse
>>> people.
>>>
>>> For instance, some of my static libraries I want to intermediate
>>> files to go into the build folder, but the file libXXX.a file to go
>>> into a common folder that is one folder up, but not locked to my
>>> user name. So instead of:
>>>
>>> /users/bbarnes/code/dim3Common/Libraries
>>> /users/bbarnes/code/dim3BitmapUtility/build
>>>
>>> I could do:
>>>
>>> <current project>/../dim3Common/Libraries
>>> <current project>/build
>>>
>>> If that's not there, mark this as a feature request :)
>>
>> One thing you could try is to define a 'source tree' path in the
>> Source Tree preference pane. Then use the 'Setting Name' for the
>> source tree in the path, like so:
>>
>> Add a Source tree like 'CommonLibraries' and then in your path put
>>
>> ${CommonLibraries}
>>
>> and use the SRCROOT variable to refer to the project directory
>>
>> ${SRCROOT}/build
>>
>> If this doesn't work please file a bug on the part that doesn't work.
>>
>> Note: for the 'Source Tree' each person needs to add the same source
>> tree and set their path to it's location on their disk.
>
> OK -- there's a bug with this :)
>
> I had build products set as: ${SRCROOT}/../dim3Common/Libraries
> and intermediate products as: ${SRCROOT}/build
>
> There's a build directory created in ${SRCROOT} (right -- with the
> build files)
> But it also creates on in ${SRCROOT}/../dim3Common/Libraries, I just
> want libdim3XXX.a there (which is there.)
Please file a bug and provide a small testcase if you can.
>
> Also -- as mentioned before -- there doesn't seem to be a way to close
> an editor window if you by mistake create on in the project window.
> How do I close this? I'm close to re-making the project!
To clear out the files in the attached editor, click in the editor and
select 'Clear File History' from the View menu. Then select 'Close
Current File' from the File menu. Finally click on the "Hide Editor"
toolbar item to hide the attached editor.
In Xcode 1.0 there are definitely known issues with not remembering the
state of the project window correctly. Many of these have been fixed
for the next release.
Scott
>
> [>] Brian
> _______________________________________________
> xcode-users mailing list | email@hidden
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/xcode-users
> Do not post admin requests to the list. They will be ignored.
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.