Bug#712938: No change?
On Sun, 26 Jul 2015 10:52:13 -0300 Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer perezme...@gmail.com wrote: On Sunday 26 July 2015 12:42:56 MichaÅ Milanowski wrote: Can't any debian dev see his stupidity regarding to this issue? There are tons of qt4 apps that are widely used and will be probably never ported to qt5, like Skype for example, but many others too. Hi! I'm the Qt maintainer, and yes, I understand your arguments, but again: do you really want to push dead-upstream code and support it trough the whole life of Stretch? I don't. Your argument is that of principles against usability. People USE Debian. The principles are important, of course, but as far as they don't interfere with usability. You speak about dead code as if Qt4 has totally disappeared. As you know, there are and will be so many Qt4 apps. Porting to Qt5 is a good advice but, here again, an advice against usability?! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712938: No change?
On Sunday 26 July 2015 12:42:56 Michał Milanowski wrote: Can't any debian dev see his stupidity regarding to this issue? There are tons of qt4 apps that are widely used and will be probably never ported to qt5, like Skype for example, but many others too. Hi! I'm the Qt maintainer, and yes, I understand your arguments, but again: do you really want to push dead-upstream code and support it trough the whole life of Stretch? I don't. You decided to drop support for them just like that (90% actually used linux apps) and you are providing the only solution Port your app to qt5. Or someone to step up and become a sni-qt upstream, fix it's bugs and we can reconsider. All workarounds decrived here look like a joke, not real solution. Yes, sadly they failed to me too :( Ubuntu provided this patch, Arch provided too. Every known distro has workaround built in by patching qt to make their users live easier. But not Debian. For the reasons I have already stated. Shame and f you (sorry!). That was definitely too much. Please refrain from that kind of comments in the future. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#712938: No change?
Sorry, both are dead: qt4 and that patch. I can't understand your arguments, why can't you include that patch into qt4? I don't even mean sni-qt, but please apply patch that will make possible to use sni-qt. Most of people are able to compile sni-qt by theirself (or risk and install ubuntu deb). This patch is quite small and should not break stability. I understand you principles, but this case is huge usability issue. Too huge to be able to be accepted. On Sun, 26 Jul 2015 10:52:13 -0300 Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer wrote: On Sunday 26 July 2015 12:42:56 MichaŠMilanowski wrote: Can't any debian dev see his stupidity regarding to this issue? There are tons of qt4 apps that are widely used and will be probably never ported to qt5, like Skype for example, but many others too. Hi! I'm the Qt maintainer, and yes, I understand your arguments, but again: do you really want to push dead-upstream code and support it trough the whole life of Stretch? I don't. You decided to drop support for them just like that (90% actually used linux apps) and you are providing the only solution Port your app to qt5. Or someone to step up and become a sni-qt upstream, fix it's bugs and we can reconsider. All workarounds decrived here look like a joke, not real solution. Yes, sadly they failed to me too :( Ubuntu provided this patch, Arch provided too. Every known distro has workaround built in by patching qt to make their users live easier. But not Debian. For the reasons I have already stated. Shame and f you (sorry!). That was definitely too much. Please refrain from that kind of comments in the future. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/
Bug#712938: No change?
Can't any debian dev see his stupidity regarding to this issue? There are tons of qt4 apps that are widely used and will be probably never ported to qt5, like Skype for example, but many others too. You decided to drop support for them just like that (90% actually used linux apps) and you are providing the only solution Port your app to qt5. All workarounds decrived here look like a joke, not real solution. Ubuntu provided this patch, Arch provided too. Every known distro has workaround built in by patching qt to make their users live easier. But not Debian. Shame and f you (sorry!).
Bug#712938: No change?
As far as I know, no change will be needed with Qt5 = 5.4 for the systray icons to work hmm... 5.4.2 is in unstable now - so if no change is needed, why does the systray not work. Another thing is - why did kf5 drop support for XEmbed when many toolskits use it? -- Søren Holm signature.asc Description: This is a digitally signed message part.
Bug#712938: No change?
On Saturday 25 July 2015 21:44:00 Søren Holm wrote: As far as I know, no change will be needed with Qt5 = 5.4 for the systray icons to work hmm... 5.4.2 is in unstable now - so if no change is needed, why does the systray not work. It works, for Qt5 apps. There was a bug with Qt5 5.4. Qt4 apps do not work. Another thing is - why did kf5 drop support for XEmbed when many toolskits use it? http://blog.martin-graesslin.com/blog/2014/06/where-are-my-systray-icons/ And a (maybe) interesting workaround can be found in: http://alien.slackbook.org/blog/support-for-old-school-xembed-system-tray-icons-in-plasma-5/ Disclaimer: I haven't tested it yet. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#712938: No change?
perezme...@gmail.com escribió: And a (maybe) interesting workaround can be found in: http://alien.slackbook.org/blog/support-for-old-school-xembed-system-tray-icons-in-plasma-5/ Disclaimer: I haven't tested it yet. Another possible workaround is using trayer, as described in the current last comment in the link above
