mcclim-devel

mcclim-devel@common-lisp.net

820 discussions

Stuck trying to get this to build in AppVeyor, think it's related to the TrueType setup error in Windows
by pouar＠pouar.net 04 Sep '18

04 Sep '18

Sent this message earlier, but I wasn't sure if it showed up without subscribing to the mailing list as I didn't see it show up on the page, so I subscribed and sent it again Tried wrapping it in handler-case but it doesn't seem to be working on AppVeyor Console output https://ci.appveyor.com/project/pouar/appveyor-test/build/1.0.25 Script used to install dependencies as AppVeyor might expect this to be separate https://gitlab.com/pouar/appveyor-test/blob/d889e5109ec5a56e52e875b8a125e0d… Script for building https://gitlab.com/pouar/appveyor-test/blob/d889e5109ec5a56e52e875b8a125e0d… -- GPG Keys: https://keybase.io/pouar

1 0

text-field-pane
by José Ronquillo 07 Aug '18

07 Aug '18

Hello everyone. I am trying to use the keys of the keypad to enter numbers in a text-input-pane; I have traced the problem to the function x-event-to-key-name-and-modifiers located in Backends/CLX/keysyms.lisp; what I see is that the function returns the first value (the keyname) as nil. Does anyone else have problems using the keypad?

1 0

Re: gesture docs?
by Orm Finnendahl 06 Aug '18

06 Aug '18

Hi, just FYI (if someone googles this question...): After some code inspection I found out that the "cut-and-paste-mixin" sends pointer-events in its dispatch-event :around method to eos/shift-click if the shift key is pressed. This seems related to some historic semantics of shift-click behaviour for setting and dragging points as explained in the "text-selection.lisp" file. I couldn't find anything in the clim specific docs. May it'd be sensible to add this information (maybe at bauhh.dyndns.org?). -- Orm

2 3

gesture docs?
by Orm Finnendahl 05 Aug '18

05 Aug '18

Hi, is there any documentation on pointer-gestures in mcclim? This doesn't seem to work: (define-gesture-name :multiple-select :pointer-button-press (:left :shift)) whereas this works: (define-gesture-name :multiple-select :pointer-button-press (:left :control :shift)) :wheel-up and :wheel-down seems to be bound to scrolling a (scrollable) pane using mouse-wheel-scroll-mixin and I don't know how to override this. This also doesn't seem to work: (define-gesture-name :up :pointer-scroll (:wheel-up :shift)) (define-gesture-name :down :pointer-scroll (:wheel-down :control)) I found out that all mouse and keypress events are received in #'process-next-event, so X actually transfers them to mcclim. Is the exact name of the gestures/modifiers somewhere documented (and also how to make them work?) -- Orm

2 1

Re: gesture docs?
by Orm Finnendahl 03 Aug '18

03 Aug '18

Hi, just to be more specific: I'm well aware of the documentation on bauhh.dyndns.org and the clim specs of Lispworks and Franz, but apart from being seemingly different, they also don't mention the scroll-wheel and the modifiers of :pointer-button don't seem to work as expected on my machine. -- Orm ----- Forwarded message from Orm Finnendahl <orm.finnendahl(a)selma.hfmdk-frankfurt.de> ----- Subject: gesture docs? From: Orm Finnendahl <orm.finnendahl(a)selma.hfmdk-frankfurt.de> To: mcclim-devel(a)common-lisp.net Date: Fri, 3 Aug 2018 19:33:26 +0200 Hi, is there any documentation on pointer-gestures in mcclim? This doesn't seem to work: (define-gesture-name :multiple-select :pointer-button (:left :shift)) whereas this works: (define-gesture-name :multiple-select :pointer-button (:left :control :shift)) :wheel-up and :wheel-down seems to be bound to scrolling a (scrollable) pane using mouse-wheel-scroll-mixin and I don't know how to override this. This also doesn't seem to work: (define-gesture-name :up :pointer-scroll (:wheel-up :shift)) (define-gesture-name :down :pointer-scroll (:wheel-down :control)) I found out that all mouse and keypress events are received in #'process-next-event, so X actually transfers them to mcclim. Is the exact name of the gestures/modifiers somewhere documented (and also how to make them work?) -- Orm ----- End forwarded message -----

1 0

x-coord not supplied in blank-area-click
by Orm Finnendahl 03 Aug '18

03 Aug '18

