search

fastcat / nuvola-app-google-keep

Integration of Google Calendar web app into your linux desktop via an experimental Nuvola Apps Alpha mode of Nuvola Player.
BSD 2-Clause "Simplified" License
0 stars 0 forks source link

Push to Nuvola Player project #1

Open fastcat opened 8 years ago

fastcat commented 8 years ago

Seems to work ... nothing fancy

jiri-janousek commented 7 years ago

Hello @fastcat. Could you port your script to the Nuvola SDK? sudo pip3 install -U nuvolasdk; nuvolasdk convert-project should do the trick. If not, please [create a bug report]().

fastcat commented 7 years ago

Done -- 2d65986ec852bf19d1061157031c8df9e9d906b6

I should note that rendering of Google Keep in WebKitGTK is currently broken -- this is not a nuvolaplayer3 issue, as I verified it is also a problem in the WebKit MiniBrowser. Something seems to be wrong with float positioning I'm guessing, causing all the notes (and all the list items inside a checkboxes-enabled note) to render atop one another.

I've also noticed that the logic to detect links that should open in an external app, inherited from the Google Calendar integration, is broken in both. I have a suspicion this is related to click tracking -- links that functionally open in new windows don't have the initial new window flag set that the integration JavaScript uses to detect "external" links.

jiri-janousek commented 7 years ago

Great :-) Could you transfer the repository to the Nuvola Maintainers team? You will be still the main maintainer.

I should note that rendering of Google Keep in WebKitGTK is currently broken -- this is not a nuvolaplayer3 issue, as I verified it is also a problem in the WebKit MiniBrowser. Something seems to be wrong with float positioning I'm guessing, causing all the notes (and all the list items inside a checkboxes-enabled note) to render atop one another.

It occurs also in the latest unstable WebKitGTK 2.15.91. How experienced with HTML, CSS and JavaScript are you? Are you able to find a hot fix? Or could you create a bug report at WebKitGtk?

I've also noticed that the logic to detect links that should open in an external app, inherited from the Google Calendar integration, is broken in both. I have a suspicion this is related to click tracking -- links that functionally open in new windows don't have the initial new window flag set that the integration JavaScript uses to detect "external" links.

Well, this is a bug introduced in tiliado/nuvolaplayer@b8716717. So I've just fixed it in the master branch. The fix is also available in the master branch of flatpak builds and will be later propagated to other builds as well.

Could you test the flatpak build? DEB/RPM builds of new scripts are not going to be provided.

apt install flatpak xdg-desktop-portal-gtk
reboot # to add Flatpak directories to various system paths
flatpak remote-add --from gnome https://sdk.gnome.org/gnome.flatpakrepo
flatpak remote-add --from nuvola https://dl.tiliado.eu/flatpak/nuvola.flatpakrepo
flatpak install gnome org.gnome.Platform//3.22
flatpak install nuvola eu.tiliado.Nuvola//master eu.tiliado.NuvolaAppGoogleKeep//master
jiri-janousek commented 7 years ago

Also, your Tiliado account has been upgraded to a developer account. (3.1 Rolling Releases are currently available only to developers and patrons.)

fastcat commented 7 years ago

The decision to go pure-flatpak begets the obligatory: https://xkcd.com/927/

Adding a new package management system and installing duplicate copies of system libraries using tools that don't integrate with the distro system & security update tools ... just for one app ... not high on my list of things I'm likely to do.

I love nuvolaplayer, and I understand why something like flatpak is attractive from a developer point of view. But only supporting that ends up being pretty hostile from a user point of view.

☹️

jiri-janousek commented 7 years ago

Thanks for sharing your concerns about flatpak builds. Every feedback is important in this phase, especially the negative one. I believe Flatpak builds of Nuvola are a huge step forward because Flatpak finally, after years of struggling, allows Nuvola project to pursue its goals and users will benefit from it. (I have been writing an article on this topic.)

The decision to go pure-flatpak begets the obligatory: https://xkcd.com/927/

