[GCompris-devel] GCompris refused on iOS

Holger Kaelberer hk at elberer.de
Wed Feb 3 08:24:49 UTC 2016



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".

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.

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?

Holger


More information about the GCompris-devel mailing list