Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
To mitigate this problem I think we should only offer a view of the
symbols in current category. That's what MSWord and OO Writer do AFAIK.
We already have that.
This is new then... I guess you read my mind ;-)
It doesn't help, though, since the categories need to be
calculated nevertheless (the combo is still needed).
Of course.
What we can do is to unconditionally fill in all categories when we are using
utf8. This should save some time.
Or we could fill in all category once and for all at construction and
then filter the displayed category depending on the encoding used.
2. lots of symbols are missing in the dialog. This is a general
problem: if Qt cannot find a glyph in the font database, it inserts a
white rectangle. I think we should insert something more remarkable
(a red question mark or something), but I do not know how to check if
a glyph is available.
In the Qt doc, I see that they just use blank squares in the
CharacterWidget example:
http://doc.trolltech.com/4.2/widgets-charactermap.html
You could probably take inspiration from this example.
Rather than this, we could use a QTableView. KCharSelect does this (but it
involves proper model/view implementation, which is new land to me).
Yes, using a View/Model is always better than using the convenience
Widget class that Qt is providing (like QListWidget).
If we had access to something like python's unicodedata in C++, we
could also add nice tooltips displaying the name of the glyph.
Ideas welcome.
Ideas in no particular order:
- The information brought by QFontDatabase::writingSystem() seems
interesting to display.
Hm, perhaps. Not sure.
- We should also try to change the font used as a function of the
selected category.
I don't understand this.
I mean the font used in the symbolsLW list widget. Depending on the code
range we can choose this or that font for display using
QListWidgetItem::setFont(). Some fonts are appropriate for Latin1, some
others for Symbols, others for Arabic, etc. Of course this means that we
maintain a codepoint / font correspondence table somewhere like what we
do for the modern fonts for math.
- Now is probably a very good time to look at the stix fonts for GUI
purpose.
well, I believe that when I see it.
I am not talking about LateX, only about GUI. Some project (matplotlib)
are already making use of the fonts with success. I am talking about
getting rid of the modern fonts (the Bakoma package).
Abdel.
