[GCompris-devel] gcompris [Sailfish OS]

Johnny Jazeix jazeix at gmail.com
Thu Jan 15 11:35:27 UTC 2015


For now, I don't think anyone has taken the task.

If you have a wiki account, you can add a line on this table with your
name in front: http://gcompris.net/wiki/Qt_Quick_Migration_status#Core
so we'll know that you are doing it and nobody will take this task. If
you don't have one, I'll add the line later (and/or you can ask Bruno
for an account if you want one).

Johnny


2015-01-15 12:28 GMT+01:00  <smirnoff.al at gmail.com>:
> Good.
> Could you  already say who will do it?
>
> I could try to fullfil this task.
> I mean, remove all imports of dialogs and add imports from custom ones.
> The first version of custom dialogs could be just copy past from qt ones with slight changes.
>
> Alex.
>
> Am Do. Jan. 15 10:40:13 2015 GMT+0100 schrieb Johnny Jazeix:
>> Hi,
>>
>> I agree with Bruno, it will be a lot of work to maintain a lot of
>> platform specific (and it's not the aim of GCompris).
>>
>> We don't need to reproduce at identical the Dialog component. I mean,
>> we could only have a <insert color here> rectangle displaying in
>> middle with a TextField (or a Item that we fill depending on our
>> needs), Buttons at bottom and if needed a Progress bar.
>>
>> The actual uses we have are very simple and I think we should not complicate it.
>>
>> Johnny
>>
>>
>> 2015-01-15 1:36 GMT+01:00 Bruno Coudoin <bruno.coudoin at gcompris.net>:
>> >
>> > Le 14/01/2015 21:36, Alex Smirnoff a écrit :
>> >
>> > Hi.
>> > Dialog is just a simple window. This should be no problem to implement it.
>> > But respecting SailfishOS - in usual case it have only one window -
>> > Application window.
>> > Then it use Page concept. You just slide forward and back between several
>> > pages.
>> > That mean that in case of SailfishOS Dialog could  be implemented as Page.
>> > But even it implemented as window (In case of games this also quite usual),
>> > that better to slide to another page in any case if dialog content is little
>> > bit more complex as simple yes/no buttons. Because that make it more usable
>> > on target platform and less alien.
>> >
>> > So
>> > 1. I agree that custom dialogs should be implemented for gcompris.
>> > 2. Dialog could or should have native implementation specific to target
>> > platform. (Page sliding concept in case of Sailfish OS using native silica
>> > library).
>> > 3. The same thin could be said regarding controls, especially buttons.
>> >
>> > Hi,
>> >
>> > I don't agree that we have to be that concerned about native implementation.
>> > If you look at games this is natural to have dialogs and buttons that
>> > matches the game look and feel versus the platform one. Also the platform
>> > design may not be appropriate for children.
>> >
>> > My concern here is accessibility. Using native buttons ensure the
>> > accessibility tools of the platform will work in GCompris. On that side we
>> > made more efforts to allow keyboard navigation than we did in the Gtk+
>> > version.
>> >
>> > Bruno.
>> >
>> >
>> > _______________________________________________
>> > GCompris-devel mailing list
>> > GCompris-devel at kde.org
>> > https://mail.kde.org/mailman/listinfo/gcompris-devel
>> >
>> _______________________________________________
>> GCompris-devel mailing list
>> GCompris-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/gcompris-devel
>>
>
> --
> Gesendet von meinem Jolla


More information about the GCompris-devel mailing list