unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Adrian Robert <adrian.b.robert@gmail.com>
To: Ken Raeburn <raeburn@gnu.org>, Emacs Development <emacs-devel@gnu.org>
Subject: Re: a little feedback on Cocoa Emacs.app
Date: Mon, 4 Aug 2008 23:05:56 -0400	[thread overview]
Message-ID: <7ABEFFDC-6DA1-47FF-912A-BA4613B7F98D@gmail.com> (raw)
In-Reply-To: <27370426-1D11-4ECB-BA96-7734F7BF5148@gmail.com>


On Aug 4, 2008, at 7:43 PM, Adrian Robert wrote:

>
> On Aug 4, 2008, at 12:56 PM, Ken Raeburn wrote:
>
>> On Aug 4, 2008, at 08:50, Adrian Robert wrote:
>>>> When you say "one-element", you mean it adds the one element to  
>>>> the existing standard dock menu provided by the system, or it  
>>>> replaces it?  I'd prefer adding..
>>>
>> It appears that the items of the menu you define get slipped in  
>> between the list of windows and the standard set of actions in the  
>> menu that pops up.
>
> Cool.  I'll rework the patch a little bit (see Yamamoto-san's post)  
> and apply it, maybe tomorrow.

This is in.  Thanks.  Have you signed copyright assignment papers with  
FSF?  I can take this patch without them, but anything else will put  
you over the limit..



>>>> Using the keyboard commands to delete a frame get that result;  
>>>> clicking on buttons with the mouse can make the application go  
>>>> away.
>>>
>>> This sounds like a bug.  Shouldn't it have the same behavior  
>>> regardless of whether close from mouse or keyboard?
>>
>> I'm comfortable enough with the way things have worked for a while  
>> that this doesn't seem like an issue to me.  The lack of  
>> consistency of the new Mac UI with the way the rest of it works  
>> does, though.  (Well, I haven't checked the Windows version.)
>> If you want to argue that all window-system versions should behave  
>> the way the Cocoa port does now, go for it.  But unless/until you  
>> win that argument, I think the Cocoa port should change.
>
> Sure, the X interface is the prototype we follow.  But does the  
> different behavior when kb or mouse to close window seem right to  
> you?  Is there some reason for it you can think of?  I just want to  
> make sure because it seems strange, and like I say NS port has no  
> specific code handling this right now (should be generic behavior  
> that is seen).  (BTW, are you using GTK or non-GTK X?)

Actually I stand corrected on one point -- the NS port did have some  
code shortcircuiting delete-frame request when <= 1 frame left.  I  
took this out.  I'm not happy about it because the behavior now seems  
like a bug as I say, but no one else is speaking up so I'll not worry  
about it for now.

Also, regarding your report about the dialog appearing when you select  
Quit from dock menu, it's still there, but I fixed a bug in some  
cleanup changes of Jul 17 that was causing dialogs to fail.





  reply	other threads:[~2008-08-05  3:05 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-26  2:11 a little feedback on Cocoa Emacs.app Ken Raeburn
2008-07-27  2:29 ` Adrian Robert
2008-07-27  2:56   ` Stefan Monnier
2008-07-27 16:45   ` Ken Raeburn
2008-07-28  2:34     ` Adrian Robert
2008-08-04 10:15       ` Ken Raeburn
2008-08-04 12:42         ` mituharu
2008-08-04 13:08           ` Adrian Robert
2008-08-04 12:50         ` Adrian Robert
2008-08-04 16:56           ` Ken Raeburn
2008-08-04 17:04             ` Dan Nicolaescu
2008-08-04 17:23               ` Justin Bogner
2008-08-04 17:27                 ` Dan Nicolaescu
2008-08-04 19:28               ` Ken Raeburn
2008-08-04 21:53                 ` Dan Nicolaescu
2008-08-04 23:43             ` Adrian Robert
2008-08-05  3:05               ` Adrian Robert [this message]
2008-08-05  4:01                 ` Ken Raeburn
2008-08-05 16:17                   ` Adrian Robert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7ABEFFDC-6DA1-47FF-912A-BA4613B7F98D@gmail.com \
    --to=adrian.b.robert@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=raeburn@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).