Thomas Fjellstrom: > I "think" I managed to get away with making sure Platform.h had a "#define > PLAT_QT 0" and lower down, a "#if defined(QT)".
OK, although I'd like to hear from Phil Thompson whether the changes are OK for QScintilla. > Also theres that ifdef PLAT_WX (int ascent) in the Font class, maybe it should > be a method? It is a protected cached value just used within wx's platform layer for performance. > Now, noone will mind if I use the scite lexer description files right? ;) If you mean the .properties files then some people use them in their encapsulation but they have never seen much design effort to make them useful for that purpose. > I'm also a little concerned that scintilla forces use of xpm's, it may be > possible to have Qt4 convert its QIcon/QPixmap's to an xpm, but it seems like > an extra step that needent be taken.. XPM is a quite simple format that should be convertible with your own code. Tunneling platform-specific pixmap objects and related data (some platforms like individual pixmaps, other pixmap sets and element IDs) exposes Scintilla to platform vagaries (transparency not supported or supported only through a specific key colour, no API to discover size or depth, resource management, etc). If you think you know enough about this area then I'd welcome an API design. XPM also has the benefit that code that uses pixmaps in Scintilla can be cross platform. > And Im confused about the little bit of unicode code in the Platform class.. > Qt natively supports unicode via its QString's, I'm just not sure how they > all fit together. There is no Unicode in the Platform class interface. There are some DBCS methods but they are for non-Unicode encodings of languages like Japanese Shift-JIS where a character may be 1 or 2 bytes. If you don't want to support these encodings, stub those calls. Neil _______________________________________________ Scintilla-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scintilla-interest
