[Feature Request] Send location

[NonnEmilia]

It would be nice to implement the "Send location" feature as in the mobile app. For example to use Telegram bots that are requiring location to send infos like weather forecasts or bus stops in the neighborhood.

[123RaZoR321]

It would be great to implement support for Windows Location API. Nowadays many Windows tablets have built-in GPS.

[stek29]

@123RaZoR321 And for OS X one, and for hundreds of Linux ones)

[AndydeCleyre]

http://doc.qt.io/qt-5/qtpositioning-index.html

The Qt Positioning API provides positioning information via QML and C++ interfaces.

Currently the API is supported on Android, iOS, OS X, Linux (using GeoClue version 0.12.99), Windows (with GPS receivers exposed as a serial port providing NMEA sentences), and WinRT (using Windows.Devices.Geolocation).

[john-preston]

@AndydeCleyre And QtWebEngine to display google maps to choose the point? :)

[AndydeCleyre]

@john-preston That's a good option, but maybe using

http://doc.qt.io/qt-5/location-maps-qml.html

would make for a more "native" experience.

[john-preston]

@AndydeCleyre Bringing QtQuick for that I'm afraid will be even more overkill than QtWebEngine.. But I didn't make a research yet. Perhaps QtWebEngine can't be statically linked (QtWebkit was not possible to link statically), so it is not about tdesktop currently.

[AndydeCleyre]

@john-preston Isn't finally allowing dynamic linking part of the plan anyway?

[john-preston]

@AndydeCleyre No such plans in work right now. It will significantly complicate many things, starting with autoupdate.

[AndydeCleyre]

@john-preston I'll try to stop at this one as I'm getting off-topic, but an application should absolutely not be handling the installation of its own updates. This is clearly the job of a package manager. Self-updating apps are a hideous kludge to work around missing package managers.

• All popular mobile OSs have decent package managers (Google Play, App Store, etc.).
• Linux desktops certainly do.
• OS X has the App Store plus homebrew to fill in the gaps.
• Windows desktop . . . I don't know. But even if it has nothing, you could just link to the installer download page.

So you say it would complicate things. Well, it would also simplify things. And maybe the things that it would complicate really should be revisited.

[john-preston]

@AndydeCleyre Well, we won't agree on this one, I guess. For me, the best way a software can handle its updates is like Google Chrome does. Frequent updates, almost unnoticed by user, done completely by the app itself, without disturbing the user - that's what Chrome widely introduced and what was one of the key features for it to get such a huge market share.

So for me, an application absolutely should handle its own updates - the best way is to be like a web service, where you each time open the latest version of the web app, there is even no such thing as an update.

