>
> On Wed, 3 Oct 2018 at 16:18, Guillermo Polito <guillermopol...@gmail.com>
> wrote:
>
>
>
On 2 Oct 2018, at 12:30, Ben Coman <b...@openinworld.com> wrote:
>
> On Mon, 1 Oct 2018 at 23:16, Sean P. DeNigris <s...@clipperadams.com>
> wrote:
>
>> Tim Mackinnon wrote
>> > either by showing {owner}/{project}
>>
>> What about when there are multiple remotes?
>>
>
> +1 to what you imply here, that the owner/remote should not be auto-coded
> into the project name.
> Remotes are well handled within Iceberg.
> The user though could add the owner as free text into a custom project
> name i.e. "owner-project"
>
> cheers -ben
>
>
> On Tue, Oct 2, 2018 at 6:54 PM Ben Coman <b...@openinworld.com> wrote:
>
>>
>>
>> On Tue, 2 Oct 2018 at 15:52, Guillermo Polito <guillermopol...@gmail.com>
>> wrote:
>>
>>> - Maybe, for old projects that don't have a name, we could initialize a
>>> project's name as it's repository name?
>>>
>>
>> In any case, I'd expect the project name within Iceberg to match the name
>> of the working directory on disk.
>>
>
> Yes
>
>
>> Possibly even the project renamed within Iceberg should rename the disk
>> working directory.
>>
>
> I am afraid of this ^^. This could be a natural and simple mechanism to
> explain, but take into account that you can have in iceberg different
> repositories from different places in your disk.
> Then this means you will not be able to rename your project if you have a
> directory with the required name in the same place.
>
I get your point, and Sean's also. Probably over-constraining it to force
the Pharo-name and disk-name to be the same.
It would help if the disk working directory is easily discoverable, like
showing in a hover popup.
Menu items like "Open Folder Here" or "Open Shell Here" would help workflow.
cheers -ben