Well, there are now only two competing standards - Flatpak and Snap - and I think there is healthy competition between them.

Adding a new package management system and installing duplicate copies of system libraries using tools that don't integrate with the distro system & security update tools ... just for one app ... not high on my list of things I'm likely to do.

This is a pretty valid point. I'm afraid Nuvola will lose some users because of that. On the other hand, it may get new users from distributions where Nuvola packages have never been available or are poorly maintained.

I love nuvolaplayer, and I understand why something like flatpak is attractive from a developer point of view. But only supporting that ends up being pretty hostile from a user point of view.

The decision to support only Flatpak is simply driven by the lack of manpower as the Nuvola project has only a single core developer. It is still possible to provide DEB/RPM packages if volunteers are found to take over this task. Are you interested?

fastcat commented 7 years ago

Well, there are now only two competing standards - Flatpak and Snap - and I think there is healthy competition between them.

And deb and rpm and Arch's thing, and Slackware's thing, and ... My point here is mainly that Flatpak and Snap are not the "native" package format of any major distribution (AFAIK). Getting one to be the native/primary package manager for a major distro might be as hard as e.g. getting Red Hat to switch to DEBs. Or maybe they get lucky and some distros ship native support for them in their core package manager -- that seems more likely, but still all speculation.

It is still possible to provide DEB/RPM packages if volunteers are found to take over this task. Are you interested?

To be honest, at the moment I'm giving Google Play Music Desktop Player a whirl. Thus far it has upsides and downsides compared to NuvolaPlayer (packaging and otherwise). GPM itself seems to run smoother in it for whatever reason (presumably down to the different browser core), and flash-less playback works out of the box, but of course it doesn't have the easy extensibility of NuvolaPlayer to other/custom web apps.

If I come back to NuvolaPlayer, I would be interested in contributing to the packaging, at least for Debian/Ubuntu packages. I think I have the know-how (I've done some basic dpkg work before), and I definitely have the resources (hardware with sufficient disk space and cpu/memory to run VMs/containers to do clean builds).

jiri-janousek commented 7 years ago

Well, there are now only two competing standards - Flatpak and Snap - and I think there is healthy competition between them.

And deb and rpm and Arch's thing, and Slackware's thing, and ...

These are not competitors of Flatpak and Snap at all. The mission of Flatpak and Snap is to provide cross-distribution framework for distribution of sandboxed (desktop) apps. They are designed to coexist with traditional package managers, not to replace them.

My point here is mainly that Flatpak and Snap are not the "native" package format of any major distribution (AFAIK). Getting one to be the native/primary package manager for a major distro might be as hard as e.g. getting Red Hat to switch to DEBs.

That's not the goal of Flatpak nor Snap.

Or maybe they get lucky and some distros ship native support for them in their core package manager -- that seems more likely, but still all speculation.

There is no need for that in low-level core package managers. in case of high-level package managers, GNOME Software 3.22 already supports Flatpak.

If I come back to NuvolaPlayer, I would be interested in contributing to the packaging, at least for Debian/Ubuntu packages. I think I have the know-how (I've done some basic dpkg work before), and I definitely have the resources (hardware with sufficient disk space and cpu/memory to run VMs/containers to do clean builds).

Looking forward to that :-)

fastcat commented 7 years ago

These are not competitors of Flatpak and Snap at all. The mission of Flatpak and Snap is to provide cross-distribution framework for distribution of sandboxed (desktop) apps. They are designed to coexist with traditional package managers, not to replace them. ... There is no need for that in low-level core package managers. in case of high-level package managers, GNOME Software 3.22 already supports Flatpak.

Aah, and now I understand the disconnect. I was coming at it from the context of "I mostly live on the command line and need to run apt/yum update/upgrade on 30+ machines, Flatpak/Snap don't play nice with that."

And if GNOME's package management GUI can process Flatpak & Snap, I'm sure some creative person could eventually update apt & yum to process them too, even if I'm not going to hold my breath there.