Ferada/cl-cffi-gtk

Can't use positive Response ID's in GtkDialog

kierangrant opened this issue · 9 comments

kierangrant commented

gtk-response-type is defined as a foreign enum with fixed negative values.
But GTK Docs says all positive values or allowed and are reserved to the user.
The way gtk-response-type is implemented in gtk/gtk.dialog.lisp prevents this.
You get an error when setting response ID or if one is returned not within scope of:
"... is not defined as a value for enum type #<CFFI::FOREIGN-ENUM GTK:GTK-RESPONSE-TYPE>."
For example, in a signal handler for a custom widget in a dialog:

(defun preferencs->apply (widget)
  (declare (ignore widget))
  (format t "Applying Preferencs~%!")
  (gtk-dialog-response (get-handle :preferences :dialog) 1)

Errors when selecting the button associated with this callback.

Is there a way to define it so we can still use the enum technique on responses and when passing, but also allow user defined values?

Might require the defcfun function being used indirectly...
like

(defcfun ("gtk_dialog_response" %gtk-dialog-response) :void
  (dialog (g-object gtk-dialog))
  (response-id :int))

(defun gtk-dialog-response (dialog response-id)
  (%gtk-dialog-response
   dialog
   (case response-id
     (:none -1)
     (:reject -2)
     (:accept -3)
     (:delete-event -4)
     (:ok -5)
     (:cancel -6)
     (:close -7)
     (:yes -8)
     (:no -9)
     (:apply -10)
     (:help -11)
     (t response-id))))

(export 'gtk-dialog-response)

(defcfun ("gtk_dialog_run" %gtk-dialog-run) :int
  (dialog (g-object gtk-dialog)))

(defun gtk-dialog-run (dialog)
  (let ((response (%gtk-dialog-run dialog)))
    (case response
      (-1 :none)
      (-2 :reject)
      (-3 :accept)
      (-4 :delete-event)
      (-5 :ok)
      (-6 :cancel)
      (-7 :close)
      (-8 :yes)
      (-9 :no)
      (-10 :apply)
      (-11 :help)
      (t response))))

(export 'gtk-dialog-run)

There are other functions with the same problem.

Ferada commented

Sure sounds good to do it indirectly, except that I don't want to duplicate the case statements, I'd like to find a way that the case statements don't have to be duplicated from the enumeration definition though.

kierangrant commented

Fair point, I made a simple patch to fix (hopefully) all uses to use case statements...
kierangrant@a25c15b
I don't know how we can eliminate the duplication though...
Maybe a macro to define these "special" enum's that are open ended?

Ferada commented

I think you can get the range of the enums from CFFI, maybe via that, test for lower/upper range and use the "native" CFFI conversion if so.

kierangrant commented

Yes, looks like foreign-enum-keyword and foreign-enum-value could be used.
If we get an error getting the value from enum or finding enum for value, we could then pass the user's value directly...

  • 👍1
Ferada commented

Hmm yeah, I was thinking that CFFI had a better option. Anyway, yes, I'd say do it like that, that keeps the code short and it might be possible to optimise it later.

Ferada commented

Cool, PR? Otherwise I'll take that branch later and merge it.

Ferada commented

Merged, thank you!

kierangrant commented

Yeah, sure... went out of my timezone... I'm awake now! :) I'm using this library for a cross-platform GTK app for work...
I don't see any problems on Windows 10 so far, but developing on Linux...
Though I am currently using very old GTK on Winodws (3.10)...
I will need to fetch a new version from msys2 project...