C++/Qt developer - free contribution

[Mylène JOSSERAND]

Hi,


My name is Mylene JOSSERAND.

I wanted to create an application to learn Japanese and I found your application that filled my requirements.

I am a french C++ and Qt developer on embedded Linux systems and I was wondering if I could help you to develop / improve your application.
Could you be interesting by my help ?

This is the first time I will contribute to an open source project so I do not know how to start. Could you give me some hints ?
I am currently testing your application to see how it works and all its functionnalities.

I have read that an Android version is in progress. It seems that you have chosen Web languages. Have you considered using QML/Qt Quick for your Android development ?


Best regards,

Mylène

[Alexandre Courbot]

Hi Mylène,

Thanks for your interest in Tagaini! Of course your help would be very
welcome, especially as an experienced Qt developer. I have become
quite busy with other stuff and did not put as much energy into it as
I should have recently. :(

To get started with it, assuming that you are familiar with the basics
of git and Github, the first steps would be to download the main
branch, compile it, and run it on your system. Then finding something
you would like to fix and submitting a pull request on Github would be
a nice way to begin development.

The application by itself is not really difficult to understand I
believe, although the source code is a little bit messy. Basically,
src/core/ contains all the non-GUI stuff, which src/gui/ builds on to
display the application. We have two data sources, JMdict (Japanese
dictionary) and kanjidic2 (kanji dictionary) that work independently,
hence you have one sub-directory for each in src/core and src/gui.
Technically it would be possible to use Tagaini's core for any kind of
dictionary, not only Japanese.

We also rely heavily on SQLite for storing/querying data, and have a
thin layer of abstraction on top of it.

One of the things I am trying to do is porting the application to Qt
5, a way overdue task. There is a qt5 branch for this - please feel
free to hack on it as well, since there are probably many things that
could be improved.

Regarding the Android development, my motivation for using Javascript
is that it is a language that can easily be used on desktop and any
mobile platform. My plans are thus to rewrite the *core* in Javascript
for portability, but keep the desktop GUI in Qt. The Android version
would then have a native Android UI, again on top of that Javascript
core.

I have considered QML/Qt Quick, but it seemed to me that the libraries
payload would be rather huge (~30MB if I remember correctly), to end
with a non-native look. This is not a fixed decision though - nothing
has been rewritten in Javascript yet, and I am definitely open to
QML/Qt Quick if there are good reasons to use it. As an embedded Qt
developer, you can probably give us some good reasons to use it. :)

Let us know if you have more questions, and it would be interesting to
hear about the advantages of QML/Qt for the Android version.

Cheers,
Alex.

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Tagaini Jisho" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to tagaini-jish...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Mylène JOSSERAND]

Hi Alexandre,

> Thanks for your interest in Tagaini! Of course your help would be very
> welcome, especially as an experienced Qt developer. I have become
> quite busy with other stuff and did not put as much energy into it as
> I should have recently. :(

Thank you for your interest !
I understand that it is not easy to deal with different tasks and
spend as much time as we would like.

>
> To get started with it, assuming that you are familiar with the basics
> of git and Github, the first steps would be to download the main
> branch, compile it, and run it on your system. Then finding something
> you would like to fix and submitting a pull request on Github would be
> a nice way to begin development.

Okay thanks for the tips.
I will spend time this week-end to test it and use it because I did
not know that this app existed before !
As I am currently learning japanese, it will help me ! :)

>
> The application by itself is not really difficult to understand I
> believe, although the source code is a little bit messy. Basically,
> src/core/ contains all the non-GUI stuff, which src/gui/ builds on to
> display the application. We have two data sources, JMdict (Japanese
> dictionary) and kanjidic2 (kanji dictionary) that work independently,
> hence you have one sub-directory for each in src/core and src/gui.
> Technically it would be possible to use Tagaini's core for any kind of
> dictionary, not only Japanese.

Yes, I have noticed the gui and core folders. Thank you for the explanations

>
> We also rely heavily on SQLite for storing/querying data, and have a
> thin layer of abstraction on top of it.
>
> One of the things I am trying to do is porting the application to Qt
> 5, a way overdue task. There is a qt5 branch for this - please feel
> free to hack on it as well, since there are probably many things that
> could be improved.

Yes ! This could be great to get a newer version than 4.5.
I think I will try this branch !

>
> Regarding the Android development, my motivation for using Javascript
> is that it is a language that can easily be used on desktop and any
> mobile platform. My plans are thus to rewrite the *core* in Javascript
> for portability, but keep the desktop GUI in Qt. The Android version
> would then have a native Android UI, again on top of that Javascript
> core.

