Programming

VSCode + CodeLLDB is great (and FOSS), surprised no one mentioned this yet

Try ddd. Also IDEs usually can be integrated with gdb and other popular debuggers.

As I assume you're not looking for FOSS-only solutions, you probably want to go with Jetbrains IDEs (IntelliJ). They are arguably the best IDEs around and have native Linux versions.

I assume you are mostly working with C/C++. I don't have first experience with CLion but haven't heard anything negative about it.

Any modern IDE for any language has a built-in debugger UI. Mostly good one.

I use gdb myself.

I don't know exactly what you're after. From the above, I see:

"easy to use"

" the mouse is faster, not slower"

You don't specify a language, so I'm assuming you're looking for something low-level.

You don't specify an editor, so I'm assuming that you want something stand-alone, not integrated with an editor.

There are a number of packages that use gdb internally, but put some kind of visualization on it. I've used emacs's before, though I'm not particularly married to it

mainly found it interesting as a way to rapidly move up and down frames in a stack

but I'm assuming that if you want something quick to learn, you're not looking for emacs either.

Maybe seer? That'd be a stand-alone frontend on gdb with a GUI. Haven't used it myself.

EDIT: WRT gdb, the major alternative that I can think of to gdb is dbx, and that's also a CLI tool and looks dead these days. gdb is pretty dominant, so if you want something mouse-oriented, you're probably going to have some form of frontend on gdb.

There are other important debugging tools out there, stuff like valgrind, but in terms of a tool to halt and step through a program, view variables, etc, you're most-likely looking at gdb, one way or another, unless you're working in some sort of high-level language that has its own debugger. If you want a GUI interface, it's probably going to be some sort of frontend to gdb.

EDIT2: Huh. Apparently llvm has its own debugger, lldb. Haven't used it, and it's probably not what you want anyway, since it's also a CLI-based debugger. I am also sure that it has far fewer users than gdb. But just for completeness....guess you already looked at that, mentioned it in your comment.

Emacs is a crazy good GUI debugger I've heard but I've been invested in Neovim for years

https://github.com/j6t/kdbg might be to your liking, but it is still a gdb frontend.

depending on the language you use there might be an IDE with a good debugger for it, if so i'd have a look at that.

It's fine to want a gui debugger and I want to clarify that I'm not actually trying to persuade you to use gdb! My actual advice would be vscode (or other ide) with it's gdb/lldb integration which allows you to debug from your ide in a gui-oriented way.

I do however think that you're wrong about how hard it is to learn gdb. I learned to use it not that long ago and it doesn't take "1 month". Using gdb on a basic level is actually not particularly hard, and I can recommend this talk for anyone actually curious about learning gdb. It's just 15 minutes, but the same speaker has done a couple of other talks on the same theme that are longer if you want to learn even more, you can probably find them in the recommended videos sidebar.

What I actually think is the case is that learning gdb takes a bit more mental effort because it's a different paradigm than normal gui editors, and a lot of things aren't intuitive. If you're prepared to be a bit uncomfortable and lost for an afternoon, and maybe even flip through the official document for a bit you can be "good enough" at gdb in less than a day.

Gdb is also more powerful than most gui-only editors, because you can do scripting in gdb. For example you can execute an arbitrary series of gdb commands when you hit a certain breakpoint which can be really useful in some circumstances. My preferred way of debugging in linux is actually to both have a gdb window that I can enter commands in so I can do more scripting stuff if I want to, and also some extra bells and whistles for viewing source code and setting breakpoints etc. I edit in vim so I use the termdebug plugin that comes bundled with vim, but use whatever exists for your editor if you don't use vim yourself.