On 5/1/22 3:03 AM, David Faure wrote:
This seems to only work for actions in a toolbar, says the comment in
ActionFileParser::setActionToolTip().
That's what I found experimentally, but checking now I don't see the
comment. Wait! The Rosegarden codebase moves quickly. ;) I hadn't
pulled the latest master. There it is: "(philip 2022-03-31 11:07:46
+0200 514)". Thanks, Philip!
createAction(...)->setToolTip("some text");
That should work.
I'll retry with the latest sources and see if there's a change.
But do you know why it's off by default? Because tooltips on menu items are
pretty annoying, if you ask me ;)
You're trying to read what's available in the menu, and boom, some tooltip
hides parts of it. What's usually done instead, is setStatusTip() and having a
statusbar where the help text appears.
But the tooltips still aren't displayed.
I can debug this if really needed, but first, what do you think about status
tips instead?
I'll try setStatusTip(), and that's probably the near-term answer. I
will say that it took me, a Rosegarden newbie, a long time to even
realize the statusbar was there (in the Matrix Editor, which is my main
use case). The RG GUI is so complex, and the statusbar isn't where my
visual focus is on the mouse pointer, that I just didn't see it. BTW,
there are lots of places in the code where RG_WARNING is used to report
user-facing messages to stdout which should instead absolutely go to the
statusbar or somewhere else more reasonable. I should probably file a
bug report or feature request about it but have held off since I'm not
likely to volunteer to do the work myself (Hercules and the Augean stables).
I understand your point about tooltips obscuring things, but couldn't
that be solved by ensuring that they're displayed to the right of the
menus (like secondary "More choices > " actions), or somewhere similar?
That's what I like about tooltips -- they're "right there" and
impossible to miss. I hate everything about the Apple/Mac interface,
like how the current application's menubar takes over the whole screen
at the top, the arbitrary usage conventions that the fanboys think are
intuitive when it's really only that they're consistent, etc, etc.
(Excuse me, an angry mob with pitchforks, torches, and a noose just
appeared at my front door and I have to let them in.) But "balloon
help", which I think Apple invented, although it might have been stolen
from Xerox PARC along with everything else, was a great idea.
In a way. But more precisely, this is very much based on the KDE Frameworks
XMLGUI technology. When rosegarden was ported away from KDE technology, a
custom parser for those xml gui files was written.
It's not really like QtDesigner because it's purely about menus and toolbars,
nothing else; and QtDesigner leads to generated C++ code, while this xml file
is parsed at runtime by the application.
Again, I think this is excellent system design, especially combined with
how the .rc files are compiled into the application binary instead of
being external dependencies. So much so that I was wondering why it
wasn't a built-in capability of Qt. IMO it's a much better solution than
GUI builders generating code. That always works for simple cases but
becomes more trouble than it's worth as the complexity grows and
workarounds have to be made for the builder's inevitable limitations.
Not that any of this is exactly new. Many, many years ago I worked with
arguably the best coder I've ever met who did something similar for
Motif (I told you it was a long time ago) that I can't find anything
remaining online about now. It was built on the Xt Intrinsics database,
which in turn is another wheel that got reinvented over and over again
(xdg, etc). But I've been called a grumpy old man, for what should be
somewhat obvious reasons. ;)
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