Okay, I understand.
In fact, as you were using Qt, I was wondering why not starting with QML.

>
> I have considered QML/Qt Quick, but it seemed to me that the libraries
> payload would be rather huge (~30MB if I remember correctly), to end
> with a non-native look. This is not a fixed decision though - nothing
> has been rewritten in Javascript yet, and I am definitely open to
> QML/Qt Quick if there are good reasons to use it. As an embedded Qt
> developer, you can probably give us some good reasons to use it. :)
>
> Let us know if you have more questions, and it would be interesting to
> hear about the advantages of QML/Qt for the Android version.

Hum, I do not really have experiences with QML (I am currently testing
it at home but I am just starting).

I know that QML is more and more used for tablets and smartphones. I
know, for example, GCompris application which is an educative
application. The maintainer has tested HTML5 but, at the end, he has
chosen QML. You can find a video at the "Capitole du Libre" in
Toulouse where he spoke why he choose QML :
http://www.dailymotion.com/video/x2c8pll_conference-gcompris-passe-a-qtquick-avec-l-aide-de-kde_school
(sorry, only in French but I have seen that you are French Alexandre,
right ?)

I agree with him. Developing in javascript means, generally, using
third-party libraries whereas QML is part of the Qt framework. So you
will have consistency in your code and, also, get all the Qt community
help.
The advantages of QML are, also, that you will not have to rewrite the
core in Javascript as QML can use C++. As you seem to have separate
the GUI from the core, it could be faster to make this transition. QML
is very simple to code and permits to create very great GUI with no
efforts. Moreover, QML can be used for Desktop application, Android
application and also iOS application :
http://doc.qt.io/qt-5/ios-support.html so you will not have to adapt
the code according to the platform. You could use the same code for
Desktop and embedded devices.

If I have some questions, should I ask it here or should I send you an
e-mail directly (as it could be, maybe, too precise and technical for
this mail list) ?


Best regards,


Mylène

[Alexandre Courbot]

Hi Mylène,

On Sat, Dec 13, 2014 at 6:01 AM, Mylène JOSSERAND
<josseran...@gmail.com> wrote:
> Hi Alexandre,
>
>
>
>> Thanks for your interest in Tagaini! Of course your help would be very
>> welcome, especially as an experienced Qt developer. I have become
>> quite busy with other stuff and did not put as much energy into it as
>> I should have recently. :(
>
>
> Thank you for your interest !
> I understand that it is not easy to deal with different tasks and
> spend as much time as we would like.
>
>
>>
>> To get started with it, assuming that you are familiar with the basics
>> of git and Github, the first steps would be to download the main
>> branch, compile it, and run it on your system. Then finding something
>> you would like to fix and submitting a pull request on Github would be
>> a nice way to begin development.
>
>
> Okay thanks for the tips.
> I will spend time this week-end to test it and use it because I did
> not know that this app existed before !
> As I am currently learning japanese, it will help me ! :)

Hopefully. I started Tagaini for my own Japanese studies, as I wanted
a tool that helps me find, organize, and practice vocabulary and
kanji, while showing as many connections between entries as possible
to facilitate memorization. Although some time has passed, I have yet
to find a free tool that connects data that way.

>
>
>>
>> The application by itself is not really difficult to understand I
>> believe, although the source code is a little bit messy. Basically,
>> src/core/ contains all the non-GUI stuff, which src/gui/ builds on to
>> display the application. We have two data sources, JMdict (Japanese
>> dictionary) and kanjidic2 (kanji dictionary) that work independently,
>> hence you have one sub-directory for each in src/core and src/gui.
>> Technically it would be possible to use Tagaini's core for any kind of
>> dictionary, not only Japanese.
>
>
> Yes, I have noticed the gui and core folders. Thank you for the explanations
>
>
>>
>> We also rely heavily on SQLite for storing/querying data, and have a
>> thin layer of abstraction on top of it.
>>
>> One of the things I am trying to do is porting the application to Qt
>> 5, a way overdue task. There is a qt5 branch for this - please feel
>> free to hack on it as well, since there are probably many things that
>> could be improved.
>
>
> Yes ! This could be great to get a newer version than 4.5.
> I think I will try this branch !

Be aware that there will be a crash once in a while when you run the
program from the qt5 branch. To workaround this, just fix it again. It
is a bug in the update checking code (that runs once a day) that I
haven't yet fixed.

