Open Steinhagen opened 8 years ago
Reported: https://bugs.kde.org/show_bug.cgi?id=368386
Oh I know.... :-) but this is not because of my application, it is because of the new plasma libtaskmanager how handles windows, startups, launchers...
unfortunately when discussed this with the official developer he agreeded in reveiving patches but this is not something to be fixed in the near future...
Is there a bug raised upstream for this problem?
I dont think so...
I dont know if it should...
according to libtaskmanager developers: the libtaskmanager took on its implementation the consideration that many applications even mainstream do not have correct desktop files... and actually this is true... Personal case the chrome desktop file which believes is a Group of windows, possibly because its tab is a different thread...
the current libtaskmanager support three different states: Launcher, Startup, Window in order to change state an item from the ListModel is removed and the new state is added... So to go from a Launcher to a Window state these line of states (which means removals, additions) is used... I have disabled totally the Startups, because they were creating a mess of animations... To consider that there apps that dont go to Window State even a Window is shown, they stay to Startup, so I had to take into consideration that some Startups must be shown eventually after a certain delay...
The librarry developers aggree that it should be implemented in other way in order to not remove or add that often elements from model but for the current plasma use case it works... For example in current taskmanager plasmoid all this behavior is hidden because there arent many animations...
They would also agreed into taking patches to fix this but they would take a very rough review process because of the importance of the library... Not having the time personally in order to change such an important piece of library, especially when something more important exists (transition from X to Wayland), I stopped my effort for this and it is something for the far future...
It should be noted here that all alternative docks probably will stop working in Wayland.. In Wayland only one window manager can exist. I believe that this means that any other dock that does not contact with the libtaskmanager or the Kwin somehow, it is not going to work... This makes Now Dock even more important to exist... Any gnome based docks will not work in Wayland under Plasma if they dont interact with KWin or the new libtaskmanager...
Well, now i am confused as to "what upstream to report to".
on the broken system, i changed:
and its working now.
The kmail problems seems the same thing : the system launches command 'kmail -qwindowtitle %c %u'. Launching with 'kmail' only, its working.
In a way .... it seems taskmanager is doing the right thing, but very very strict. for it to work, perfectly and correct desktop files must exist.
Like psifidotos said.... on a taskmanager maybe people didn't use this feature much, but on a dock, app/launcher tracking is most important.
What do you guys recommend i do ? report to kde taskmanager devs or report to distribution system devs to change the desktop files ?
What do you guys recommend i do ? report to kde taskmanager devs or report to distribution system devs to change the desktop files ?
if libtaskmanager behaves correctly with the correct desktop files then I think this should go to distribution or application level..
Informing the libtaskmanager developers for this, if they want to support this case and how it could also be reported...
So either both or definitely the distribution...
So either both or definitely the distribution...
ok, will do. At least on Gentoo and KDE I will report it. I will also mention this thread, if they need background info.
:+1:
Launching a pinned application, shouldn't make it disappear from the dock and then reappear when the application has started.