[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [h-e-w] Windows 10 Taskbar Behavior
From: |
Rob Davenport |
Subject: |
Re: [h-e-w] Windows 10 Taskbar Behavior |
Date: |
Mon, 26 Oct 2015 21:46:06 +0000 |
> Yes, but how was that instance of Emacs launched? From the Start menu or in
> some other way?
>From the command-line using runemacs.exe. No shortcut involved.
> I can understand why Windows would look in the Start menu shortcut when you
> pin an application that was launched via the Start menu -- for Windows, that
> shortcut "represents" the application. But I'd be surprised to hear that
> Windows looks at the AppID of the Start menu shortcut when you pin an
> application that
> was launched by some other way -- how would Windows even know that there is a
> shortcut for the application there?
I was surprised as well. Launched Emacs via command-line runemacs, then
pinned, and saw Explorer.exe process open and read the GNU Emacs.lnk in the
Start Menu before creating the Emacs.lnk in the taskbar user-pinned directory.
Changing the AppID in the Start Menu shortcut changed the value in the pinned
shortcut. When it was "GNU.Emacs" in the Start Menu, it created lnk with
"GNU.Emacs" in pinned directory. When I changed the Start Menu app id to
something else, it did *not* put the app id in the pinned shortcut (it was then
blank).
Could test this by pinning some other program besides Emacs and see if it looks
through the start menu for a shortcut before pinning. But it still seems to do
so, and explains why on Win10, I was then getting pinned shortcuts with the app
id already in them.
I suspect Windows looks through Start Menu shortcuts for any that contain the
executable name in the target of the shortcut. What does it do if there are
multiple hits, I don't know. If you had two with different command-line
parameters but same executable, I don't know which it would choose or why.
> Documentation is easy to change.
Be my guest. I'm just saying it's there and users are being told they can use
addpm because of it.
> I'm sure I'm not the only one who knows how to create a Start menu shortcut
> for a program without using any programs.
Yes, and I would think a very high percentage of Emacs users on Windows know
how to do that even if they're not too fond of Windows.
But I think we then get into a philosophical debate on whether or not Emacs
should support running on Windows *more* (better integration, easier for
'normal Windows users' to use) or *less* (making any concessions to running on
Windows separate from standard Emacs and require extra work to include).
That's up to RMS et al. and I'll follow their lead. For now addpm is part of
Emacs and Windows has changed around it, so I think it could use an update.
> No, it doesn't add environment variables. It adds Registry keys that serve
> the same duty.
No, environment variables *are* registry entries. And it does add environment
variables - cf. the env_vars array in addpm.c.
> And it oh-so-helpfully also changes PATH that Emacs will see if it finds a
> GTK installation (this particular part was removed from the development
> sources,
> but the released versions still have it). And adding EMACSLOADPATH to
> Registry means that you cannot easily run 2 different versions of Emacs on
> the same
> system, because each version needs its own EMACSLOADPATH. Etc. etc. -- addpm
> does more harm than help, and it does that subtly, so that most users will
> not even realize what's going on.
Ah, so these behaviors are what upset you. These can easily be changed as well
- and I would think making them options would be a good idea, to provide more
flexibility. And even making them non-default options as well, so you only use
them if you find you need them. If Emacs on Windows native support for image
libraries has improved, then yes, I can see not needing to surreptitiously
adjusting the DllPath for Emacs. I hadn't realized it did that.
And I agree that putting the EMACSLOADPATH in the registry is limiting.
Again, making it a non-default option would be my preference.
And making just those little changes wouldn't negatively impact many people I
would think. (Except maybe the few that added that code to addpm in the first
place.)
You make some good points about those behaviors. I still like the idea of
addpm as the 'installer' - one that is optional, is part of Emacs, doesn't need
to be maintained with each release, and as the tool to add Windows (and
taskbar) integration in a standardized way. But changing the GTK and
EMACSLOADPATH bits I can agree with.
>Not in a MinGW compiled C program, it isn't, AFAIK. In an MSVC-compiled C++
>program, yes, it's easy.
I was saying in an *MSI* it's easy. I'm still working on getting a MinGW
environment set up (any pointers to good setup instructions?).
> addpm was never intended to serve as an Emacs installer. Emacs does not have
> an installer, and should not need one. Programs that modify the Registry are
> pests, because those Registry entries stay there long after the program was
> uninstalled/deleted. Our Registries are full of junk because of that.
No, there is no installer, I was saying it serves some of the same functions in
that it creates the shortcuts and updates env vars, as typical Windows
installers do.
It's providing integration into Windows. In that vein, I think the shortcut
it creates should add the App ID to better integrate with the taskbar in
Windows 10 (if not 7 and 8).
Your assertion that *should* not have an installer (or installer-like) program
gets back to that philosophical argument again. I'm fine with changing addpm
to make the GTK and EMACSLOADPATH 'features' optional as that makes the
integration better for more users. I'll let you argue it's existence with the
important people. :)
It would be interesting it there were a package manager for windows like apt et
al. that could take care of the installation/integration stuff - including
removal - I heartily agree that the registry gets lots of barnacles from old
software. A true 'installer' would take care of removing those when
uninstalling. I've looked a little at Chocolatey, maybe that would work.
Though I think it would need an MSI underneath and need to be rebuilt with each
Emacs release. But worth considering if it decouples Emacs from it's
installation and integration with the environment.
> I meant optional even on systems that do support AppID.
That's what I was saying - only systems (Win 7, 8 and 10) support the
IPropertyStory on the IShellLink's IPersistFile interface, so if that interface
isn't found, we don't try to add the app id, and thus it is only attempted to
be installed on supporting systems.
> I want addpm gone, so I'd rather not advertise it too much.
So you feel *all* integration with Windows (shortcuts, env vars, registry
settings (beyond env.vars - like context menu integration), taskbar
integration, etc.) should not be anywhere in Emacs itself, but solely
documented for users to locate and apply by hand? I can understand the
separation, but I do like a standard way to do said integration (with support
for removing it). Rather than having to deal with inconsistent environments
and trying to remember and rediscover all the little tricks. But it could all
be done with better user control. You get to pick what things to do - add
this shortcut or that one, but not this other one, etc. Maybe that's a better
approach than changing addpm. I'd want such a tool to be an (optional) part of
Emacs distribution though so it's widely available. But that gets back to the
philosophy again.
Regards,
Rob
- Re: [h-e-w] Windows 10 Taskbar Behavior, (continued)
- Re: [h-e-w] Windows 10 Taskbar Behavior, Juanma Barranquero, 2015/10/23
- Re: [h-e-w] Windows 10 Taskbar Behavior, Eli Zaretskii, 2015/10/23
- Re: [h-e-w] Windows 10 Taskbar Behavior, Rob Davenport, 2015/10/23
- Re: [h-e-w] Windows 10 Taskbar Behavior, Juanma Barranquero, 2015/10/23
- Re: [h-e-w] Windows 10 Taskbar Behavior, Rob Davenport, 2015/10/25
- Re: [h-e-w] Windows 10 Taskbar Behavior, Rob Davenport, 2015/10/26
- Re: [h-e-w] Windows 10 Taskbar Behavior, Juanma Barranquero, 2015/10/26
- Re: [h-e-w] Windows 10 Taskbar Behavior, Eli Zaretskii, 2015/10/26
- Re: [h-e-w] Windows 10 Taskbar Behavior, Rob Davenport, 2015/10/26
- Re: [h-e-w] Windows 10 Taskbar Behavior, Eli Zaretskii, 2015/10/26
- Re: [h-e-w] Windows 10 Taskbar Behavior,
Rob Davenport <=
- Re: [h-e-w] Windows 10 Taskbar Behavior, Eli Zaretskii, 2015/10/27
- Re: [h-e-w] Windows 10 Taskbar Behavior, Rob Davenport, 2015/10/27
- Re: [h-e-w] Windows 10 Taskbar Behavior, Juanma Barranquero, 2015/10/27
- Re: [h-e-w] Windows 10 Taskbar Behavior, Rob Davenport, 2015/10/28
- Re: [h-e-w] Windows 10 Taskbar Behavior, Juanma Barranquero, 2015/10/28
- Re: [h-e-w] Windows 10 Taskbar Behavior, Rob Davenport, 2015/10/28
- Re: [h-e-w] Windows 10 Taskbar Behavior, Rob Davenport, 2015/10/26
- Re: [h-e-w] Windows 10 Taskbar Behavior, Rob Davenport, 2015/10/10
- Re: [h-e-w] Windows 10 Taskbar Behavior, Rob Davenport, 2015/10/10
- Re: [h-e-w] Windows 10 Taskbar Behavior, David Vanderschel, 2015/10/11