Re: [h-e-w] Windows 10 Taskbar Behavior

[Rob Davenport]

 

Ø  IMHO, none (including the one for emacs.exe) are "useful", ie, I don't think addpm should even touch them.

 

True.   http://blogs.msdn.com/b/oldnewthing/archive/2011/07/25/10189298.aspx provides some interesting history and information on AppPaths.  I do remember the problems it says AppPaths was intended to solve.

But, you’re right – these days Windows users have the Start Menu to search for executables by name.   I believe if you favor the Run dialog or START command-line command, the AppPaths would help.

Personally I use aliases on the command-line primarily, or pinned taskbar shortcuts, or context menu commands from Explorer.     The only argument for keeping it would then be support for older OS versions and I don’t know any official policy on that.  The documentation states Emacs ‘is known to run on’ Windows back to 95 and XP.  But is it OK to remove the AppPaths feature?  (Not my call.)  If that gets removed, I’d argue that the DDE code in there isn’t needed as well.

 

Still, it seems the primary benefit would be creating of the shortcuts.  Trimming it down to just do that (and include the AppUserModelID on supporting platforms) would be good.  And please Eli. J

 

Ø  There are other things that could be done to make Emacs integrate better with Windows (for example, having a jumplist / task list in the taskbar icon, showing an icon in the tray notification area when daemonized, etc), but I don't think they are worth the effort. Not to mention that if that functionality doesn't (more or less) exist in other window environments, you'd have a hard sell in emacs-devel.

 

Agreed.  I haven’t played with jumplists much, though I do use them a lot when connecting to the many remote VMs I use at work.  Right-click on the Remote Desktop taskbar icon and choose the one I want.   Emacs could make use of that for files in recent file lists.   Nice, and would be seen to better integrate with Windows (if that’s a goal), but not vital and could be seen as hampering users learning what Emacs already provides.

 

Tray notification area would be neat as well, but might make David’s use of Win+<num> a little harder.  And honestly I have way too many icons there to find the one I want easily (most IT mandated at work).  

Notifications of background events like new email or news might be nice.  Does Emacs integrate with other window manager notification mechanism in GNU/Linux distros?

 

The context menu features I do like, since I end up using Windows Explorer a fair amount.  (cf. http://www.emacswiki.org/emacs/MsWindowsGlobalContextMenu)   

 

Interesting ideas to play with and maybe propose on emacs-devel someday.

 

>> Now I see that addpm only *updates* those registry values (EMACSLOADPATH, emacs_dir,

>> EMACSPATH, EMACSDATA, EMACSDOC, SHELL and TERM) – they must already exist.

 

>This is another recent change. All released versions do add them unconditionally if the registry key (not values) already exists.

 

I have 24.4 source as well, and it also seems to only update the values.  Was the change made earlier than 24.4?  Or am I looking at the wrong code?  (Still learning my way around the source control history.)

 

>> -          Adding emacs.exe entry to AppPaths key.

> Which I wouldn't call "useful". I happen to have my own App Path entries and addpm "blind overwriting" style messes with them. All just to be able to run emacs.exe without having it in the PATH. Bah.

 

Yes, not overly useful.  But you’re right – it shouldn’t do it blindly.  It shouldn’t overwrite them if they already exist.  Maybe warn you about them – especially if they are different and prompt to run addpm again with a parameter to force it to update them. But not by default.

 

> -          Add a shortcut to the Windows common or user Start Menu folder

And we (AppID issue apart) don't really need an application for that.

 

Yes, aside from the AppID issue, users – especially Emacs users – are very capable these days to create their own shortcuts.    I was also taken with the idea of addpm acting as the ersatz ‘installer’ for Emacs on Windows – primarily to make it more palatable to new users.  To make it more ‘familiar’ to non-Unix types.  But Emacs evangelism is a whole other topic…

 

 

> So I'd tend to agree with Eli, addpm is a relic and should be left to die.

 

Aside from the AppID issue, you guys may be right.  And it could just turn into a utility that only creates the shortcut(s) with the AppID for those that experience what appears to be a Win10 bug.  As David reminded us he pointed out a while ago.

 

Rob