>
>
>
>>
>> Regarding the Android development, my motivation for using Javascript
>> is that it is a language that can easily be used on desktop and any
>> mobile platform. My plans are thus to rewrite the *core* in Javascript
>> for portability, but keep the desktop GUI in Qt. The Android version
>> would then have a native Android UI, again on top of that Javascript
>> core.
>
>
> Okay, I understand.
> In fact, as you were using Qt, I was wondering why not starting with QML.

QML did not exist at the time I was really active with Tagaini. ;) And
while it is definitely fit for mobile, I am not convinced it is the
best way to present data to desktop users?

>
>
>
>>
>> I have considered QML/Qt Quick, but it seemed to me that the libraries
>> payload would be rather huge (~30MB if I remember correctly), to end
>> with a non-native look. This is not a fixed decision though - nothing
>> has been rewritten in Javascript yet, and I am definitely open to
>> QML/Qt Quick if there are good reasons to use it. As an embedded Qt
>> developer, you can probably give us some good reasons to use it. :)
>>
>> Let us know if you have more questions, and it would be interesting to
>> hear about the advantages of QML/Qt for the Android version.
>
>
> Hum, I do not really have experiences with QML (I am currently testing
> it at home but I am just starting).
>
> I know that QML is more and more used for tablets and smartphones. I
> know, for example, GCompris application which is an educative
> application. The maintainer has tested HTML5 but, at the end, he has
> chosen QML. You can find a video at the "Capitole du Libre" in
> Toulouse where he spoke why he choose QML :
> http://www.dailymotion.com/video/x2c8pll_conference-gcompris-passe-a-qtquick-avec-l-aide-de-kde_school
> (sorry, only in French but I have seen that you are French Alexandre,
> right ?)

Thanks for the link, I will watch this with interest.

And yes, I am French. I'm just so glad the people on this list cannot
*hear* our English. :P

>
> I agree with him. Developing in javascript means, generally, using
> third-party libraries whereas QML is part of the Qt framework. So you
> will have consistency in your code and, also, get all the Qt community
> help.

Point taken about the requirement of 3rd party libraries for
Javascript. And I don't feel like doing everything on the bare metal
either.

> The advantages of QML are, also, that you will not have to rewrite the
> core in Javascript as QML can use C++. As you seem to have separate
> the GUI from the core, it could be faster to make this transition. QML
> is very simple to code and permits to create very great GUI with no
> efforts.

Well, I intent to rework the DB design and core architecture anyway,
so there will be a rewrite to some extent. I thought it might also be
the opportunity to add portability by switching languages.

> Moreover, QML can be used for Desktop application, Android
> application and also iOS application :
> http://doc.qt.io/qt-5/ios-support.html so you will not have to adapt
> the code according to the platform. You could use the same code for
> Desktop and embedded devices.

That's tempting, especially when you consider why I chose Qt in the
first place. See, when I started Tagaini back in 2008, the world was a
different place: people still used their desktop or laptop machine
primarily, so you just had to support Windows, MacOS and Linux to
cover virtually every user. Qt was the silver bullet.

Fast-forward 5 years, and the world is a mess again: iOS and
Objective-C, Android and Java, of course no one using the same
frameworks, and you still must support desktop on top of that (and
sync between them all). Things are muuuch harder now, and despite its
efforts to adapt to the mobile world, Qt comes from a very different
time. My rationale for JS was that all these platforms can at least
support a small C layer (SQLite and other required native functions),
and can all interpret Javascript. But as you pointed out, you would
then need to come with a different GUI for all of them, that's the
disadvantage compared to QML.

At the risk of infuriating some people, and to be fully honest, I
don't really care about iOS at this point. What I am more interested
in, and which I haven't seen in the list of platforms supported by Qt,
is Chrome OS. But here it seems like we would need a fully HTML
interface or something like that.

Actually exploring the feasability of QML would be a great thing to
try, if you don't know what to do. ;) It is one of my great shames in
life that Tagaini does not support mobile platforms yet, and any step
that could help going forward in that direction is probably the best
contribution one can make at this point.

>
> If I have some questions, should I ask it here or should I send you an
> e-mail directly (as it could be, maybe, too precise and technical for
> this mail list) ?

I think this mailing-list is fine - it is not targeted at users in
particular, and the volume is low, so please feel free to ask
questions and have technical discussions here. Having the discussions
public might also trigger other potential contributors, or people with
experience doing mobile apps.

In any case, please don't hesitate asking questions, and please also
don't hesitate to fork the project on Github and to submit pull
requests for bug fixes/new features. There's nothing better to get
started, and it's also more fun this way.

Cheers,
Alex.

[Shubham Mishra]

   It is one of my great shames in
> life that Tagaini does not support mobile platforms yet, and any step
> that could help going forward in that direction is probably the best
> contribution one can make at this point.

