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
