Too many user interface changes and no documentation of any of them

[attilakinali]

Hi,

I've been using icewm for 24 years now and thus have accumulated a lot of muscle memory of shortcuts and ways to do things. While I do appreciate and welcome the new pace of development, there are way too many changes in the user interface since the maintainership has been taken over. Every time I update icewm there is some shortcut, some mouseclick-keypress, some behavior that doesn't work anymore. And every time I have to figure out what changed, where and how to re-enable the old behavior, if it is even possible. And this breaks my workflow. Every single time. A workflow that I have been cultivating and optimizing for decades.

This isn't just super annoying, it's getting to a level where I am seriously considering forking icewm because it would be less wasted time and effort to maintain my own fork than the hours I spend with every update to restore my workflow or find ways around it.

Would it be at least possible to make a list, like a changelog, of all the user interface changes and how to restore the old behavior? So that at least I don't have to read to a million git commit diffs to figure out what changed where.

Thanks for your consideration

Attila

[gijsbers]

Nice to finally hear from ya. It would be more productive if you provided a long complete and detailed list of all the many muscle-memorized shortcuts and ways to do things that no longer work. Please include the date it stopped working, the version number and a clear description of what it did exactly and what it does or doesn't do now. That would be most helpful.

[attilakinali]

As I am not updating every day and do not follow your git commits, I cannot give you exact dates when something stopped working.

1. The newest one is that Win key as alias for Ctrl-Alt stopped working. And none of the config switches I found seem to re-enable it.

2. Another one that is quite annoying is that Shift-Alt-F10 (Alt-F10 being maximize) on a maximized window would shrink it in y direction to the original size and keep the x direction maximized, instead it switches to y-direction maximized, x-direction original size. Same with Shift-double click on the title bar. This means that the possibility to have a window maximized in y direction only is lost.

3. It used to be that, in case a window sets an alert (IIRC _NET_WM_STATE_DEMANDS_ATTENTION), Alt-Tab would switch to that window, no matter which desktop the window is on. Now Alt-Tab only switches to that window if it's on the current desktop. I'm not quite sure whether the original behavior is best, as I can see that not everyone wants to always switch across desktops, so maybe an Alt-Tab variant like Ctrl-Alt-Tab or something might be more useful.

4. Ctrl-Space does not open a shell prompt in the taskbar anymore.

And these are just the ones that are at the top of my head.

As you can see there are quite a few and I would have expected that these changes are done consciously and for a reason. And that's the reason why I usually don't report UI changes. I assume that the developer has a reason for changing them, one that I don't see. If that's not the case, but instead these changes are bugs, then more testing of the user interface would probably be a good idea.

[gijsbers]

1. ModSuperIsCtrlAlt=1
2. KeyWinMaximizeHoriz= ... ?
3. QuickSwitchGroupWorkspaces=0
4. KeySysAddressBar="Ctrl+Space"

[pintergreg]

@gijsbers If I may... I think the main problem behind this issue is the low quality release notes. I do think the release notes should be structured. Partly because it is hardly readable in this format, partly because the different type of changes are mixed. Don't forget that GitHub provides markdown to format the texts.

I think the following categories should be introduced: fixes, features, changes, for packagers. (It is not comprehensive, you may get ideas from others.)

When a behavior is changed, the config to "reverse" the changes could be included. Just like your response before. That would enable users to easily find the "problem" and reverse them without too much effort.

The packaging part also important for the distributors. In release 2.9.0, there is a potentially important notice (Update minimum required cmake version to 3.2.) in the middle of a lengthy unstructured text that should be easily found by packagers, who might not even use the software. There was complain (#101) that might be related to this. I know it is not literally about this though.

Have a look at these release notes:

• https://github.com/transmission/transmission/releases/tag/4.0.0
• https://github.com/go-gitea/gitea/releases/tag/v1.18.0

I know it would require a lot of time to format the release notes, and the projects above are much larger, but I think it might worth the effort.

disclaimer: I'm not a packager and I don't even use icewm on a daily bases. I just keep it installed on my servers for the cases I'd need to vnc to them.

[gijsbers]

Like this: https://github.com/ice-wm/icewm/releases/tag/3.3.1?

[pintergreg]

Like this: https://github.com/ice-wm/icewm/releases/tag/3.3.1?

Yes, I think that is much better and readable! I personally would add bullet points, but that is only a matter of taste. The sections alone make it easier to pick up the relevant information.

Thanks for considering my remark.

[Code7R]

@pintergreg Are you serious? https://github.com/Kitware/CMake/releases/tag/v3.2.0 Maybe we should also warn users about C++ 11 features? So, like after almost 13 years of its release?

And I am serious. Even the most conservative distro I would consider covers those requirement without additional efforts. https://packages.debian.org/search?keywords=cmake

[cheapy]

This might be OT but I think we should be giving these people CREDIT for their efforts and results!

Compare IceWM to all the other programs out there that never improve...