Hi, I'm trying to learn CLIM, through McCLIM, from the ground up, but I'm having a slight problem with commands. The following example program shows the issue:
(in-package :clim-user)
(define-application-frame example-editor () () (:menu-bar menubar-command-table) (:panes (text-edit :text-editor)) (:layouts (default text-edit)))
(define-example-editor-command com-quit () (frame-exit *application-frame*))
(make-command-table 'file-command-table :errorp nil :menu '(("Quit" :command com-quit)))
(make-command-table 'menubar-command-table :errorp nil :menu '(("File" :menu file-command-table)))
The "Quit" menu option shows up just fine, but nothing happens when I click it. Why is this?
Furthermore, non-ASCII-input (the Danish special characters Æ, Ø and Å, for example) does not show up in the text-editor pane. I assume that McCLIM lacks support for this. Where would I want to look, if I am to hack up some support for this?
Troels Henriksen athas@sigkill.dk writes:
Furthermore, non-ASCII-input (the Danish special characters Æ, Ø and Å, for example) does not show up in the text-editor pane. I assume that McCLIM lacks support for this. Where would I want to look, if I am to hack up some support for this?
This is (unfortunately) a complicated problem.
The CLX functions for drawing text take a :translate keyword argument, for translating from characters to (font, glyph index) pairs. http://common-lisp.net/project/cmucl/doc/clx/6_7_Drawing_Text.html has much more detail about this; the default translate function simply maps ascii characters to their char-codes, and assumes that the font never changes.
So to hack support for Danish special characters, it might be as simple as finding a font that is encoded in iso-8859-1, making sure it's available on all X servers, using it in McCLIM, and writing a slightly less conservative translate-function. Of course, this won't get (say) the euro symbol to work, because that's not in the iso-8859-1 repertoire; it is in -15, but using that would mean losing some other characters.
So a more proper answer might be to find a font encoded in iso-10646-1, which is basically 16-bit Unicode. Typically, fonts don't actually have all 2^16 points filled, but at least the translate function for those is still relatively simple. Otherwise, one might need to use sets of fonts and change between them where necessary.
(All of this assumes that you're using the CLX backend, of course; I have no idea how any of this works in other backends...)
Cheers,
Christophe
Christophe Rhodes csr21@cam.ac.uk writes:
This is (unfortunately) a complicated problem.
Indeed it is. I've hacked a few things up in CLX that allows me to read Danish special characters from the keyboard. This was mostly about redefing `translate-default' and modifying *keysym->character-map* in CLX itself (as I said, a hack). It works in pure CLX-applications, but for some reason, not in McCLIM. Have I missed something? I've traced `lookup-keysym' in Backends/CLX/keysyms-common.lisp, and it appears to look up the characters alright, so I don't really understand what is wrong.
"TH" == Troels Henriksen athas@sigkill.dk writes:
TH> I've hacked a few things up in CLX that allows me TH> to read Danish special characters from the keyboard. This was TH> mostly about redefing `translate-default' and modifying TH> *keysym->character-map* in CLX itself (as I said, a hack). It TH> works in pure CLX-applications, but for some reason, not in TH> McCLIM.
Look for "non-ASCII" in the mailing list archive, June 2005. I've found a working Q&D way to input and display Czech characters in McCLIM using a Unicode font.
Regards,
Milan Zamazal
Milan Zamazal pdm@zamazal.org writes:
Look for "non-ASCII" in the mailing list archive, June 2005. I've found a working Q&D way to input and display Czech characters in McCLIM using a Unicode font.
Thank you. Based on your post, I was able to write some functions that solve the problem in a very simple way:
(defun fix-character (character keysym) "Setup character to work in CLX and McCLIM." (xlib::define-keysym character keysym) (goatee::add-gesture-command-to-table character 'goatee::insert-character goatee::*simple-area-gesture-table*))
(defun fix-danish-input () (fix-character #\æ 230) (fix-character #\Æ 198) (fix-character #\ø 248) (fix-character #\Ø 216) (fix-character #\å 229) (fix-character #\Å 197))
I also had to replace clim-clx::translate with the Unicode-capable translation function from Climacs.
I think this fix should be mentioned somewhere, since non-ASCII input is likely to be important to many people. Also, could this method be used as a general solution, or is it still a hack (apart from the low number of supported characters, of course)?
"TH" == Troels Henriksen athas@sigkill.dk writes:
TH> I think this fix should be mentioned somewhere, since non-ASCII TH> input is likely to be important to many people.
Perhaps it could be added to McCLIM Cliki?
TH> Also, could this method be used as a general solution, or is it TH> still a hack (apart from the low number of supported characters, TH> of course)?
I'm not competent to answer this question. But I'd like to assure McCLIM developers that any partially working solution is definitely much better than not to be able to use non-ASCII characters at all. Lack of very basic i18n support in McCLIM was one of the main reasons why I had to cowardly switch from McCLIM to GNOME Guile in one of my projects. :-|
Regards,
Milan Zamazal
Milan Zamazal pdm@zamazal.org writes:
"TH" == Troels Henriksen athas@sigkill.dk writes:
TH> I think this fix should be mentioned somewhere, since non-ASCII TH> input is likely to be important to many people.Perhaps it could be added to McCLIM Cliki?
It's here:
Paolo
On Dec 30, 2005, at 1:16 AM, Troels Henriksen wrote:
Hi, I'm trying to learn CLIM, through McCLIM, from the ground up, but I'm having a slight problem with commands. The following example program shows the issue:
(in-package :clim-user)
(define-application-frame example-editor () () (:menu-bar menubar-command-table) (:panes (text-edit :text-editor)) (:layouts (default text-edit)))
(define-example-editor-command com-quit () (frame-exit *application-frame*))
...
The "Quit" menu option shows up just fine, but nothing happens when I click it. Why is this?
The problem is that there is no application-pane (standard CLIM drawing area) or interactor-pane (used for entering commands), so the whole CLIM command infrastructure, which includes processing menu clicks, is effectively disabled. I need to ponder whether or not this is correct (I suspect not; the motivation was that with no *standard-input`* there would be no place from which to read commands, but that's obviously not correct in the presence of menus), but in the mean-time you want to conduct your experiments with application panes or interactor panes, or at the least add one of those panes to your application.
Tim
-
Christophe Rhodes -
Milan Zamazal -
Paolo Amoroso -
Timothy Moore -
Troels Henriksen