From ziga.lenarcic at gmail.com Mon Nov 2 15:32:28 2009 From: ziga.lenarcic at gmail.com (=?UTF-8?Q?=C5=BDiga_Lenar=C4=8Di=C4=8D?=) Date: Mon, 2 Nov 2009 16:32:28 +0100 Subject: [mcclim-devel] A few questions Message-ID: <0D1F9165-5D18-4406-9725-297442B57325@gmail.com> Hi McCLIM developers! I have a few questions, in no particular order: * I've started 'theming' McCLIM to give it a more modern look (a darker look).. I've started with /Looks/pixie.lisp and went from there. Is pixie.lisp an example of 'correct' skinning process - effectively creating new classes with overridden methods for various things or is it better to just redefine the handle-redraw methods of original gadgets and be done with it? Pixie has a problem for instance - mouse wheel scrolling doesn't work, because it reimplements scrolling logic implemented in gadgets.lisp or somewhere else. Wouldn't it be more correct to use the 'default' logic and only redefine handle-repaint methods, if change in functionality isn't needed? * what is the correct way to add my own widgets? I assume I should look at gadgets.lisp and start from there. Are new widgets welcome in the main McCLIM source tree or is McCLIM closely following some CLIM specification and doesn't want to go beyond that? * I'm using CLX backend and default/freetype/truetype font renedering. I've noticed that with default X11 font rendering, the usual textstyle (sans-serif, roman) is much more readable at size :small, than :normal. For antialiased fonts, :normal works great. Perhaps the default fontsize should be :small (or mcclim's clx default font render should just interpret :normal as :small) - clim- examples applications would look nicer out of the box and I wouldn't need to write cases in my app (if ''freetype'' :normal :small) to make stuff look nice. I think this has been mentioned before.. * right now McCLIMs 'textfield' is vastly different from text fields in other toolkits. I think we could conform better if the caret was just a line (not a block), if the caret blinked properly, if there was caret positioning via mouse click and if there was selection possible. I don't know how other McCLIM users feel about this - but if I added these features, would they be added to McCLIM? Would it be better to add a new 'gadget' for this 'modern' text field stuff? Regards, Ziga From ziga.lenarcic at gmail.com Mon Nov 2 15:54:44 2009 From: ziga.lenarcic at gmail.com (=?UTF-8?Q?=C5=BDiga_Lenar=C4=8Di=C4=8D?=) Date: Mon, 2 Nov 2009 16:54:44 +0100 Subject: [mcclim-devel] another question Message-ID: Hi! Here's my previos email I sent as a non-member: ---------------- Hi McCLIM developers! I have a few questions, in no particular order: * I've started 'theming' McCLIM to give it a more modern look (a darker look).. I've started with /Looks/pixie.lisp and went from there. Is pixie.lisp an example of 'correct' skinning process - effectively creating new classes with overridden methods for various things or is it better to just redefine the handle-redraw methods of original gadgets and be done with it? Pixie has a problem for instance - mouse wheel scrolling doesn't work, because it reimplements scrolling logic implemented in gadgets.lisp or somewhere else. Wouldn't it be more correct to use the 'default' logic and only redefine handle-repaint methods, if change in functionality isn't needed? * what is the correct way to add my own widgets? I assume I should look at gadgets.lisp and start from there. Are new widgets welcome in the main McCLIM source tree or is McCLIM closely following some CLIM specification and doesn't want to go beyond that? * I'm using CLX backend and default/freetype/truetype font renedering. I've noticed that with default X11 font rendering, the usual textstyle (sans-serif, roman) is much more readable at size :small, than :normal. For antialiased fonts, :normal works great. Perhaps the default fontsize should be :small (or mcclim's clx default font render should just interpret :normal as :small) - clim- examples applications would look nicer out of the box and I wouldn't need to write cases in my app (if ''freetype'' :normal :small) to make stuff look nice. I think this has been mentioned before.. * right now McCLIMs 'textfield' is vastly different from text fields in other toolkits. I think we could conform better if the caret was just a line (not a block), if the caret blinked properly, if there was caret positioning via mouse click and if there was selection possible. I don't know how other McCLIM users feel about this - but if I added these features, would they be added to McCLIM? Would it be better to add a new 'gadget' for this 'modern' text field stuff? Regards, Ziga ----------------- I have another question: * What's the state of unicode support with McCLIM. I guess this is backend specific, since SBCL supports unicode strings very nicely. I use McCLIM on Mac OS X and non ASCII keys don't produce anything in McCLIM. Perhaps this is a problem with Mac OS X's X11 server? I've looked into 'freetype' font rendering and (I think) it assumes that char-code is < 256. Is there any unicode support in McCLIM? Regards, Ziga From strandh at labri.fr Wed Nov 4 21:58:17 2009 From: strandh at labri.fr (Robert Strandh) Date: Wed, 4 Nov 2009 22:58:17 +0100 Subject: [mcclim-devel] A few questions In-Reply-To: <0D1F9165-5D18-4406-9725-297442B57325@gmail.com> References: <0D1F9165-5D18-4406-9725-297442B57325@gmail.com> Message-ID: <19185.63737.486682.559790@serveur5.labri.fr> I alread answered these questions on #lisp, but here goes for documentation purposes. > * I've started 'theming' McCLIM to give it a more modern look (a > darker look).. I've started with /Looks/pixie.lisp and went from > there. Is pixie.lisp an example of 'correct' skinning process - > effectively creating new classes with overridden methods for various > things or is it better to just redefine the handle-redraw methods of > original gadgets and be done with it? Pixie has a problem for > instance - mouse wheel scrolling doesn't work, because it > reimplements scrolling logic implemented in gadgets.lisp or somewhere > else. Wouldn't it be more correct to use the 'default' logic and only > redefine handle-repaint methods, if change in functionality isn't > needed? I haven't looked at pixie, but the way I would do this would be to make handle-repaint call something like theme-handle-repaint with an additional argument of type `skin' or `look' or `theme' or whatever. Inheriting from existing gadgets and overriding methods doesn't seem like the right approach. I might be wrong of course. > * what is the correct way to add my own widgets? I assume I should > look at gadgets.lisp and start from there. I think that's correct, yes. > Are new widgets welcome in > the main McCLIM source tree or is McCLIM closely following some CLIM > specification and doesn't want to go beyond that? Personally, I am in favor of more gadgets. They won't end up in the CLIM package, but that's no problem. CLIM was meant to be extended this way. If you make it a separate system (in the ASDF sense) then people can include it if they want. > * I'm using CLX backend and default/freetype/truetype font > renedering. I've noticed that with default X11 font rendering, the > usual textstyle (sans-serif, roman) is much more readable at > size :small, than :normal. For antialiased fonts, :normal works > great. Perhaps the default fontsize should be :small (or mcclim's clx > default font render should just interpret :normal as :small) - clim- > examples applications would look nicer out of the box and I wouldn't > need to write cases in my app (if ''freetype'' :normal :small) to > make stuff look nice. I think this has been mentioned before.. I have no right answer for you. Perhaps one day we can have a rendering system that would be anti-aliased and look good at low resolutions. Currently that is not the case. > * right now McCLIMs 'textfield' is vastly different from text fields > in other toolkits. I think we could conform better if the caret was > just a line (not a block), if the caret blinked properly, if there > was caret positioning via mouse click and if there was selection > possible. I don't know how other McCLIM users feel about this - but > if I added these features, would they be added to McCLIM? Would it be > better to add a new 'gadget' for this 'modern' text field stuff? I would commit those features as changes to the existing text field unless someone can give me good reasons not to. Regards, -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Wed Nov 4 22:03:59 2009 From: strandh at labri.fr (Robert Strandh) Date: Wed, 4 Nov 2009 23:03:59 +0100 Subject: [mcclim-devel] another question In-Reply-To: References: Message-ID: <19185.64079.805630.361299@serveur5.labri.fr> > I have another question: > > * What's the state of unicode support with McCLIM. I guess this is > backend specific, since SBCL supports unicode strings very nicely. I > use McCLIM on Mac OS X and non ASCII keys don't produce anything in > McCLIM. Perhaps this is a problem with Mac OS X's X11 server? I've > looked into 'freetype' font rendering and (I think) it assumes that > char-code is < 256. Is there any unicode support in McCLIM? There are two distinct issues, input and output. Output is relatively easy. If we use mcclim-freetype or mcclim-truetype, things work fine it seems. You just need a Unicode font with all the glyphs. For native X11 (bitmap I guess) fonts, it is more complicated, because such fonts are limited to 16-bit glyph numbers, so we need a system for creating groups of fonts and choices of fonts depending on code points that would render in a pleasant way, and I am told this is hard because it depends on the language. Input is trickier and depends on the backend. Our current problem is that the CLX backend doesn't support the XKEYBOARD extension (I am just repeating what others have told me here), so the McCLIM CLX backend doesn't either. Perhaps the good thing to do is to extend CLX with XKEYBOARD support. Regards, -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From _deepfire at feelingofgreen.ru Wed Nov 4 23:04:22 2009 From: _deepfire at feelingofgreen.ru (Samium Gromoff) Date: Thu, 05 Nov 2009 02:04:22 +0300 (MSK) Subject: [mcclim-devel] another question In-Reply-To: <19185.64079.805630.361299@serveur5.labri.fr> References: <19185.64079.805630.361299@serveur5.labri.fr> Message-ID: <20091105.020422.1008913975573204780._deepfire@feelingofgreen.ru> From: Robert Strandh > > I have another question: > > > > * What's the state of unicode support with McCLIM. I guess this is > > backend specific, since SBCL supports unicode strings very nicely. I > > use McCLIM on Mac OS X and non ASCII keys don't produce anything in > > McCLIM. Perhaps this is a problem with Mac OS X's X11 server? I've > > looked into 'freetype' font rendering and (I think) it assumes that > > char-code is < 256. Is there any unicode support in McCLIM? > > There are two distinct issues, input and output. > > Output is relatively easy. If we use mcclim-freetype or > mcclim-truetype, things work fine it seems. You just need a Unicode > font with all the glyphs. For native X11 (bitmap I guess) fonts, it > is more complicated, because such fonts are limited to 16-bit glyph > numbers, so we need a system for creating groups of fonts and choices > of fonts depending on code points that would render in a pleasant way, > and I am told this is hard because it depends on the language. > > Input is trickier and depends on the backend. Our current problem is > that the CLX backend doesn't support the XKEYBOARD extension (I am > just repeating what others have told me here), so the McCLIM CLX > backend doesn't either. Perhaps the good thing to do is to extend CLX > with XKEYBOARD support. I have posted patches to both CLX and McCLIM enabling XKB and layout switching about a year ago. Unfortunately, while they still apply, they appear to have bitrotten, and while the X layout switching keystroke appears to have effect, inputting any foreign character freezes McCLIM. If anyone wants to take it from where I left it, here goes. Sorry if it is an offensive way to publish that, but, for what it's worth, the changes can be accessed via git: git://git.feelingofgreen.ru/mcclim, 'xkb-support' branch and git://git.feelingofgreen.ru/clx, 'xkb-support' branch regards, Samium Gromoff -- _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From ziga.lenarcic at gmail.com Thu Nov 5 11:55:26 2009 From: ziga.lenarcic at gmail.com (=?utf-8?Q?=C5=BDiga_Lenar=C4=8Di=C4=8D?=) Date: Thu, 5 Nov 2009 12:55:26 +0100 Subject: [mcclim-devel] another question In-Reply-To: <20091105.020422.1008913975573204780._deepfire@feelingofgreen.ru> References: <19185.64079.805630.361299@serveur5.labri.fr> <20091105.020422.1008913975573204780._deepfire@feelingofgreen.ru> Message-ID: <3A1633E0-2B47-4244-8610-B8B4F10FCECE@gmail.com> On Nov 5, 2009, at 12:04 AM, Samium Gromoff wrote: > From: Robert Strandh >>> I have another question: >>> >>> * What's the state of unicode support with McCLIM. I guess this is >>> backend specific, since SBCL supports unicode strings very nicely. I >>> use McCLIM on Mac OS X and non ASCII keys don't produce anything in >>> McCLIM. Perhaps this is a problem with Mac OS X's X11 server? I've >>> looked into 'freetype' font rendering and (I think) it assumes that >>> char-code is < 256. Is there any unicode support in McCLIM? >> >> There are two distinct issues, input and output. >> >> Output is relatively easy. If we use mcclim-freetype or >> mcclim-truetype, things work fine it seems. You just need a Unicode >> font with all the glyphs. For native X11 (bitmap I guess) fonts, it >> is more complicated, because such fonts are limited to 16-bit glyph >> numbers, so we need a system for creating groups of fonts and choices >> of fonts depending on code points that would render in a pleasant >> way, >> and I am told this is hard because it depends on the language. >> >> Input is trickier and depends on the backend. Our current problem is >> that the CLX backend doesn't support the XKEYBOARD extension (I am >> just repeating what others have told me here), so the McCLIM CLX >> backend doesn't either. Perhaps the good thing to do is to extend >> CLX >> with XKEYBOARD support. > > I have posted patches to both CLX and McCLIM enabling XKB and layout > switching about a year ago. Unfortunately, while they still apply, > they appear to have bitrotten, and while the X layout switching > keystroke > appears to have effect, inputting any foreign character freezes > McCLIM. > > If anyone wants to take it from where I left it, here goes. > > Sorry if it is an offensive way to publish that, but, for what it's > worth, the changes can be accessed via git: > > git://git.feelingofgreen.ru/mcclim, 'xkb-support' branch > > and > > git://git.feelingofgreen.ru/clx, 'xkb-support' branch > > > regards, > Samium Gromoff > -- > _deepfire-at-feelingofgreen.ru > O< ascii ribbon campaign - stop html mail - www.asciiribbon.org I've looked at what you did in xkb-support. Turns out it was mostly a matter of defining additional keysyms in clx/keysyms.lisp. I don't know about XKB - from what I googled it doesn't matter - but I know near to zero about X in general. Anyways - I've converted http://www.cl.cam.ac.uk/~mgk25/ucs/keysym2ucs.c to CLX form. Btw this C file is probably the standard solution for unicode input in X clientwise - I've seen it in GLFW library which has crossplatform unicode input and has X11 as one of its backends. So when I add all these define-keysyms into clx/keysyms.lisp, unicode in McCLIM 'just works'. Let me elaborate: - if :mcclim-truetype is not loaded, you get an error ( .. not unsigned byte 8) - seems the default font rendering is not robust enough - it should just spit out black squares or something when (> char-code 255), rather than dying.. - if :mcclim-truetype is loaded, unicode input 'just works' in 'gadgets test's text editor! But it doesn't work in goatee test! I don't know enough about internals to tell what's wrong. -- another thing regarding CLX's conversion of keysyms->chars - the ASCII region of keysyms doesn't require a hashtable lookup and is the used most of the time. The conversion for ASCII region is trivial. I don't know how important this is performance-wise but if you look at the end of http://www.cl.cam.ac.uk/~mgk25/ucs/keysym2ucs.c -- it's probably best to do a check for ASCII region and return immediately, why waste cycles and memory lookups. Perhaps CLX requires a more general approach - I don't know, please tell me. Otherwise the C file is probably a good example how this should be done. CLX has a more general approach - in the hashtables there are lists stored, which again is not that efficient. Well perhaps the cost is negligible (or it is for SBCL! other lisps might be less efficient).. Please comment on this if you have experience hacking CLX - I'm interested in the rationale behing CLX's approach. I've attached the UTF-8 encoded converted C file .. the contents must be put at the end of clx/keysyms.lisp. Perhaps this should be included in the main CLX branch (if it even exists) since it looks like a pretty general solution for all unicode keys (better than every CLX user rolling his own version). Regards, Ziga From nikodemus at random-state.net Sat Nov 14 09:52:35 2009 From: nikodemus at random-state.net (Nikodemus Siivola) Date: Sat, 14 Nov 2009 11:52:35 +0200 Subject: [mcclim-devel] faster clim-clx:pixel-translator Message-ID: <633d72b0911140152q79ac513fkffc671d67c278b4e@mail.gmail.com> One of the reasons IMAGE-TO-XIMAGE is slow is that pixel translators are _really_ slow. Attached patch fixes this bit. (On SBCL at least -- presumably elsewhere as well.) Cheers, -- Nikodemus -------------- next part -------------- A non-text attachment was scrubbed... Name: faster-pixel-translator.patch Type: application/octet-stream Size: 2501 bytes Desc: not available URL: From poketo7878 at yahoo.co.jp Sun Nov 22 06:56:38 2009 From: poketo7878 at yahoo.co.jp (=?iso-2022-jp?B?GyRCPT01NRsoQiAbJEJiQ05nGyhC?=) Date: Sun, 22 Nov 2009 15:56:38 +0900 Subject: [mcclim-devel] How to use McCLIM on SnowLeopard with SBCL ? Message-ID: <654F498E-BE07-4E59-846D-02A3ABAA9C4F@yahoo.co.jp> Hello, I try to use McCLIM on Mac OSX SnowLeopard with latest version SBCL. I finished install mcclim and try to test program. (require 'clim-examples) (clim-demo::demodemo) Then I got Error like this: debugger invoked on a SB-BSD-SOCKETS:HOST-NOT-FOUND-ERROR: Name service error in "getaddrinfo": 8 (nodename nor servname provided, or not known) Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. (SB-BSD-SOCKETS::ADDRINFO-ERROR "getaddrinfo" 8) But I can't figure out why this error happen. Does anyone can solve this probrem? Pleas help me. Many Thanks.-------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/