App stores on the phones are doing two different jobs: allowing user to find himself an app + allowing OS to control which app he can install. The first one is fine, but the second is really bad in my opinion and I hope that desktops will not fall in such madness (that I can't install an app I want - outside the store, that is controlled by the OS vendor). Apple is just performing censorship on the app store, removing all apps it doesn't want to exist on the platform, no matter what users want to use. The app store version of tdesktop has less features, is slower updated (even when it is critical), requires to pass a review for every update.

Telegram Desktop is a cross platform app that works in a unified way on all the supported platforms. On Windows (which was more than 95% of users when I last checked) the in-app auto update is the best and only way to have an up-to-date app, on OS X it is much better than the app store madness, so on Linux, which is less than 3%, it just works as it does in other OSs (in the easiest way for the user - he downloads the app from the official website, starts using it and doesn't think about it ever more - the app is just updated as soon as it has a new version).

Yes, I know, that on Linux, there is another way to do that, through package managers (as I know there are many different). Perhaps some day I'll be able to prepare all the packages for those managers as well as a simple download-n-run version, but not right now. The community members, as far as I know, already maintain some of those.

[tmladek]

Still no progress? 😢 Came here from this SO link which puts it quite succinctly:

UPDATE: as of May 2016 Telegram Desktop for Mac (v. 2.10.45.133) has this feature. The Linux desktop version has not this feature (v. 0.9.42). Nov 2016: Windows desktop client (v. 0.10.19) still doesn't have this feature. Feb 2017: Windows desktop client (v. 1.0.12) still doesn't have this feature. Jun 2017: Windows desktop client (v. 1.1.7) still doesn't have this feature.

[AndydeCleyre]

App stores on the phones are doing two different jobs: allowing user to find himself an app + allowing OS to control which app he can install. The first one is fine, but the second is really bad in my opinion and I hope that desktops will not fall in such madness (that I can't install an app I want - outside the store, that is controlled by the OS vendor).

FYI, that's not how the Linux package managers work -- you can always add out-of-repo packages, as well as custom repos altogether.

[auchri]

@AndydeCleyre There is a build option to disable the built in updater.

[AndydeCleyre]

Thanks @auchri , good to know, though not the point of that exchange, which was @john-preston 's resistance to dynamic linking.

[auchri]

@AndydeCleyre Yes I know, just wanted to state that there is a way to disable the updater.

But let's stop with this off topic stuff now.

[AndydeCleyre]

As far as I understand, it's a significant factor in @john-preston 's decision not to bring location sharing to the cross-platform client, which is exactly the topic of this issue discussion. But I will try not to comment on this issue further since I think I'm annoying the devs.

[omkarnathsingh]

Any update on this?

[YuriyLitvin]

Prepared a small Telegram bot to help solve this issue: https://t.me/SelectLocationBot Maybe later it can be used to prepare a production ready solution.

[stale[bot]]

Hey there!

This issue will be automatically closed in 7 days if there would be no activity. We therefore assume that the user has lost interest or resolved the problem on their own.

Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

[tmladek]

Hello bot, I would still like to see this feature in tg-desktop :)

[stale[bot]]

Hey there!

This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.

Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

[YuriyLitvin]

I think it is very important to have this possibility.

[ilya-fedin]

Some time ago, I implemented bindings to system APIs in tdesktop's lib_base via https://github.com/desktop-app/lib_base/pull/70. It uses Sensors API on Windows and gpsd on Linux, with Wi-Fi/BT/cellular geolocation via Mozilla Geolocation Service (and NetworkManager/Bluez/ModemManager on Linux) as fallback. Wi-FI & BT is implemented on both Windows and Linux, while cellular geolocation is implemented only on Linux (it won't work well as ModemManager exposes information only about the current base station, I tested with a 3G Huawei modem) as I haven't found an API for that on Windows, Mobile Broadband API doesn't expose that info. I haven't implemented anything for macOS as Apple doesn't want its ecosystem to be open, well, neither I need it.

I don't think this feature request will be implemented any time soon, though, as @john-preston needs to implement the UI part, while he doesn't have time and this is not a priority.

[ogtayhuseynov0]

👀

[Jokero]

Any news maybe? Current behaviour is inconsistent on the platform. Mobile clients send location (if request_location=true), while desktop doesn't (even without any error or possibility for fallback).

[ilya-fedin]

No news unfortunately, there's no one to implement the UI part.

[Nashev]

I miss this too

[VetaLioSTV]

Definitely it should be implemented.

[Jokero]

Does anyone know why InformBox with lng_bot_share_location_unavailable message is not displayed (at least in macOS application)?

case ButtonType::RequestLocation: {
    HideSingleUseKeyboard(controller, item);
    controller->show(
        Ui::MakeInformBox(tr::lng_bot_share_location_unavailable()));
}

https://github.com/telegramdesktop/tdesktop/blob/v4.5.2/Telegram/SourceFiles/api/api_bot.cpp#L356-L360

Can we maybe also send the button text to the chat (as any other text button does)? In this case we will be able to send a fallback message to user like Please, attach your current location.. This will require minor code changes, but will improve the UX. What do you think?

[john-preston]

@Jokero I guess you're talking about the native macOS app (Telegram Swift, see https://github.com/overtake/TelegramSwift).

Telegram Desktop shows this message correctly and it can't attach the location, so the user should see this message and go to a mobile app to use that bot feature :(

[Jokero]

@john-preston ohh, you're right, I didn't even know about the other app 🤦. Thanks for information, I can confirm that the message is displayed

[Aokromes]

5.3.0 added send location, idk if it fits your needs.

[NonnEmilia]

Yay! The "send location" feature has been added in v5.3.0! 🎉 🙏

[800147]

Still doesn't work on Linux :( v5.5.3