From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: pop-up tool-bar Date: Fri, 8 Oct 2004 12:03:37 -0700 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1097282018 4025 80.91.229.6 (9 Oct 2004 00:33:38 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 9 Oct 2004 00:33:38 +0000 (UTC) Cc: Miguel Frasson , Emacs-Devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 09 02:33:25 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CG5Ar-0006lR-00 for ; Sat, 09 Oct 2004 02:33:25 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CG5Hf-0000vU-Jf for ged-emacs-devel@m.gmane.org; Fri, 08 Oct 2004 20:40:27 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CG5GR-0000DC-Bx for emacs-devel@gnu.org; Fri, 08 Oct 2004 20:39:11 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CG5GQ-0000Cs-0X for emacs-devel@gnu.org; Fri, 08 Oct 2004 20:39:10 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CG5GP-0000Ce-K8 for emacs-devel@gnu.org; Fri, 08 Oct 2004 20:39:09 -0400 Original-Received: from [199.232.41.8] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1CG50X-000415-Q4 for emacs-devel@gnu.org; Fri, 08 Oct 2004 20:22:46 -0400 Original-Received: from [141.146.126.230] (helo=agminet03.oracle.com) by mx20.gnu.org with esmtp (Exim 4.34) id 1CG092-0002iU-3T for emacs-devel@gnu.org; Fri, 08 Oct 2004 15:11:12 -0400 Original-Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.191.12]) by agminet03.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i98J3jSj001673; Fri, 8 Oct 2004 12:03:47 -0700 Original-Received: from rgmgw3.us.oracle.com (localhost [127.0.0.1]) by rgmgw3.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i98J3j0J024728; Fri, 8 Oct 2004 13:03:45 -0600 Original-Received: from dradamslap (dhcp-amer-csvpn-gw1-141-144-69-154.vpn.oracle.com [141.144.69.154]) by rgmgw3.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id i98J3fHw024651; Fri, 8 Oct 2004 13:03:44 -0600 Original-To: "Stefan" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:28114 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:28114 What else have I tried? Well, I tried the code you offered, but it didn't work for me, as I mentioned previously. You never replied to my report of those pbs and my request for info on what I might be doing wrong (copied below). Did you actually _run_ your code successfully? If you have another suggestion, let's try it. But please _try_ this code too, before dismissing it out of hand. Please pound on it, so we can see just how brittle it is. I'm curious: just what part of the quoted mouse-click fix do you find to be a "really super ugly nasty brittle dark hack"? What makes it so? Are you speaking in terms of the code being brittle or the user experience (e.g. being nonintuitive), or both? You raise (I guess) two issues: - bad code - bad user interface I'm open to improvement on both accounts. But let's be specific about what is wrong. In terms of the code, please point out just what is brittle/bad style/poor performance/whatever or suggest improvements. In terms of the UI, please _try_ the code, and then report on what you find to be a pb. So far, you seem to be reacting to a description of the behavior, and, as I said, it's easier to experience the behavior than to describe it. Abstractly name-calling the code or the UI doesn't help, I think. Please be specific. I'm sure that you can come up with good, concrete improvements, just as you did with the Info quotes highlighting. You already did offer a concrete suggestion about `make-variable-frame-local', which I used. I think we should offer users a pop-up tool-bar feature; that's all. I don't push for my implementation of that feature; the best implementation should be used. Frankly, I'd rather that someone else code this feature. Thanks, Drew -----Original Message-----From: Stefan > The fix was to scroll the buffer (window) `tool-bar-lines' to compensate for > the window movement. This scrolling happens for mouse events only, since > other events do not cause the problem (and you don't want to scroll the > buffer each time you click a tool-bar button). This kind of really super ugly nasty brittle dark hack should be kept for extreme circumstances where there's really no other possible option. What else have you tried? Stefan -----Original Message-----From: Drew Adams Good input. I wasn't even aware of `make-variable-frame-local', though I see now that it's at least as old as Emacs 20. I see you put "valid" in quotes, but I'm still not sure I know what you mean. If the next event is a (valid) mouse-down, that's seems to be OK. The mouse-down occurs at the right position in the buffer (as evidenced by the highlighted region and cursor position), so I don't think that's the pb. What happens, I think, is that when the tool-bar disappears, without your having moved the mouse relative to the display, the mouse nevertheless has moved relative to the displayed buffer -- so a region has been selected. Now that I think of it, that could provide a solution, if we could be sure to know the tool-bar height at all times in terms of # of buffer lines. We could scroll the buffer down that number of lines, to compensate for the buffer lines moving up relative to the display because the tool-bar disappears. Maybe I'll give that a try. (Looking at tool-bar margins and button-relief margins might be kind of a pain, though, and perhaps the tool-bar height is not always an integral number of buffer lines, and maybe we'll have to worry about different-size fonts - ugh.) Can you elaborate on your "Note" - Is it meant to apply to my original code or to your code (or both)? With my code, if I click "Buttons" and then delete the frame instead of clicking a button, it seems to behave as I would expect, at least on Windows: the frame is gone, that's all. Maybe I'm doing something wrong, but your code doesn't work for me: - The tool-bar doesn't disappear afterward, no matter how I end (click a button or do something else. - "Buttons" doesn't come back to the menu-bar, and I can't get it back again, even by turning tool-bar-mode on, then off. - I get this error when I click "Buttons": show-tool-bar-for-one-command: Wrong number of arguments: (lambda (hook function append local)... No doubt the first two symptoms are due to the last pb. Don't you need an unwind-protect to be sure to turn the mode back off, in case, for instance, the user does C-g -- or will the post-command-hook always take care of that? - Drew ---------------From: Stefan Monnier It looks like the problem is that the event you get from read-event is not "valid" any more after you remove the toolbar (becaue the position is changed). Using read-event is generally a source a trouble. But the alternatives aren't great either. Maybe you can try something like the appended code. Note: you should pay attention to the case where the frame has been deleted by the next command. Also, you declare your minor mode to be ":global t" but it is frame-local, so you should add (make-variable-frame-local 'tool-bar-here-mode) somewhere at the toplevel. Stefan (defun add-hook-once (hook function append local) "Same as `add-hook', but FUN is only run once. Also contrary to `add-hook', this is not idempotent." (let ((code (list 'lambda))) (setcdr code `(() (,function) (remove-hook ',hook ',code ',local))) (add-hook hook code append local))) ... (defun show-tool-bar-for-one-command () "Pop up the tool bar so you can click a button. The tool bar stays visible until one command is executed \(whether or not it was initiated by clicking a button)." (interactive) (tool-bar-here-mode 1) (add-hook-once 'post-command-hook `(lambda () ;; We're just now done with show-tool-bar-for-one-command. (add-hook-once 'post-command-hook (lambda () ;; We're done with the next command. (select-frame ',(selected-frame)) (tool--bar-here-mode -1))))))