[Sugar-devel] Remove the naming alert in 0.86

[Gary C Martin]

On 5 Sep 2009, at 18:24, Eben Eliason wrote:

> On Sat, Sep 5, 2009 at 11:51 AM, Gary C Martin<gary at garycmartin.com>  
> wrote:
>> On 5 Sep 2009, at 12:53, Tomeu Vizoso wrote:
>>
>>> On Sat, Sep 5, 2009 at 13:46, Benjamin M.
>>> Schwartz<bmschwar at fas.harvard.edu> wrote:
>>>> Tomeu Vizoso wrote:
>>>>> I also think that improving the default texts will improve greatly
>>>>> this issue. Anybody wants to tackle it? Maybe for a reduced number
>>>>> of
>>>>> activities at first?
>>>>
>>>> Ah, but what should it say?
>>>
>>> I think that the best automatic title will be activity-dependent.
>
> Definitely.
>
>>> Activities can already set any title they want in the write_file()
>>> method, but should respect the title_set_by_user property.
>>>
>>>> How about "Change this title to a description of this Write
>>>> Document!"?
>>
>> Ewwww no thanks!! :-)
>>
>>> That's interesting, though has its drawbacks.
>>
>> Drawbacks, are that many will still choose to not edit the name, and
>> Journal will fill with this junk text when ever they don't bother (I
>> usually only edit a name if I think the content is of future use).
>>
>> The auto-title needs to be smarter, more useful, not more  
>> annoying ;-)
>
> Agreed.
>
>> Two good concrete example suggestions I've seen so far:
>>
>> Eben suggested Chat at least (and perhaps some others) could be using
>> the buddy name as part of its default title, "Gary's Chat Activity'.
>> This has the added benefit that when shared, the Neighbourhood view
>> will get that more descriptive title (you currently need to edit a
>> title before sharing for the text to show up).
>>
>> Christoph suggested Write could use the first few words from the
>> document as part of the default title so "The Lazy Dog Write
>> Activity". This could get quite smart, but a few cases could be  
>> enough
>> ie. take first line of text followed by newline as title, limit to N
>> words, if longer than N also add ellipsis. "A voyage in space; a
>> course of six lectures 'adapted... Write Activity"
>>
>> It's also been suggested that when title names are identical, it  
>> would
>> be nice to append a unique number so at least there is some different
>
> Yes, I think this would be really good.
>
>> text in the title. Perhaps a natural language date string could serve
>> as the same device (as the Journal is not providing any way of
>> presenting creation dates and could realy help when searching  
>> "tuesday
>> august 18 notes").
>
> I can see some utility there, but it could also be rather confusing to
> have multiple dates exposed for every entry in the Journal. I'd lean
> toward a simpler and shorter counting mechanism.

OK, fair point (though since day one I've wished creation dates were  
explicitly kept, knowing when you started something is as or more  
important than when you last opened it).

>> I think each Activity will have different options to get a good name
>> (i.e in Labyrinth I could have it take the text from the primary man
>> node), but se should agree on some general improvements so we can  
>> have
>> some consistency in behaviour (i.e. an extended set of recommended
>> title guidelines for activity authors).
>
> Would it be easier for activities to provide a method like
> get_default_title() that the shell calls when appropriate? If we had
> this, then activities wouldn't have to deal with checking whether or
> not the user has already titled something, minimizing effort and
> possible error, and we could also have the shell check the DS for
> same-name entries and append a unique identifier itself, again
> ensuring consistency and removing work from the activity. The shell
> would only call this function once when an activity is first closed
> (when the naming alert currently appears), and then only when the
> title hasn't yet been set by the user.


Yes it would be easier, and something to think about for 0.88, but the  
0.86 train has left the station, so it is perhaps wiser to try this  
for a few Activities and then see what sticks enough to pickup in a  
future cycle.

Regards,
--Gary