Not that I have anything useful to contribute to this discussion but please don't say that.  Tagaini on the desktop is an excellent program and knowing that I can always back home and rely on an efficient tool is what keeps me going with my studies. Such a feature filled and bug free program is reason enough to be proud.

[Alexandre Courbot]

Thanks for the kind words - I am afraid I have to decline the "bug free" compliment though. ;)

Anyway, hopefully some day you will be able to use Tagaini on your mobile, too!

[Mylène JOSSERAND]

Hi Alexandre,

>
> Hopefully. I started Tagaini for my own Japanese studies, as I wanted
> a tool that helps me find, organize, and practice vocabulary and
> kanji, while showing as many connections between entries as possible
> to facilitate memorization. Although some time has passed, I have yet
> to find a free tool that connects data that way.
>

hum, I am not so far with my Japanese studies ! :)
I know the Hiragana pretty well and some Kanji but I have to learn Katakana and
much more Kanji !
Tagaini helps me for the practice part. This is what is missing in other
applications. I have tested KanaTest for example. But I can not practise kanji
and katakana and hiragana and also, customise to practise "vocabulary" !
I really like the animation to show how write kanji and to split the different
part of it ! This is very cool =)


During my first test, to be honest, I was a little lost with the different
lists. In fact, I did not understand that the list view in left side was
different from the study list. I was expecting to get the study list printed
here. Now, I get it ! But I was lost to add kanji in the study list and not
seeing them in the list view. I do not know if you see what I mean. Maybe the
study list could be printed in the list view ? I think you should have your
reasons to do it like this. So I was wondering, why did you print the study list
in a different way than the others list ?

>
> Be aware that there will be a crash once in a while when you run the
> program from the qt5 branch. To workaround this, just fix it again. It
> is a bug in the update checking code (that runs once a day) that I
> haven't yet fixed.
>

Yes I noticed it !
I fixed it in the Qt code last week. I successed to compile kanjidic, jmdict and
tagaini.
It was an error during building kanjidic2. The XML parsing failed because some
contents were empty.
I do not know if my fix is enough (I add a test about empty data) because,
maybe, the bug is deeper and in the XML file side.
Should I send you a pull request of it or should I search deeper the cause of
the bug ? If you want more informations, ask me ! I can open another subject
about this "bug".

>
> QML did not exist at the time I was really active with Tagaini. ;) And
> while it is definitely fit for mobile, I am not convinced it is the
> best way to present data to desktop users?
>

Hum, the GUI will be more "simple" because of Mobile constraints but I think it
can fit for a Desktop use.
With QML, it is easy to create some GUI, with the Qt Quick Designer, just to see
what can be done. I can design some "empty" GUI if you want. You will see if you
did not like it for Desktop use.

>
> Thanks for the link, I will watch this with interest.

You are welcome

>
> And yes, I am French. I'm just so glad the people on this list cannot
> *hear* our English. :P

Ah ah ! I agree with you ! Let's say it is our "French touch" ;)

>
> Point taken about the requirement of 3rd party libraries for
> Javascript. And I don't feel like doing everything on the bare metal
> either.

I understand.

>
> Well, I intent to rework the DB design and core architecture anyway,
> so there will be a rewrite to some extent. I thought it might also be
> the opportunity to add portability by switching languages.
>

Ah okay ! So you planned to rewrite many parts.

>
> That's tempting, especially when you consider why I chose Qt in the
> first place. See, when I started Tagaini back in 2008, the world was a
> different place: people still used their desktop or laptop machine
> primarily, so you just had to support Windows, MacOS and Linux to
> cover virtually every user. Qt was the silver bullet.
>
> Fast-forward 5 years, and the world is a mess again: iOS and
> Objective-C, Android and Java, of course no one using the same
> frameworks, and you still must support desktop on top of that (and
> sync between them all). Things are muuuch harder now, and despite its
> efforts to adapt to the mobile world, Qt comes from a very different
> time. My rationale for JS was that all these platforms can at least
> support a small C layer (SQLite and other required native functions),
> and can all interpret Javascript. But as you pointed out, you would
> then need to come with a different GUI for all of them, that's the
> disadvantage compared to QML.
>

Yes, I agree, now, it is very more complex to be multi-platform.
Well, QML can also interact with Javascript :
https://qt-project.org/doc/qt-5-snapshot/qtqml-javascript-expressions.html
I do not know if we can use a all javascript-core instead of a C++ core. I will
search deeper.