Hi, the x coordinate is nil when handling blank-area-clicks. This is how the chain is defined: (define-presentation-to-command-translator blank-area-click (blank-area com-blank-area-click clim-quo :gesture :select :echo nil) (x y) (list x y)) (define-clim-quo-command (com-blank-area-click :name nil) ((x 'real) (y 'real)) (handle-blank-area-click (find-pane-named *application-frame* 'canvas) x y)) (defun handle-blank-area-click (pane first-point-x first-point-y) (break "blank-area-click x: ~a, y: ~a~%" first-point-x first-point-y) ;;; (details omitted...) ) When clicking in a blank area of the pane handle-blank-area-click breaks with: blank-area-click x: nil, y: 140 The y coordinate is correct. I'm pretty sure it used to work, but the code is some years old and I'm unsure whether the api might have changed, but couldn't find anything. This happens with most recent quicklisp mcclim-20180711-git on arch linux running sbcl 1.4.8 under X11. Let me know if you need more details. Any help is appreciated! I might be able to work around it by determining the mouse position within the handler code, but this seems wrong to me... -- Orm ---------------------------------------------------------------------- Prof. Orm Finnendahl Komposition Hochschule für Musik und Darstellende Kunst Eschersheimer Landstr. 29-39 60322 Frankfurt am Main

2 1

highlight action
by Orm Finnendahl 02 Aug '18

02 Aug '18

Hi, another problem has occured: When mouse hovering over a presentation, the presentation's highlight method is called. When clicking, the unhighlight method is called before calling the click-handler. This is unfortunate in my use-case as I need the information, what was previously highlighted when reacting to the click method. Unfortunately this information is *not* always identical to the clicked presentation. Is there a way to suppress the unhighlighting prior to the invocation of the click handler to avoid explicitely calling the highlight method again within the click-handler? -- Orm ---------------------------------------------------------------------- Prof. Orm Finnendahl Komposition Hochschule für Musik und Darstellende Kunst Eschersheimer Landstr. 29-39 60322 Frankfurt am Main

1 0

Running on threads
by Greg Bennett 02 Jul '18

02 Jul '18

From Greg Bennett, running 64bit Mint 18.2 and sbcl 1.4.0 [should fix that!] I am trying to port a project using mcclim as the graphics machine. Using code from CLIM User Guide V2.2.2 P19: <START of CODE> (in-package :clim-user) (define-application-frame test () () (:panes (display :application)) (:layouts (default display))) (define-test-command (com-quit :menu t) () (frame-exit *application-frame*)) (defvar *test-frame* nil) (defun test () (flet ((run () (let ((frame (make-application-frame 'test))) (setq *test-frame* frame) (run-frame-top-level frame)))) (sb-thread::make-thread #'run :name "test") *test-frame*)) <END of CODE> and then (test), I can get a mcclim window in which I can draw while still having the sbcl listener alive. I'd like to learn how to create other instances of application frames on the same thread [named "test" in this case] Is it as simple as invoking clim:run-frame-toplevel again, for instance ? If there are pointers to mcclim's handling of threads, I'd be happy to learn of them. Thanks for advice and assistance, Cheers /GB ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Sbcl-devel mailing list Sbcl-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sbcl-devel

1 0

'clim:layout-frame called as each letter typed into interactor?
by John Morrison 18 Nov '17

18 Nov '17

Hi; The McCLIM app I am writing has both a pan/zoom application pane and an interactor pane. I am trying to track down why the top-level frame gets resized (radically - too big to fit the X11 screen) when things get drawn onto the canvas. Immediately upon tracing clim:layout-frame, I was surprised to see it (unexpectedly, to me) getting called as each letter it typed into the interactor pane - before I actually start drawing anything (much) onto the canvas/application pane. I am guessing that my output-record-producing drawing similarly triggers the layout protocol again... Is this expected behavior? I was hoping/expecting that the frame layout was computed a "final" time, and then I could draw onto one of its panes with impunity, counting on visible region clipping. If it is not expected behavior, I would be happy to try and track it down. If it is expected behavior, is there some way to prevent it? It is indeed strange for the application to "spontaneously" and dramatically change its size/realization on the screen. Thanks! -jm

2 2

dumb question about gadgets
by John Morrison 12 Nov '17

12 Nov '17

Hi; In another app I am writing, I BELIEVE gadgets used to come out stacked vertically. After an upgrade (to current git), I think they come out "diagonally," in that the x & y of successive gadgets increase (presumbly by the dimensions of its preceding gadget). Please find attached the simplest test program I could cons up that displays the behavior, along with a screenshot that shows the behavior. What is the idiomatic/best way to get them to stack vertically? I messed about (again, mostly unsuccessfully, or I wouldn't be pestering you all) with various approaches, but every time I find myself with a complex solution, it turns out there is indeed a Better, Simpler Way. Thanks, -jm

2 9

← Newer
1
...
4
5
6
7
8
9
10
...
82
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

mcclim-devel