Hi,

it looks fine for me. @Mihai, Mike DePaulo: Can we update our build environment to build x2goclient with Qt5 on platforms where Qt5 is available?

regards, Alex

PS: thank you for the patch, Sébastien

Am 21.03.2016 um 16:48 schrieb Mike Gabriel:

Hi Stefan, hi Mihai, hi Alex, hi Sébastien,

On Mo 21 Mär 2016 15:13:24 CET, Sébastien Ducoulombier wrote:

...

Hello,

Attached is a patch for X2Go Client so to support Qt5.

It compiles and executes fine on Debian.

I attempted to retain Qt4 compatibility using #ifdefs.

-- Sébastien

@Sébastien: Awesome job!!! Well done!

@Alex: I'd highly recommend applying this patch, testing it and switching the complete build to Qt5 on recent distros. Debian will remove Qt4 support for Debian 9. At least the security and release teams tries to each this. Qt4 is highly deprecated in the various distro realms.

Mike

---

x2go-dev mailing list x2go-dev@lists.x2go.org http://lists.x2go.org/listinfo/x2go-dev

--

Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Harzstr. 4 | Fax. : 0911 - 14870374 9 D-90491 Nürnberg | Mobil: 0163 - 49 64 461

Geschäftsführung: Dipl.-Inf. Oleksandr Shneyder

Amtsgericht München | http://www.phoca-gmbh.de HRB 196 658 | http://www.x2go.org USt-IdNr.: DE281977973

On 21.03.2016 05:28 PM, Oleksandr Shneyder wrote:

it looks fine for me. @Mihai, Mike DePaulo: Can we update our build environment to build x2goclient with Qt5 on platforms where Qt5 is available?

One thing I completely forgot but was bitten by while going through the build process for X2Go Client is the browser plugin. It looks like development of qtbrowserplugin stopped in 2009 and the code has been dropped with Qt5.

Qt5webkit will not help us any and there seems to be no direct replacement.

In the end, it probably boils down to x2goplugin dying once Qt4 is removed.

In the meantime, while Qt4 and Qt5 are both available in the repositories, it would probably be possible to build x2goclient against Qt5 and x2goplugin against Qt4. Does that make sense, though?

Mihai

Hello,

Stefan Baur wrote :

As you might know, I'm the current X2Go Project/Community Manager, and I'm not a coder, so I can't really judge the value of your contribution myself - but I heard it from the other developers on previous occasions that this was indeed a big upcoming issue, and their reaction so far seems to support that you did a very good job there.

Thank you but I did not do much. My motivation is to get X2Go Client fully translated in French for my users. In order to test my translations, I needed to compile X2Go Client on my computer. I wanted to avoid installing Qt4 as I already had the Qt5 development environment installed.

We still have some IBM-sponsored "goodies" to give away, and I'd say this occasion warrants it. :-)

So if you tell me your postal address (off list, of course), I'll send you a package of "IBM swag" as a sign of the project's gratitude. :-)

I did not expect such a warm welcome for my patch :)

And congratulations for such a useful piece of software ! X2Go Client is used everyday by at least 10 of my users, mostly teachers.

I hope I will be able to contribute again.

-- Sébastien

Mihai Moldovan wrote :

The only problem I see with it is that all instances of QString::toAscii () have been replaced by QString::toUtf8 (). Personally, I like the idea of porting things to UTF-8, but fear side-effects in terms of passing UTF-8-encoded strings to other interfaces that actually expect ASCII (or really a plain 8bit encoding.)

Hence, I'd like to modify all these occurrences with QString::toLatin1 () for now. At the same time, I think your original patch serves as a great reference as to what locations can potentially be rather ported to using UTF-8. I'll need to examine where this is actually possible more accurately at a later time.

Does this make sense to you? Are there any objections?

It does make sense and I have no objection.

-- Sébastien

On 01.04.2016 10:45 AM, Nable wrote:

QString::toLocal8Bit() may be more suitable in some places. At least, it doesn't break access to files with non-ASCII names as QString::toLatin1() do.

Good point. toLocal8Bit() might carry out conversions, though, while toAscii() is equivalent to toLatin1(), iff no conversion method was set. We never do the latter, so within X2Go Client toAscii() should be functionally equivalent to toLatin1().

Thus, to retain the old (potentially broken(!), as you pointed out) behavior for now, toLatin1() sounds like the best option.

Mihai