> At the risk of infuriating some people, and to be fully honest, I
> don't really care about iOS at this point. What I am more interested
> in, and which I haven't seen in the list of platforms supported by Qt,
> is Chrome OS. But here it seems like we would need a fully HTML
> interface or something like that.
>

Okay, I understand this part. I am not interesting about iOS either ;) But many
people have an iPhone so I guess we will have to develop for it.
For me, I have a Firefox OS so I have the same "problem" because all is written
in HTML5. I agree that it is not supported by QML at this point.

I have seen that some people tried to porting QML into web :
qt-project.org/forums/viewthread/4347/
In the last Qt version (5.4
http://www.qt.io/qt5-4/?utm_source=qtproject&utm_medium=banner&utm_campaign=
qt54release#section-16), Qt adds the possibility to handle Windows phone. So it
is now possible to develop applications on Android, iOS and Windows phone. They
are also working on web engine and the web view :
http://doc.qt.io/qt-5/qtwebview-index.html. I hope that the next platforms
handled will be HTML5 based OS like Chrome OS and Firefox OS ! ;)

> Actually exploring the feasability of QML would be a great thing to
> try, if you don't know what to do. ;) It is one of my great shames in
> life that Tagaini does not support mobile platforms yet, and any step
> that could help going forward in that direction is probably the best
> contribution one can make at this point.
>

Okay, let's do it !
I will try the feasability of QML.
If you agree, I will send you some QML "empty" design to see if it could
interest you and I will see what can be done.

As I wanted, in first place, develop my own japanese learning application, I
have "my" idea of what GUI I was waiting for.
This is "my idea" so it will be different than yours and, maybe, they are not
good ideas :) But I can design some QML gui to talk about it. What do you think
? And I will look deeper at QML and all its possibilities !

>
> I think this mailing-list is fine - it is not targeted at users in
> particular, and the volume is low, so please feel free to ask
> questions and have technical discussions here. Having the discussions
> public might also trigger other potential contributors, or people with
> experience doing mobile apps.

Okay, I will ask/send questions/proposals on this mailist.

>
> In any case, please don't hesitate asking questions, and please also
> don't hesitate to fork the project on Github and to submit pull
> requests for bug fixes/new features. There's nothing better to get
> started, and it's also more fun this way.
>

Okay, thank you !
I have cloned your project but I am new to github so I forgot to fork it.
I have already fix the Qt5 bug as I mention above but I do not know if the bug
reflect a XML problem so my "fix" can, maybe, avoid some part of it.
I have also, some features to propose but I do not know if they can interest you
and Tagaini's users !
Should we talk about it before I start to develop it or is it fine for you to
send you directly pull requests with new features ?


Cheers,

Mylène

[Alexandre Courbot]

Hi Mylène, and happy new year everyone! Sorry (again) for the delayed
reply. You know, end-of-year celebrations and shit.

On Sun, Dec 21, 2014 at 8:58 PM, Mylène JOSSERAND
<josseran...@gmail.com> wrote:
>> Hopefully. I started Tagaini for my own Japanese studies, as I wanted
>> a tool that helps me find, organize, and practice vocabulary and
>> kanji, while showing as many connections between entries as possible
>> to facilitate memorization. Although some time has passed, I have yet
>> to find a free tool that connects data that way.
>>
>
>
>
> hum, I am not so far with my Japanese studies ! :)
> I know the Hiragana pretty well and some Kanji but I have to learn Katakana and
> much more Kanji !
> Tagaini helps me for the practice part. This is what is missing in other
> applications. I have tested KanaTest for example. But I can not practise kanji
> and katakana and hiragana and also, customise to practise "vocabulary" !

Although the current GUI probably reflect that fact poorly, I view
Tagaini as a Japanese study assistant (and not a dictionary) designed
to help with three important phases of learning:

1) Finding what you want to study. It should be easy to find entries
you want or need to remember, either because they are the logical next
steps in your study (e.g. kanji made of components you already master
and which are part of vocabulary you already know), or because you
stumble upon a word and need to look it up despite it being made of
kanji you don't know (e.g. the Ctrl-k kanji input method which is
probably the most underexploitd feature of Tagaini).

2) Connecting the new entries to study with those you already know to
help their memorization, and keeping them in its database so you will
be remembered of them the next time you meet them in another context
(e.g. a kanji you are trying to remember that shows up in a new word
you just looked up).

3) Providing means to practice the entries you want to remember, and
consolidate their memorization. The current practice mode does a
decent job at it, but should be improved with a spaced-repetition
engine. The printable booklets are a very outdated way to practice on
the mode, and should be replaced by a decent mobile app.

