[Bug 266] GoogleEarth should use the system Qt4 libs instead of its own (permitting font antialiasing)

https://plf.zarb.org/bugzilla/show_bug.cgi?id=266

--- Comment #12 from Davy Defaud <[email protected]> 2010-03-13 01:24:02 CET ---
(In reply to comment #11)
> (In reply to comment #10)
> > > First issue: private copy of QT4.
> > Rebuilding the needed Qt4 libs would be probably enough. But of course it would
> > increase the maintenance work a lot. I would understand that you don't want to
> > go this way.
> We'd need to rebuild the application, not the libs, which is not possible.
> 

I meant rebuilding a specific version of the Mandriva Qt4 libs, the same
version as those provided by Google.

> > What about providing the Mandriva Qt4 libs that are known to be working, the
> > ones from 2010.0, as a replacement of Google's ones ? It is a bit crappy, but
> > anyway, with this kind of package we don't have to compile anything as there is
> > no source code? At least should work on cooker...
> The only reliable libs are the ones the application has been linked against.
> Moreover, I don't see any interest replacing them with other binary builds.
> 

The reason is in the title of this bug report: enabling font antialiasing.

> > > Also, it doesn't really save any space, as installing the four required
> > > libraries actually installs approximatively 50 packages on a x86_64 system.
> > 
> > Hélas! Google still doesn't provide a 64 bits googleearth. Adobe provides a 64
> > bits flash-player plugin (albeit it's a beta version) but still doesn't provide
> > a 64 bits Adobe Reader. I hope this will change in a near future.
> You're dreaming. 'linux support' for proprietary software editor means 'intel
> 32bit binary', and tomorrow it will probably be 'here is the ubuntu package'.
> 

You are too pessimistic, x86_64 is now the standard configuration even on
netbooks and Apple hardware, and Windows 7 is provided in a 64 bits version.
How would software editors ignore that? Flash-player plugin is a first step but
it won't be the only one.

> > > Second issue: GTK theme support under QT.
> ...
> > Do you think it's worth to go ahead, or we should just wait for Google to
> > complete their job?
> That's a documentation issue, not a packaging issue. Feel free to add
> documentation on mandriva wiki to explain how to support GTK themes under QT,
> but I won't make any spec file more complex just for this kind of eye-candy
> prupose.

I agree that GTK theme support under QT is more global "problem" that should be
dealt in a more generic way, but GoogleEarth specificity is to be only
available for 32 bits. So for an x86_64 Mandriva, only GoogleEarth needs the
necessary 32 libs. That's the reason why I still think an empty
googleearth-gtk-compat subpackage requiring these libs would be a user friendly
and easy to implement solution.


> > > I don't understand the need to set LC_NUMERIC, or the issue with a shared
> > > cache, that would mix start location in multi-user scenario. As googleearth is
> > > a user-run application, each users saves its own data under its own directory ?
> > 
> > Well, I guess you run a cooker box and you haven't been able to start
> > googleearth with Mandriva Qt4 libs, as you reported that it crashes...
> > When using Mandriva Qt4 libs on 2010, if you don't set LC_NUMERIC to a locale
> > which the decimal separator is a point, like our French coma for example, then
> > what you will see in GE 3D view is a white ball. I guess it's a matter of
> > coordinates evaluation with a scanf() function affected by the locales
> > settings.
> So, that's just a issue when subtituting original libs, right ?

Yes, indeed.

-- 
Configure bugmail: https://plf.zarb.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
PLF-discuss mailing list
[email protected]
https://www.zarb.org/mailman/listinfo/plf-discuss