Slashdot Mirror

← Back to Stories (view on slashdot.org)

New Google Apps For Linux Coming

Posted by kdawson on from the bated-breath dept.

techoon writes "The goal of the Google Linux Client Team is to develop Linux desktop applications, such as the official Linux versions of Google Earth and Google Picasa. This team made an interesting splash during a presentation at the first-ever Linux Foundation Collaboration Summit, which they had kindly hosted at their Mountain View campus. The Google presenters claimed some 'significant accomplishments' and other new Google desktop applications coming out this year for the Linux platform."

6 of 159 comments (clear)

  1. Native? by colourmyeyes · · Score: 5, Interesting

    As TFA says, Picasa for Linux wasn't native, just a Windows version repackaged with Wine. I hope the new stuff isn't like that.

    --
    My grandmother used anecdotal evidence all the time, and she lived to be 120 years old.
    1. Re:Native? by yincrash · · Score: 5, Interesting

      should they be writing picasa fom scratch? the wine versions help the wine project by submitting patches bringing more win32 apps usable to linux making linux a more and more appealing option.

  2. Give us gtalk on linux already! by LingNoi · · Score: 4, Interesting

    Gtalk with all the features available that the windows version has, such as chat logging and voicemail support. If there was ever going to be a killer app this would be it.

  3. 64 bit Google Earth by phrostie · · Score: 3, Interesting

    a 64 bit version of Google Earth would be awesome!

  4. Re:Crumbs from the table aren't appealling by abigor · · Score: 3, Interesting

    An interface is slow when it commonly requires chains of arcane data structures as parameters, and many Win32 API calls do just that. An interface is buggy when there are 17 ways to do something, each producing a slightly different result. Windows API developed both of these traits over the years, and I only pity Microsoft for that, not blame them. But here they are, with a junk Win32 API and with a newer .NET layer built on top of that. I'm aware of the shortcomings of the Win32 api, as I used to code with it extensively in the '90s when I actually programmed for the Windows platform, but I don't really understand your point. Passing in pointers to parameters, no matter how "arcane", isn't slow, nor is dereferencing them to get the values you need. Pretty much anything passed by value are just integers, like window handles and stuff. Or maybe you mean "slow" as in time-consuming to code, in which case I suppose I agree. As for the second complaint, do you have an example of this 17 different ways to do something, all with slightly different results? That would be cool to see.

  5. Re:Crumbs from the table aren't appealling by tftp · · Score: 3, Interesting
    I was specifically mentioning pointers to large, complex data structures that often contain pointers to other, even more complex data structures. You can find those everywhere, for example look for LPSECURITY_ATTRIBUTES and follow the pointers and the methods that manipulate them. It's a lot of work to code it all correctly, and it's a lot of time to run it. If you code WDM drivers then such structures are everywhere, even to convert one ASCII string into one UNICODE string. You can see some code here.

    With regard to 17 ways to do something, it's easy. Look at ReadFile vs. ReadFileEx, OpenFile vs. CreateFile vs. CreateFileTransacted - they are all generally doing the same thing. This was caused by freezing the API at various points in time, and when it was discovered that this and that function can't be implemented in existing API then a new method was concocted, with just the parameters for that new function, and so on.

    But there are even more fundamental differences, when the whole API gets deprecated. For example, the Waveform API - you still can use it, but it's not nice and does not always offer you the best results. DirectX / DirectSound is more appropriate these days, though XAudio2 is also interesting, though you'd better know about X3DAudio if you are making games, though DirectSound3D could replace it for you. Fortunately, on Vista there is WASAPI in between the stack and the hardware, which only adds fun to the scope of your testing :-)