> I really like the animation to show how write kanji and to split the different
> part of it ! This is very cool =)

Yet there is sooo much more things that can be done on top of this
basic animation feature. I dream that someday, someone will implement
the ideas in Jeroen Hoek's brilliant thesis
(http://handle.jeroenhoek.nl/files/hoek_2009.pdf ). All the data is
already here.

> During my first test, to be honest, I was a little lost with the different
> lists. In fact, I did not understand that the list view in left side was
> different from the study list. I was expecting to get the study list printed
> here. Now, I get it ! But I was lost to add kanji in the study list and not
> seeing them in the list view. I do not know if you see what I mean. Maybe the
> study list could be printed in the list view ? I think you should have your
> reasons to do it like this. So I was wondering, why did you print the study list
> in a different way than the others list ?

There is no "study list" per say - just entries that you marked as
"studied", and which you can later retrieve by making the appropriate
query. This, together with the "Add to study list" menu entry, indeed
gives the misleading impression that there is an actual "study list".
The wording probably deserves to be changed here, and the interface is
certainly old and sub-optimal. That's mostly because I am a kernel
engineer for a living, with very little UI experience - IOW, I just
suck at making UIs!

The left list is just an ordered, hierarchical list in which you can
put anything you like, in the order you like. It is useful to keep
track of e.g. entries in a book - you can have sublists for each
chapter, and keep the entries in their order of appearance. Having
entries in this list does not require you to have them marked as
"studied".

> Yes I noticed it !
> I fixed it in the Qt code last week. I successed to compile kanjidic, jmdict and
> tagaini.
> It was an error during building kanjidic2. The XML parsing failed because some
> contents were empty.

Ah, right. Interestingly the crash does not occur with the Qt4 branch.

> I do not know if my fix is enough (I add a test about empty data) because,
> maybe, the bug is deeper and in the XML file side.
> Should I send you a pull request of it or should I search deeper the cause of
> the bug ? If you want more informations, ask me ! I can open another subject
> about this "bug".

Please send a pull request! Even if it is not the "right" fix, it will
provide information about what is going wrong. And from there we can
work incrementally until we reach a proper fix.

>> QML did not exist at the time I was really active with Tagaini. ;) And
>> while it is definitely fit for mobile, I am not convinced it is the
>> best way to present data to desktop users?
>>
>
> Hum, the GUI will be more "simple" because of Mobile constraints but I think it
> can fit for a Desktop use.
> With QML, it is easy to create some GUI, with the Qt Quick Designer, just to see
> what can be done. I can design some "empty" GUI if you want. You will see if you
> did not like it for Desktop use.

Sure, please do so, especially if it does not require too much of your
time. My only constraints are that I would like to keep the workflow I
described above (find, keep, and train entries). Apart from that, I
leave it to you to come with a better UI than what I did (which should
not be too hard).

I am really happy that you are willing to give this a shot, to be
honest. Tagaini's internals are somehow ok, but the UI is really,
really getting old, and it was not so good to begin with anyway. So
please consider you have a blank check for this.

>> Well, I intent to rework the DB design and core architecture anyway,
>> so there will be a rewrite to some extent. I thought it might also be
>> the opportunity to add portability by switching languages.
>>
>
> Ah okay ! So you planned to rewrite many parts.

Yeah, now will I *actually* do it, that's another story... >_< I
really want to, though.

>> At the risk of infuriating some people, and to be fully honest, I
>> don't really care about iOS at this point. What I am more interested
>> in, and which I haven't seen in the list of platforms supported by Qt,
>> is Chrome OS. But here it seems like we would need a fully HTML
>> interface or something like that.
>>
>
>
> Okay, I understand this part. I am not interesting about iOS either ;) But many
> people have an iPhone so I guess we will have to develop for it.

Yup, although as far as I am concerned this is in the "nice to have" department.

> For me, I have a Firefox OS so I have the same "problem" because all is written
> in HTML5. I agree that it is not supported by QML at this point.

Ah! I have not mentioned Firefox OS because I could not guess you were
a user, but this is also a platform I would like to see supported, if
only by principle! Well here it is again a matter of having a HTML+JS
interface, same as Chrome OS.

So if we summarize what we want to see supported, and the options we
current have:

- desktop version, Qt UI
- desktop version, HTML+ JS (ChromeOS)
- mobile version, QML (Android, iOS?)
- mobile version, HTML + JS (Firefox OS)

