| Summary: | Tearoff menus exist randomly | ||
|---|---|---|---|
| Product: | [Unmaintained] kdelibs | Reporter: | Luke-Jr <luke-jr+kdebugs> |
| Component: | kdeui | Assignee: | kdelibs bugs <kdelibs-bugs> |
| Status: | RESOLVED UNMAINTAINED | ||
| Severity: | wishlist | CC: | annma, bko, cfeck, forums, grosser.meister.morti, kde, kde, marc+bugs, timo |
| Priority: | HI | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Luke-Jr
2003-02-26 20:17:26 UTC
Not a kwin bug. It's better to file individual wishlist reports for the applications that could use a menu tearoff. All menus should have tearoffs *** Bug 55475 has been marked as a duplicate of this bug. *** I agree, all menus shoud have tearoffs by default. It was very convenient in KDE 3.0 and I'm not happy to have lost all these features in KDE 3.1. *** Bug 56619 has been marked as a duplicate of this bug. *** *** Bug 56618 has been marked as a duplicate of this bug. *** *** Bug 53265 has been marked as a duplicate of this bug. *** *** Bug 60312 has been marked as a duplicate of this bug. *** *** Bug 63022 has been marked as a duplicate of this bug. *** This should be implemented as a global option. I don't want the screen space wasted on tearoffs I'm never going to use. Currently this actually is implemented as a global option which afaik defaults to not showing any tear-off handles at all in 3.1.x (the option is in control center > appearance & themes > style > effects > menu tear-off handles). This has nothing to do with this report anyhow. The reporter complains about the removing of the general availability of tear-off handles in all menus like it was the case in 3.0.x, which got replace by tear-off handles not being shown at all or optionally only in those applications which explicitely ask for it in 3.1.x. I know that option, I activated. But I've yet to see a single tear-off handle anywhere. What's the point of this option if no application uses it, even in the KDE core? And filing bugreports against individual applications that should have such handles is not possible, as that would be filing bugreports against almost all existing applications... Thanks for your attention! I agree that an option to activate tear-off handles everywhere regardless of "real" support for it should be reintroduced. The option to activate tear-off handles on an application level is currently a joke and unusable for anyone who regularly made use of tear-off handles in 3.0.x. In this regard (removal of a feature) this report is imo a bug report, not a wish. *** Bug 66836 has been marked as a duplicate of this bug. *** Yeap, I also tried activating that option and tear-off handles are nowhere to be found :-/ J.A. I see them once in a while in Konsole. They're not there now, but they were the last time I checked. > I see them once in a while in Konsole. They're not there now,
> but they were the last time I checked.
Just check back regularly, they might be on vacation. If you happen to see them again, tell them my greetings and that I have missed them..
So will this bug be fixed? please make it coming back ! we need tear-off menues when working in dual screen environment, or with a huge bookmark, or with the quick menu applet, ... I believe ,no kde developer may be forced to check all kde applications for reintroducing tear-offs. I also do not believe this is possible at all, since there is a bunch of developers not knowing tear-offs at all. What I think, would be easiest, is a patch of the KMenuBar class. At runtime ,the class should check the event of changing its children (i.e. the menus). Whenever it recognozes a change it parses the members of this child and decides, if they support tear-offs at all - then FORCE the child to turn the tear-off on or off. My cents... *** Bug 121940 has been marked as a duplicate of this bug. *** Is this bugreport still valid, or is the concept of tear-off menus completely gone from KDE4 ? In the latter case, should this bugreport be closed? In the latter case, this bugreport should be converted to a feature request. s/feature request/regression/ I don't mind it being gone by default, but it should at least be configurable to get it back... This should be relatively easy to reintroduce in KDE 4, because Qt 4 no longer requires the tear-off handle to be inserted as an item, which would indeed break dynamic menus. The only "problem" is that tear-off handles are displayed at the top of the menu, instead of at the bottom. But for those users that enable this feature, it should not be a blocker. Aren't tear-off handles usually displayed at the top of the menu anyway? So there is no problem. Or what do you mean? They were inserted at the bottom in KDE 3.0. Were they? At least in Gtk they are on top. Users are accustomed to such handles being at the top (see: the window decoration), so I'd guess this change would be a good thing anyway. Hi, kdelibs (version 4 and earlier) is no longer maintained since a few years. KDE Frameworks 5 or 6 might already have implemented this wish. If not, please re-open against the matching framework if feasible or against the application that shows the issue. We then can still dispatch it to the right Bugzilla product or component. Greetings Christoph Cullmann |