Re: [heads-up] evolution-data-server is libsoup3 now
ons 2022-06-22 klockan 13:13 +0200 skrev Milan Crha via desktop-devel- list: > Hello, > just a quick heads-up, the evolution-data-server development version > is > libsoup3 now; it will be the 3.45.1 release. The port depends on > libsoup3 change [1], which improves libsoup3 use in multi-threaded > applications. > > Most people are probably aware, all apps using the evolution-data- > server directly or indirectly need to use libsoup3 as well, the same > their dependencies, because libsoup2 and libsoup3 cannot be loaded > into > the same process at the same time (doing so aborts the application > with > an appropriate message). > > One thing, the libgdata has a pending merge request for the port to > the > libsoup3, but it needs more testing and such. > Use -DENABLE_GOOGLE=OFF CMake option until it's sorted out. The > option > disables the Google tasks support only. I may extract necessary bits > out of the libgdata to not depend on libgdata at all, but no promises > whether I'll make it on time for the 3.45.1. See [2] for some > insights. > > Of course, Evolution itself and evolution-ews will be ported to the > libsoup3 at the same time. Hi! Maps still depends on libsoup 2 (we get this dependency via libchamplain, and it is unlikly to get ported…) Problem is we haven't yet declared libshumate as "1.0" stable, and there's probably a couple of things to iron out before porting Maps itself to it (and GTK 4), and this is a pretty big undertaking, and I'm a bit concerned about being able to pull it off this late in the cycle. One option I think is to drop the contact address lookup in Maps (we use e-d-s via libfolks to match searches on contacts who have addresses). Not sure if this is used that much, and it's probably less use now since 42 when Contacts has a button to launch Maps with a search query based on the address for contacts who have an address set. //Marcus > > Bye, > Milan > > [1] https://gitlab.gnome.org/GNOME/libsoup/-/merge_requests/283 > [2] > https://discourse.gnome.org/t/giving-up-maintainership-of-libgdata/9983 > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
gnome-maps' default branch is now "main"
Hi! Just wanted to inform that Maps has now changed the default branch from "master" to "main". //Marcus ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Possible code freeze exception request for Maps 42.1
Hi! In https://gitlab.gnome.org/GNOME/gnome-maps/-/issues/438 it has been brought up that gnome-maps is only package depending on the older 3.x libgweather in Debian (and Ubuntu also, I think). I made a small patch in https://gitlab.gnome.org/GNOME/gnome-maps/-/merge_requests/218 Apart from adjusting the Flatpak manifest for building development snapshots (would not affect a possible inclusion in 42.1), the only change is upgrading the GI package "require" version for GWeather from 3.0 to 4.0. The small parts of the libgweather API we use in Maps is unchanged in 4.0. I think this should probably be pretty safe, since libgweather 4 is already used in GNOME 42. And I think trying to fallback to libgweather 3 might not be worth the added complexity. //Marcus ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Is any GNOME project using Mapbox legacy classic tiles with the GNOME API key?
mån 2020-06-08 klockan 22:29 +0100 skrev Emmanuele Bassi: > Could it be caused by users of Maps on some long term support Linux > distributions, like Ubuntu 16.04/18.04, or RHEL7/8? > They should still pull the .json from gis.gnome.org (which has the new ones…), there is one small caveat, we have a fallback hardcoded that is used if the request to gis.gnome.org fails.So if some old clients where used, and during that time the server was not responding, they would be using their (outdated) fallback.Maybe that was the case… //Marcus > Ciao, > Emmanuele. > > On Mon, 8 Jun 2020 at 22:00, Marcus Lundblad via desktop-devel-list < > desktop-devel-list@gnome.org> wrote: > > Hi! > > > > > > > > As Mapbox has deprecated the old classic tiles, they have been > > sending > > > > out notification e-mails to users who have accessed the classic > > styles > > > > recently. And the key we use for GNOME Maps have been flagged for > > this. > > > > I have doublechecked our tile definition, and it should use the new > > > > tile sets. In Maps we download the tile definitions dynamically > > from a > > > > service file (we have never hardcoded the tile URLs since the > > migration > > > > from MapQuest back in 2016, though we did use a proxy briefly, but > > > > stopped that, and the proxy should not working since quite a long > > time > > > > AFAIK). > > > > > > > > I just wanted to check to see if maybe there is some other project > > in > > > > GNOME that uses this service (and is still use using classic > > styles( > > > > that I have missed? > > > > > > > > The old classic tiles use a URI like (for the "streets" style): > > > > > > > > https://a.tiles.mapbox.com/v4/mapbox.streets/#Z#/#X#/#Y#.png?access_token= > > > > > > > > and the new ones: > > > > > > > > https://api.mapbox.com/styles/v1/mapbox/streets-v11/tiles/#Z#/#X#/#Y#?access_token= > > > > > > > > Or maybe some distribution has a patched version of Maps using the > > > > legacy style? > > > > > > > > And also the usage figures that Mapbox provided was only referring > > to > > > > the classic style for "streets", not the satellite one. Oh, and > > also, > > > > the classic style tiles have not received any updates since > > sometime in > > > > 2018. > > > > > > > > Thanks! > > > > //Marcus > > > > > > > > > > > > ___ > > > > desktop-devel-list mailing list > > > > desktop-devel-list@gnome.org > > > > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Is any GNOME project using Mapbox legacy classic tiles with the GNOME API key?
Hi! As Mapbox has deprecated the old classic tiles, they have been sending out notification e-mails to users who have accessed the classic styles recently. And the key we use for GNOME Maps have been flagged for this. I have doublechecked our tile definition, and it should use the new tile sets. In Maps we download the tile definitions dynamically from a service file (we have never hardcoded the tile URLs since the migration from MapQuest back in 2016, though we did use a proxy briefly, but stopped that, and the proxy should not working since quite a long time AFAIK). I just wanted to check to see if maybe there is some other project in GNOME that uses this service (and is still use using classic styles( that I have missed? The old classic tiles use a URI like (for the "streets" style): https://a.tiles.mapbox.com/v4/mapbox.streets/#Z#/#X#/#Y#.png?access_token= and the new ones: https://api.mapbox.com/styles/v1/mapbox/streets-v11/tiles/#Z#/#X#/#Y#?access_token= Or maybe some distribution has a patched version of Maps using the legacy style? And also the usage figures that Mapbox provided was only referring to the classic style for "streets", not the satellite one. Oh, and also, the classic style tiles have not received any updates since sometime in 2018. Thanks! //Marcus ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Some nigthly flatpaks are failing to build
tor 2019-08-01 klockan 17:38 +0200 skrev Milan Crha via desktop-devel- list: > On Thu, 2019-08-01 at 10:13 -0300, Isaque Galdino via desktop-devel- > list wrote: > > Notes is failing due to EDS. Once EDS changes to gettext, Notes > > should be fine. > > Hi, > from what the Goal page references: > https://gitlab.gnome.org/GNOME/evolution-data-server/issues/77 > > Long story short: This won't happen (any time soon). If you have any > flatpak/CI/whatever, which depends on evolution-data-server to be > built > too, then include intltool in the Flatpak manifest for it. > OK. Thanks for the heads-up! Added intltool to Maps' Flatpak manifest, so now it's green! //Marcus > I'm sorry. > Bye, > Milan > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Some nigthly flatpaks are failing to build
tor 2019-08-01 klockan 10:13 -0300 skrev Isaque Galdino via desktop- devel-list: Hi Javier, how are you? Notes is failing due to EDS. Once EDS changes to gettext, Notes should be fine. Thanks. And Maps as well. Thanks! //Marcus > > Em qui, 1 de ago de 2019 às 08:22, Javier Jardón > escreveu: > > Hi, > > > > > > > > It came to my attention [1] several of the nigthly flatpaks of our > > > > core apps stop building against the latest GNOME flatpak runtime > > > > > > > > Taking a look to the build failures, seems the main problems are: > > > > > > > > 1. Some of the modules depend on intltool or gnome-common; those > > are > > > > not in the SDK anymore. > > > > Solutions: > > > > - Check a more version of the component doesnt depend on those > > already > > > > (new versions of gnome-desktop doesnt depend on gettext/gnome- > > common, > > > > for example) > > > > - Port component to use gettext [2] > > > > - Port component to not use gnome-common [3] > > > > - (less preferable) Include intltool/gnome-common on your manifest, > > as > > > > a submodule [4] or directly in it [5] > > > > > > > > 2. Build failure with the gspell dependency; this is [6] > > > > Solution: > > > > - Try to fix [6] or, in the meantime, depend on the latest release > > > > tarball/tag instead master [7] > > > > > > > > Please apply those fixes asap so we can have full green for the > > next > > > > GNOME 3.34 release! > > > > > > > > Many thanks, > > > > Javier Jardon, > > > > GNOME Release Team > > > > > > > > [1] > > https://mbridon.pages.gitlab.gnome.org/flatpak-master-dashboard/ > > > > [2] https://wiki.gnome.org/Initiatives/GnomeGoals/GettextMigration > > > > [3] https://wiki.gnome.org/Projects/GnomeCommon/Migration > > > > [4] > > https://gitlab.gnome.org/GNOME/gnome-builder/merge_requests/205/diffs > > > > [5] > > https://gitlab.gnome.org/GNOME/gnome-builder/commit/806263d900da0fef016f962ad2a64f8afea272f3 > > > > [6] https://gitlab.gnome.org/GNOME/gspell/issues/6 > > > > [7] > > https://gitlab.gnome.org/GNOME/gnome-build-meta/commit/a93ce4fa1fcf508cee0a0063a8f12edd3f18c807 > > > > ___ > > > > desktop-devel-list mailing list > > > > desktop-devel-list@gnome.org > > > > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > > > > > ___desktop-devel-list > mailing listdesktop-devel-l...@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Sharing locations in Maps
Hi all! I wanted to discuss some things around sharing. Currently in Maps we have a dialog to share locations with a fixed set of apps, Weather, Clocks, and the default browser. There are a couple of problems with this. First, detecting if Weather and Clocks are available currently not possible in Flatpaks (maybe there is a "portal" to detect such things, and also launch apps). Secondly these interact kinda poorly. For example sharing a location with Clocks will permanently add that location in Clocks with the name of the place (such as the name of a shop). The option for the browser (which opens the location on the openstreetmap.org site is somewhat more useful. I recall there being some discussions before about a "sharing portal" (sharing a location might then share that as the object's URL on OSM). Is something like this already in place? (allowing sharing links with i.e. e-mail clients). A sorta "stop-gap" solution I was thinking about might be to have a dialog with read-only text entry filled with the URL allowing to copy- paste this (I think Google Maps have something similar, using a shortened URL). A companion feature for this could be to allow opening such URLs (and add Maps as a handler for HTTP(S) URIs). But maybe that would be considered bad praxis (not sure if it's possible to ensure that it would always have lower priority that any proper browsers). Ideally it would have cool to be able to add URI handlers for certain URL patterns. I brought up this at some point on IRC. But this would probably need quite some changes in how mime-handling is done. For the Clocks and Weather sharing, one option might be to show local time, or time difference and local weather (this would probably need an on/off switch for privacy reasons) directly in the "place bubbles". Or maybe skip this, assuming the user could just look up these things manually in the respective apps if wanted. Any thoughts? //Marcus ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: The status of Maps right now
ons 2016-07-13 klockan 07:16 +0200 skrev Jonas Danielsson: > Hi! > > As of recently GNOME Maps can no longer fetch tiles to display. This > is because MapQuest, > which we use as a tile provider, changed its usage policy[1]. > And we are no longer able to use the service without paying. We have > as of know no clear alternative. > > We _could_ switch to OpenStreetMap own tile servers, see patches in > bug[2]. But we would probably > violate the terms of service[3]. Unless we, as GNOME, could argue we > should be allowed. I have made some inquiries into possibly using OpenStreeMap tiles as a temporary solution for now. An idea might be to set up a simple proxy for now pointing from tiles.gnome.org → tiles.openstreetmap.org This way we could later switch this site over to a full-blown stand- alone tile server. Although I would most probably need help in setting up a web proxy. > > This all brings me to a general status report for Maps. I have been > absent from the project lately. > The reason is lack of time and motivation. Day Job and family have > been taken front seat for awhile. > Marcus, Andreas, Amisha and the rest of the team have been keeping up > with some things. But we > no-one have been making releases. > > I will need some help. Help with contacting OpenStreetMap. Help with > finding solution to our tile > issue. I think we are going to need our own tiles.gnome.org for a map > appplication/platform > to be feasible. > > Also help with making releases and reviewing patches. It is something > I would gladly help > someone get started with. Making a release is something anyone could > do really. > > I am sorry for my neglect. And I hope I have not caused to much > frustration. > No problems! As others have also pointed out, this is all volontary stuff, so no-one should have to feel any obligations like that. //Marcus > Regards > Jonas > > [1]: http://devblog.mapquest.com/2016/06/15/modernization-of-mapquest > -results-in-changes-to-open-tile-access/ > [2]: https://bugzilla.gnome.org/show_bug.cgi?id=764841 > [3]: http://wiki.openstreetmap.org/wiki/Tile_usage_policy > ___ > maps-list mailing list > maps-l...@gnome.org > https://mail.gnome.org/mailman/listinfo/maps-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