... or 4 different UIs. And of course we need a core under the UI, and
at the moment the C++/Qt core can only support the Qt/QML UI. This is
really not a simple choice, but I would like to be able to minimize
code duplication and at least reuse the same core (writing different
UIs is of course cumbersome, but more acceptable). And at the moment I
don't think C++/Qt are viable runtimes for Firefox OS and Chrome OS.
The only common denominator would be Javascript, hence my idea of
rewriting the core using it, and having the UI call into it, no matter
what language it is written in.

>
> I have seen that some people tried to porting QML into web :
> qt-project.org/forums/viewthread/4347/

Nice - this would at least cover the UI part. The C++ core would still
be an issue.

> In the last Qt version (5.4
> http://www.qt.io/qt5-4/?utm_source=qtproject&utm_medium=banner&utm_campaign=
> qt54release#section-16), Qt adds the possibility to handle Windows phone. So it
> is now possible to develop applications on Android, iOS and Windows phone. They
> are also working on web engine and the web view :
> http://doc.qt.io/qt-5/qtwebview-index.html. I hope that the next platforms
> handled will be HTML5 based OS like Chrome OS and Firefox OS ! ;)

Me too, that's really the last bit that is missing for Qt to be truly
cross-platform again. We can gamble that HTML will be a supported
platform at some point, and concentrate on Qt/QML which will at least
cover the three major desktops and Android for now. Having the core in
C++ would still be an issue for environments that expect pure HTML
apps though.

>> Actually exploring the feasability of QML would be a great thing to
>> try, if you don't know what to do. ;) It is one of my great shames in
>> life that Tagaini does not support mobile platforms yet, and any step
>> that could help going forward in that direction is probably the best
>> contribution one can make at this point.
>>
>
>
>
> Okay, let's do it !
> I will try the feasability of QML.
> If you agree, I will send you some QML "empty" design to see if it could
> interest you and I will see what can be done.

Yes, having a basis to discuss on would be great. Please don't hold
back if you want to make major changes to the UI.

> As I wanted, in first place, develop my own japanese learning application, I
> have "my" idea of what GUI I was waiting for.
> This is "my idea" so it will be different than yours and, maybe, they are not
> good ideas :) But I can design some QML gui to talk about it. What do you think
> ? And I will look deeper at QML and all its possibilities !

I think that it would be great to seed some new ideas into Tagaini, so
please feel free to come with what you feel is appropriate. I (and
hopefully others too) will then play my role as the old fart in charge
and grumble about what may break the core objectives of the app. After
a few sessions of ping-pong, I am confident that we will reach a good
design that will make everyone happy - at least, that's what my
experience with OSS projects have taught me so far: reasonable people
confronting ideas always result in something that is better than the
sum of the individual proposals. So, don't hold back, be creative, and
break everything - after 6 years of existance, it is time for Tagaini
to get a solid refresh.

It is also my hope that with time you will start seeing Tagaini as
being "your" app too - in the OSS world, app ownership comes with
contributions, and a UI overhaul would be a huge contribution indeed.

Cheers,
Alex.

[Mylène JOSSERAND]

Le jeudi 1 janvier 2015 19:29:32 UTC+1, Alexandre Courbot a écrit :

Hi Mylène, and happy new year everyone! Sorry (again) for the delayed
reply. You know, end-of-year celebrations and shit.

Hi Alexandre !
Thank you, happy new year too !

 

Although the current GUI probably reflect that fact poorly, I view
Tagaini as a Japanese study assistant (and not a dictionary) designed
to help with three important phases of learning:

1) Finding what you want to study. It should be easy to find entries
you want or need to remember, either because they are the logical next
steps in your study (e.g. kanji made of components you already master
and which are part of vocabulary you already know), or because you
stumble upon a word and need to look it up despite it being made of
kanji you don't know (e.g. the Ctrl-k kanji input method which is
probably the most underexploitd feature of Tagaini).

2) Connecting the new entries to study with those you already know to
help their memorization, and keeping them in its database so you will
be remembered of them the next time you meet them in another context
(e.g. a kanji you are trying to remember that shows up in a new word
you just looked up).

3) Providing means to practice the entries you want to remember, and
consolidate their memorization. The current practice mode does a
decent job at it, but should be improved with a spaced-repetition
engine. The printable booklets are a very outdated way to practice on
the mode, and should be replaced by a decent mobile app.

Okay, thank you for the explanation. I will try to keep in mind this workflow !

 

> I really like the animation to show how write kanji and to split the different
> part of it ! This is very cool =)

