I have created a simple McCLIM bug list at:
It is meant as a useful, lightweight resource for both users and developers. Usage, as described in the short instructions at the top, should be straightforward.
The only non obvious issue is the use of a NAME HTML tag, such as `my-bug', for each entry, This makes it possible to have URLs such as:
http://mcclim.cliki.net/Bug#my-bug
do the right thing and point the browser to the appropriate entry. Of course, I hope the page will not get long enough to make this feature useful :)
Since the mcclim-devel list is archived, I will repost old bug reports of mine, and add links from the bug list, so that they can now be permanently archived. If this is an inconvenience for you, just let me know and I will not do it.
Your feedback--better yet, your edits--is welcome.
Paolo
Paolo Amoroso writes:
I have created a simple McCLIM bug list at:
Great initiative! Thanks!
Paolo Amoroso amoroso@mclink.it writes:
I have created a simple McCLIM bug list at:
I have added all the bugs reported to the mailing list in 2004 and not yet fixed. I guess most of the older ones were fixed in some way, and it would be a lot of work to check very old reports against current code. If there are still very old bugs, they will be probably "rediscovered".
Note that I have added entries only when I could do some kind of direct check, or I was sure from memory. I have deliberately left out from the list all bugs related to Lisp implementations or operating systems to which I have no access, most notably OpenMCL, Allegro CL and LispWorks. Users of those systems are encouraged to add more entries if appropriate.
Paolo
I played briefly with McCLIM (in CMUCL on linux) over the holidays, and now I have a list of niggles and whines. These are meant as constructive minor first-impressions criticisms, I realise fully things are still being actively developed! - McCLIM is generally quite cool.
I don't want to clutter the bug list page with them as several are vague and not necessarily bugs, but because I start work again tomorrow and probably won't have time to follow any up until next xmas or something, here follows brain dump for others to pick up on, or not:
1. Listener (shows symptoms anyway, problem may lie deeper): Super-key handling is broken? super key presses are detected, but any mouse movement or button press first seems to cancel the super key, thus making it impossible to use e.g. s-L
Xev shows X isn't at fault (I think) - can anyone confirm?
2. Listener: Tab key Completion. Completes after tab when you enter two or more characters, but puts in some sort of a "[]" nonprinting-character sign after one? Similarly, space-key completion doesn't after one character, only completes after two? Presumably this behaviour is a bug rather than a feature.
3. Listener: Completion - showing possibilities? like bash, or just by dropping down a keyboard-navigable variant of the right click menu?
4. Listener: deletion on the command line. Probably a feature that's coming just not implemented. Once the listener displays the e.g. "Show Class Subclasses (class)" , you can't "go back" with the backspace key anymore - it just outputs "(class)" again.
5. Listener: ability to "press enter" with the mouse? Huh? you say - well, it's like this - the last thing I select for a one-arg command is often something I click with the mouse (or in my case stylus, actually...). - maybe the current command line should be clickable to perform the action if it becomes valid, like previous command lines are once they're done once. While this might be computationally somewhat expensive, people have absurdly fast computers these days.
6. (whine) Text Selection. Yes, I realise it's a brand-new feature. But wouldn't it be nicer to use click v.s. drag discrimination rather than the unusual shift-key? i.e. if the mouse moves more than 10 pixels over the text while the LMB is down, assume it's a highlight action rather than a click action? (Of course, there's also drag-drop to worry about).
7. (wishlist note) Accessibility or at least keyboard gadget navigation...
8. (whine/opinion) Dialogs. "exit" and "abort" to me don't seem strongly differentiated enough - exit really doesn't say to me "exit and use these values". Yes, they're in the spec as the defaults (which is probably enough to decide it, I guess...), but e.g. "Accept" (or "Okay" or "Use") / "Cancel" would be so much more in-line with modern usage.
9. Look-and-feel: Antialiased fonts on linux by default. Yes, XRENDER etc. lowlevel support belongs in clx distribution, not McCLIM - but if it is available, McCLIM should really default to it at this stage on linux, IMHO. Again, this is probably planned, but hey.
On Jan 3, 2005, at 8:51 AM, David Golden wrote:
- Look-and-feel: Antialiased fonts on linux by default. Yes,
XRENDER etc. lowlevel support belongs in clx distribution, not McCLIM - but if it is available, McCLIM should really default to it at this stage on linux, IMHO. Again, this is probably planned, but hey.
XRENDER doesn't do antialiased fonts; it simply has protocol primitives for drawing with alpha blending. All applications which use XRENDER to display antialiased fonts are also using the Freetype library (in the form of libXft) to do the displaying, which requires a nontrivial amount of FFI.
Now, there is a FFI binding to Freetype in the Experimental section, but it's for CMUCL only and I have no idea how to use it. IWBNI this worked on both SBCL and CMUCL, and maybe even used UFFI. The other option is to use Xach Beane's truetype-in-lisp to parse a few fonts and convert them to curves which can be loaded and displayed with no FFI. The Bitstream Vera family of fonts is under an open license for the GNOME project; dumping these in some kind of sexpr format describing the curves shouldn't be too hard, but drawing them is another matter. -- Brian Mastenbrook http://www.iscblog.info/ http://www.cs.indiana.edu/~bmastenb/
On Monday 03 January 2005 15:26, Brian Mastenbrook wrote:
Now, there is a FFI binding to Freetype in the Experimental section, but it's for CMUCL only and I have no idea how to use it. IWBNI this worked on both SBCL and CMUCL, and maybe even used UFFI.
Indeed. Hey, another thing that would be a distinctly nontrivial amount of work would be FFI and McCLIM backend for Cairo. :-) http://cairographics.org/
David Golden david.golden@oceanfree.net writes:
- Listener: deletion on the command line. Probably a feature that's
coming just not implemented. Once the listener displays the e.g. "Show Class Subclasses (class)" , you can't "go back" with the backspace key anymore - it just outputs "(class)" again.
Real men use Emacs keybindings :)
You can delete the whole line with C-u, or the word to the left of the cursor with M-Backspace. Or you may use the following:
1) C-b or M-b to move the cursor left 2) C-d or C-k to delete part or all of the rightmost part of the line
Paolo
On Monday 03 January 2005 16:07, Paolo Amoroso wrote: y use the following:
- C-b or M-b to move the cursor left
Well, yes, but... try this - with the "(class)" hint up, press C-b once, then press backspace (<-) - once the editing has "gotten started" with C-b, the backspace works! But backspace can't initiate the deletion once the "(class)" hint is up (it can until the hint is displayed).
-
Brian Mastenbrook -
David Golden -
Paolo Amoroso -
Robert Strandh