Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Dialog relative positioning #111

Open
netvl opened this issue Dec 13, 2012 · 2 comments
Open

Dialog relative positioning #111

netvl opened this issue Dec 13, 2012 · 2 comments

Comments

@netvl
Copy link

netvl commented Dec 13, 2012

Currently it is possible to set :parent of a dialog created via (dialog) or similar functions, and it seems that it will call Window#setLocationRelativeTo method. However, it is called before (pack!) function can be applied to the dialog, resulting to invalid positioning of the dialog (calling setLocationRelativeTo before pack is useless, at least on newly created windows - they have size 0 and will not be positioned correctly because of this).
So, to fix this, setLocationRelativeTo has to be called after (pack!) but before (show!), resulting in ugly code:

  (let [d
        (dialog
          :parent parent
          :title "Edit header"
          :content (create-header-dialog-content default-name default-value)
          :option-type :ok-cancel
          :success-fn header-dialog-ok-handler)]
    (pack! d)
    (.setLocationRelativeTo d parent)
    (show! d))

instead of threading macro.

I guess it is sufficient to add a function like

(defn relative-location! [target parent]
  (.setLocationRelativeTo target parent)
  target)

so it can be used with threading macro conveniently.
@daveray
Copy link
Collaborator

daveray commented Dec 14, 2012

Heh. The comment on that code is:

; TODO This is a little odd.

So, it deserves your skepticism. An alternative that should do what you want is:

(-> (dialog :title "Edit header"
            :content (create-header-dialog-content default-name default-value)
            :option-type :ok-cancel
            :success-fn header-dialog-ok-handler)
  pack!
  (config! :parent parent)
  show!)

I'll need to ponder on whether there's a more elegant solution.

@netvl
Copy link
Author

netvl commented Dec 14, 2012

Yeah, haven't thought about config. It feels more natural than dropping back to plain java methods. Thanks for pointing this out.
As for the solution, I don't think it is possible to do something here with little effort. It would be possible to abstract this problem if dialog had some kind of pre-initialization hook which is run before it is shown, but I know none. For now, I guess, a function is sufficient.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@daveray @netvl