Yet there is sooo much more things that can be done on top of this
basic animation feature. I dream that someday, someone will implement
the ideas in Jeroen Hoek's brilliant thesis
(http://handle.jeroenhoek.nl/files/hoek_2009.pdf ). All the data is
already here.

Thank you for the document, I will take time to read it. It seems very interesting.


 

There is no "study list" per say - just entries that you marked as
"studied", and which you can later retrieve by making the appropriate
query. This, together with the "Add to study list" menu entry, indeed
gives the misleading impression that there is an actual "study list".
The wording probably deserves to be changed here, and the interface is
certainly old and sub-optimal. That's mostly because I am a kernel
engineer for a living, with very little UI experience - IOW, I just
suck at making UIs!

okay, I understand. Tagaini's GUI is not bad ! It is just difficult to use it  the first time but once you understand the workflow, it is okay
For me, it is the opposite : I first learnt GUI and now, I would like to study kernel develpment :)

 

The left list is just an ordered, hierarchical list in which you can
put anything you like, in the order you like. It is useful to keep
track of e.g. entries in a book - you can have sublists for each
chapter, and keep the entries in their order of appearance. Having
entries in this list does not require you to have them marked as
"studied".

Understood

Ah, right. Interestingly the crash does not occur with the Qt4 branch.

 

Please send a pull request! Even if it is not the "right" fix, it will

provide information about what is going wrong. And from there we can
work incrementally until we reach a proper fix.

Done :)
 

Sure, please do so, especially if it does not require too much of your
time. My only constraints are that I would like to keep the workflow I
described above (find, keep, and train entries). Apart from that, I
leave it to you to come with a better UI than what I did (which should
not be too hard).

I am really happy that you are willing to give this a shot, to be
honest. Tagaini's internals are somehow ok, but the UI is really,
really getting old, and it was not so good to begin with anyway. So
please consider you have a blank check for this.

Thank you very much for your trust. I have already think about some improvements but I prefer work on paper before developing anything. I am also working on the QML feasability. I will be back when I will have more information.

 

Yeah, now will I *actually* do it, that's another story... >_< I
really want to, though.

No problem, I understand :)

 


Ah! I have not mentioned Firefox OS because I could not guess you were
a user, but this is also a platform I would like to see supported, if
only by principle! Well here it is again a matter of having a HTML+JS
interface, same as Chrome OS.

Cool !

So if we summarize what we want to see supported, and the options we
current have:

- desktop version, Qt UI
- desktop version, HTML+ JS (ChromeOS)
- mobile version, QML (Android, iOS?)
- mobile version, HTML + JS (Firefox OS)

... or 4 different UIs. And of course we need a core under the UI, and
at the moment the C++/Qt core can only support the Qt/QML UI. This is
really not a simple choice, but I would like to be able to minimize
code duplication and at least reuse the same core (writing different
UIs is of course cumbersome, but more acceptable). And at the moment I
don't think C++/Qt are viable runtimes for Firefox OS and Chrome OS.
The only common denominator would be Javascript, hence my idea of
rewriting the core using it, and having the UI call into it, no matter
what language it is written in.

Yes, this is very more simple to develop different GUI instead of different cores.
I will see how it is handled but I am wondering if it is not possible to have only 3 different GUIs :

• QML for Desktop version, Android, IOS, Windows phone( ?)
• desktop version HTML + JS (Chrome OS)
• mobile version, HTML + JS (firefox OS)
  

I am currently trying to configure QtCreator to get it working for android. I want to see if a "Desktop" QML interface could be used on a "Android" phone without further developments.

Nice - this would at least cover the UI part. The C++ core would still
be an issue.

Me too, that's really the last bit that is missing for Qt to be truly
cross-platform again. We can gamble that HTML will be a supported
platform at some point, and concentrate on Qt/QML which will at least
cover the three major desktops and Android for now. Having the core in
C++ would still be an issue for environments that expect pure HTML
apps though.

Yes, it's true. The core seems to be an "issue".

Yes, having a basis to discuss on would be great. Please don't hold
back if you want to make major changes to the UI.

Thank you again for your trust.

I think that it would be great to seed some new ideas into Tagaini, so
please feel free to come with what you feel is appropriate. I (and
hopefully others too) will then play my role as the old fart in charge
and grumble about what may break the core objectives of the app. After
a few sessions of ping-pong, I am confident that we will reach a good
design that will make everyone happy - at least, that's what my
experience with OSS projects have taught me so far: reasonable people
confronting ideas always result in something that is better than the
sum of the individual proposals. So, don't hold back, be creative, and
break everything - after 6 years of existance, it is time for Tagaini
to get a solid refresh.

I agree that it will be great to get a ping-pong sessions.
As soon as I will progress on "new" GUI, I will post some proposals on the mail list to get feedbacks on it.


Best regards,

Mylène