[GCompris-devel] GCompris refused on iOS

[Bruno Coudoin]

Le 03/02/2016 16:47, Holger Kaelberer a écrit :
>
>
> On 03.02.2016 12:30, Bruno Coudoin wrote:
>>
>>
>> Le 03/02/2016 09:24, Holger Kaelberer a écrit :
>>>
>>>
>>> On 02.02.2016 23:11, Bruno Coudoin wrote:
>>>>
>>>>
>>>> Le 02/02/2016 22:45, Karl Ove Hufthammer a écrit :
>>>>> Bruno Coudoin skreiv 02. feb. 2016 22:07:
>>>>>>
>>>>>> For the 24.3 they don't like our web links in our about box. We
>>>>>> already remove them when compiled
>>>>>> in 'no download mode'. But I agree we Apple that it is not a good
>>>>>> idea to let a children 'escape'
>>>>>> GCompris and get on the Internet just by clicking a link in
>>>>>> GCompris. Even if our target links
>>>>>> are fine, once in a browser you don't know what will happens. I
>>>>>> propose to remove all web links
>>>>>> all together on all platforms.
>>>>>
>>>>> I don’t agree with the proposal to remove all Web links on all
>>>>> platforms. It’s useful to have the
>>>>> Web links to Wikipedia in various activities. But it would be OK to
>>>>> (automatically) *disable* the
>>>>> links (i.e. make them non-clickable URLs) on *the iOS platform*, but
>>>>> leave them as normal links on
>>>>> other platforms.
>>>>
>>>> Hum, we have to weight the pro and cons. Starting a web browser from
>>>> GCompris when a teacher or a
>>>> parent consider the children in a walled garden is too dangerous. We
>>>> still display links and it is
>>>> not so hard to find them in most cases.
>>>>
>>>> One trade of we can do it that a link click would copy itself to the
>>>> clipboard with a little tooltip
>>>> explaining that. Then if the children has access to a browser he just
>>>> have to paste it. You like it?
>>>
>>> Another possibility would be to make behaviour configurable. To let a
>>> potential teacher decide whether he does *not* want children to inform
>>> themselves further by following http links. And leave default to "yes,
>>> you can use the web to learn more".
>> If we want to go there we need to have an adult section. I saw an app
>> that hides the configuration behind a math question like how much does
>> '47 + 12' to avoid smaller children break the configuration. To me it is
>> too risky to let the children open a browser like this so anyway this
>> option if we get there must be off by default on all platforms.
>>
>> You may think of a parent doing a desktop without a browser and see the
>> children on the web after playing on GCompris.
>
> I see your point.
>
> Allowing my own children to use a browser I was not aware that it
> might be considered an evil thing by parents that should be blocked by
> an application. Still, would be good if there would be the option to
> not wall the garden and let the children play in the forest.
I did like you but not everybody does so.
>
> Then probably an equivalent to the kiosk-mode wouldn't be considered
> safe enough as well?
Frankly, we are talking about 4 links, is this really worth to make it
an option.
>
>>
>>>
>>> I agree with Karl that external links that serve to learn more are a
>>> good thing to have.
>>>
>>> In general I don't like the idea to change overall behaviour on all
>>> platforms just because of the policy of a commercial vendor (of
>>> apples, or robots). (I see your concerns in this point of course,
>>> Bruno.) If apples are different from the rest of the fruits make an
>>> exception for them.
>> I agree with you but I do believe Apple's remark makes sense. We have no
>> reason to refuse and idea because it comes from Apple. Let's look at the
>> rationale behind it and consider it like we would from any parent,
>> teacher or school or organization willing to use GCompris.
>
> You're right, my reaction was driven by prejudice and ignorance. Got
> it now what this is about.
No problem, I understand your reaction, I would propably had the same
when I was younger ;)
>
>>
>>>
>>> Regarding download location, DataLocation fits semantically imho
>>> better than CacheLocation for GCompris data. And if this shall be
>>> changed again GCompris should probably again take care to clean up the
>>> old location (as was done when switching from data/ to data2/) or we
>>> annoy users by wasting space. Why not make an exception here for
>>> apples?
>>
>> Here again, I believe Apple is right. Our voice is really a 'cache' more
>> than a 'data'. In data we would put session information or content
>> created by the user. If you erase it you loose user generated content. A
>> cache can be erased at anytime and be recreated without lose anything
>> except bandwidth.
>
> Ok, maybe a question of interpretation. I see our data as something
> pretty persistent as it doesn't change very often and that repeated
> downloads should be avoided. My point was that changing the location
> again for *existing* platforms with existing downloads that we
> must/should clean up could be avoided by only changing the target
> location on iOS.
>
To me our voice set is like a web image that may expire and be
refreshed. I just made a commit on 0.50 branch to cleanup the old
directory. Please check I got it right.

Bruno.