Re: GNOME Online Accounts 3.34 won't have documents support
A large part of why it was removed as it being effectively non-functional. With 3.30.1 that's been fixed, and Documents can be used as it was previously intended to. So, I would vote that we keep it in core for now, and then refine it during the 3.34 cycle. Chris On Mon, Jan 21, 2019 at 11:32 AM, mcatanz...@gnome.org wrote: We have a rule though: the account types exposed in gnome-online-accounts must be used by at least one core application. It's a good rule because it doesn't make sense to have settings in control-center for apps that aren't installed by default. So unless we reverse course and add gnome-documents back to core, the documents account configuration settings should move from control-center to gnome-documents itself. Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Mon, Jan 21, 2019 at 9:14 AM, Christopher Davis via desktop-devel-list wrote: Hi Rishi, Cloud documents is an important part of where I want to move forward with the application, so Online Accounts integration would still be critical. A file previewer is definitely a priority, and an editor could be considered. Regards, Chris We have a rule though: the account types exposed in gnome-online-accounts must be used by at least one core application. It's a good rule because it doesn't make sense to have settings in control-center for apps that aren't installed by default. So unless we reverse course and add gnome-documents back to core, the documents account configuration settings should move from control-center to gnome-documents itself. Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab postmortem
On Wed, 2019-01-02 at 15:15 +0100, Milan Crha via desktop-devel-list wrote: > On Wed, 2018-12-19 at 14:37 +, Philip Withnall wrote: > > 3. I’d like to see continued movement towards disallowing direct > > pushes to git, and requiring all commits to go through MRs (and > > CI). > > Hi, > I hope this won't go through without a good research and reasoning. I only care that the option is available for each maintainer to disallow direct pushes; not that the policy is applied to all modules. > Any such requirement would be kind of showstopper for me personally. > It > would be just double work for me when coding (issue is not merge > request), causing awful commit history, resulting in unbelievably > harder effort required to produce NEWS file content (yes, I do use > commit messages to fill the NEWS files in a semi-automated way saving > my time, which I can spend on more productive things). To name a few > major obstacles at least. I’ve just written this script for generating a NEWS entry from `git log` plus information from GitLab, which you might find useful: https://gitlab.gnome.org/pwithnall/gitlab-changelog Philip signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
Christopher Davis wrote: ... > As the new maintaner I would be against making Documents a Google Drive > client, or at least > a Drive-specific one. I was just raising further Google Drive integration as one possible direction to explore - I'm not specifically pushing for it. (My recollection is that Documents is already fairly Google-specific, so it's an obvious possibility.) > It would need to have as much support for free providers like Owncloud or > Nextcloud. I wasn't aware that Nextcloud has the concept of documents - I thought it was all just "files". Do you have any ideas for what you want to do here? Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
Hey Allan, As the new maintaner I would be against making Documents a Google Drive client, or at least a Drive-specific one. It would need to have as much support for free providers like Owncloud or Nextcloud. Chris On Mon, Jan 21, 2019 at 9:31 AM, Allan Day wrote: Bastien Nocera wrote: ... > We are currently in the 3.31.x / 3.32 development cycle. Once the > GNOME 3.32 release is done, starting from 3.33.1, I will be removing > the GNOME Documents specific integration points from GNOME Online > Accounts because we no longer encourage distributors to ship this > application as part of the default set. ... That also means that GNOME Documents is as good as dead if you do this, because the main use for it was to have a single point of entry for Cloud and local documents. I've spent a fair while trying to figure out what the future is for Documents and I haven't been able to come up with a good answer. However, that doesn't mean I'm closed to the idea! The key issue, I think, is what Michael alluded to in the other thread - what the value proposition for Documents is. My feeling is that aggregating local files and Google Docs isn't all that compelling. My impression is that "documents" is quite an amorphous category, which nowadays is often equated with "files". Documents was always closely tied to Google Docs, but then Google Drive came out and that's what people generally seem to care about nowadays. Having a top-notch Google Drive client would be great and who knows, maybe that's something that Documents could become? (Not sure how that would relate to GVFS's Google Drive support though.) I think the release team is wrong in the first place. Lack of maintainership and bugs don't equate to removal. Otherwise there would be plenty more applications to remove there... Yes I think we need a good UX vision and an understanding of the role we want each app to play. Design obviously has a role to play in communicating that, so I'm sorry if we haven't done that. Allan ___ 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: GNOME Online Accounts 3.34 won't have documents support
Hi Rishi, Cloud documents is an important part of where I want to move forward with the application, so Online Accounts integration would still be critical. A file previewer is definitely a priority, and an editor could be considered. Regards, Chris On Mon, Jan 21, 2019 at 9:03 AM, Debarshi Ray wrote: Hey, I hadn't expected this to garner so much interest! Instead of replying to each message separately, I'll try to summarize a few things into this message. First of all, this thread doesn't have anything to do with GNOME Books. It's a separate application and doesn't have any Online Accounts integration whatsoever. Books shares the gnome-documents Git repository with GNOME Documents, and that's all. I can't even find it in gnome-build-meta, which is again a separate discussion: [rishi@kolache gnome-build-meta]$ git grep gnome-books [rishi@kolache gnome-build-meta]$ Second, "evince" is a lot of different things. It could mean: * everything that's in evince.git * the libevdocument3.so.4 and libevview3.so.3 APIs * /usr/bin/evince - the thing that opens files from Nautilus * /usr/bin/evince-previewer - this is used for the GTK print preview, as Emmanuele pointed out, and has NoDisplay=true * /usr/bin/evince-thumbnailer So, for some definition of "evince", GNOME Documents has a hard dependency on it. Ideally, the evince Git repository would be split to disambiguate some of these components as far upstream as possible, instead of relying on the various downstreams to get their packaging right. But that's also a separate discussion. :) It's true that GNOME Documents was conceived as a way to seamlessly access all files local and remote. In that sense, the Online Accounts integration is crucial for it. However, it has turned out to be more complicated than that. I also don't know how excited the GNOME designers are about GNOME Documents today. For various reasons, it doesn't stand any chance of adoption unless it can open files like /usr/bin/evince. "Documents" are also notoriously complicated, as compared to music, photos or videos. For example, if somebody is working on a thesis, then everything from graphs to PDFs to the textual LaTeX sources to screenshots can be considered a document. That's almost impossible to accommodate within the current reality of GNOME Documents. Lack of prior art. Every major OS out there has some equivalent of a music, photos or videos application, but I haven't come across anything like GNOME Documents with the possible exception of Google Documents. It's somewhat difficult to get people excited about, and is related to the above point. It's much easier to get people excited about music, photos or videos, because those are "fun", while documents are "boring". See how people go crazy about Google Photos at Google I/O, or Instagram, etc.. I don't see that many people go crazy about their PDF viewer. So, can it be saved? Maybe; if we are willing to diverge from it's original goals. If somebody (hey, Christopher) wants to give GNOME Documents a fresh lease of life, I think the addition of a file previewer has to be the first priority. GNOME Documents supports a lot more formats than Evince, so, done right, this could be an advantage. The widgets for rendering ebooks, Evince and LibreOffice formats would need some scrubbing for this. Exploiting the capabilities of the LOKView widget, plus some work on LibreOffice itself, could turn GNOME Documents into a sleek and stripped down word processor. That's another idea. Neither of these things require the Online Accounts integration, though. Cheers, Rishi ___ 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: GNOME Online Accounts 3.34 won't have documents support
On Mon, 2019-01-21 at 14:03 +, Debarshi Ray wrote: > Hey, > > I hadn't expected this to garner so much interest! > > Instead of replying to each message separately, I'll try to summarize > a few things into this message. > > First of all, this thread doesn't have anything to do with GNOME > Books. It's a separate application and doesn't have any Online > Accounts integration whatsoever. Books shares the gnome-documents Git > repository with GNOME Documents, and that's all. I can't even find it > in gnome-build-meta, which is again a separate discussion: > [rishi@kolache gnome-build-meta]$ git grep gnome-books > [rishi@kolache gnome-build-meta]$ > > Second, "evince" is a lot of different things. It could mean: > * everything that's in evince.git > * the libevdocument3.so.4 and libevview3.so.3 APIs > * /usr/bin/evince - the thing that opens files from Nautilus > * /usr/bin/evince-previewer - this is used for the GTK print preview, > as Emmanuele pointed out, and has NoDisplay=true > * /usr/bin/evince-thumbnailer > > So, for some definition of "evince", GNOME Documents has a hard > dependency on it. Ideally, the evince Git repository would be split > to disambiguate some of these components as far upstream as possible, > instead of relying on the various downstreams to get their packaging > right. But that's also a separate discussion. :) So far, the only proposal or request I had seen is to build evince without UI: https://gitlab.gnome.org/GNOME/evince/issues/1048 IIUC, the outcome would be the same. > [...] > "Documents" are also notoriously complicated, as compared to music, > photos or videos. For example, if somebody is working on a thesis, > then everything from graphs to PDFs to the textual LaTeX sources to > screenshots can be considered a document. That's almost impossible > to accommodate within the current reality of GNOME Documents. The thesis user case looks to me like a corner case, and Documents might be noisy because its scope of broader than a thesis. In a thesis, a challenging part is to keep all the references (mostly papers) "together", and hopefully to manage them in a way that is easier to search, and cite. I think Documents should not bother with that, because then it would need features (or subset of them) provided by tools like Mendeley. I mean, other than searching text in a collection of documents. -- Germán Poo-Caamaño http://calcifer.org/ signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
Bastien Nocera wrote: ... > > We are currently in the 3.31.x / 3.32 development cycle. Once the > > GNOME 3.32 release is done, starting from 3.33.1, I will be removing > > the GNOME Documents specific integration points from GNOME Online > > Accounts because we no longer encourage distributors to ship this > > application as part of the default set. ... > That also means that GNOME Documents is as good as dead if you do this, > because the main use for it was to have a single point of entry for > Cloud and local documents. I've spent a fair while trying to figure out what the future is for Documents and I haven't been able to come up with a good answer. However, that doesn't mean I'm closed to the idea! The key issue, I think, is what Michael alluded to in the other thread - what the value proposition for Documents is. My feeling is that aggregating local files and Google Docs isn't all that compelling. My impression is that "documents" is quite an amorphous category, which nowadays is often equated with "files". Documents was always closely tied to Google Docs, but then Google Drive came out and that's what people generally seem to care about nowadays. Having a top-notch Google Drive client would be great and who knows, maybe that's something that Documents could become? (Not sure how that would relate to GVFS's Google Drive support though.) > I think the release team is wrong in the first place. Lack of > maintainership and bugs don't equate to removal. Otherwise there would > be plenty more applications to remove there... Yes I think we need a good UX vision and an understanding of the role we want each app to play. Design obviously has a role to play in communicating that, so I'm sorry if we haven't done that. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Request "File-clipboard"
Hi Patrick, this is a bit late but still... Le 2019-01-05 11:41, Patrick H. a écrit : I've got the following idea: Often we want to send a scanned document or something like that to somebody. We then have to save the document and open it then in the mail-client or Telegram or Signal or something else. It would be nice to have a "Save to file-clipboard"-button in the Save-window and a "Open from file-clipboard"-button in the open-window. So the file doesn't have to be saved really (and deleted after sending). You may have missed the "recent files" workflow. After you scan your document, when you save it, it's added to the recent files list. When you then want to add it as an attachment inside your mail, your email client opens the file chooser[1]. On the left panel, select "Recent", and the last document you saved should appear on top of the list in the right panel. Hope this helps. [1] https://developer.gnome.org/gtk3/stable/filechooser.png Cheers, -- Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
Hey, I hadn't expected this to garner so much interest! Instead of replying to each message separately, I'll try to summarize a few things into this message. First of all, this thread doesn't have anything to do with GNOME Books. It's a separate application and doesn't have any Online Accounts integration whatsoever. Books shares the gnome-documents Git repository with GNOME Documents, and that's all. I can't even find it in gnome-build-meta, which is again a separate discussion: [rishi@kolache gnome-build-meta]$ git grep gnome-books [rishi@kolache gnome-build-meta]$ Second, "evince" is a lot of different things. It could mean: * everything that's in evince.git * the libevdocument3.so.4 and libevview3.so.3 APIs * /usr/bin/evince - the thing that opens files from Nautilus * /usr/bin/evince-previewer - this is used for the GTK print preview, as Emmanuele pointed out, and has NoDisplay=true * /usr/bin/evince-thumbnailer So, for some definition of "evince", GNOME Documents has a hard dependency on it. Ideally, the evince Git repository would be split to disambiguate some of these components as far upstream as possible, instead of relying on the various downstreams to get their packaging right. But that's also a separate discussion. :) It's true that GNOME Documents was conceived as a way to seamlessly access all files local and remote. In that sense, the Online Accounts integration is crucial for it. However, it has turned out to be more complicated than that. I also don't know how excited the GNOME designers are about GNOME Documents today. For various reasons, it doesn't stand any chance of adoption unless it can open files like /usr/bin/evince. "Documents" are also notoriously complicated, as compared to music, photos or videos. For example, if somebody is working on a thesis, then everything from graphs to PDFs to the textual LaTeX sources to screenshots can be considered a document. That's almost impossible to accommodate within the current reality of GNOME Documents. Lack of prior art. Every major OS out there has some equivalent of a music, photos or videos application, but I haven't come across anything like GNOME Documents with the possible exception of Google Documents. It's somewhat difficult to get people excited about, and is related to the above point. It's much easier to get people excited about music, photos or videos, because those are "fun", while documents are "boring". See how people go crazy about Google Photos at Google I/O, or Instagram, etc.. I don't see that many people go crazy about their PDF viewer. So, can it be saved? Maybe; if we are willing to diverge from it's original goals. If somebody (hey, Christopher) wants to give GNOME Documents a fresh lease of life, I think the addition of a file previewer has to be the first priority. GNOME Documents supports a lot more formats than Evince, so, done right, this could be an advantage. The widgets for rendering ebooks, Evince and LibreOffice formats would need some scrubbing for this. Exploiting the capabilities of the LOKView widget, plus some work on LibreOffice itself, could turn GNOME Documents into a sleek and stripped down word processor. That's another idea. Neither of these things require the Online Accounts integration, though. Cheers, Rishi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Thu, Jan 17, 2019 at 10:38:50AM -0500, Jeremy Bicha wrote: > Similarly, Todoist support was dropped from GOA 3.32. > > https://gitlab.gnome.org/GNOME/gnome-online-accounts/commit/bf77325d8 > > The commit message has a few mistakes: the Recipes app does not yet > have its own Todoist support. [rishi@kolache recipes]$ git grep -i todoist src | wc -l 43 Select a recipe -> Buy ingredients -> View shopping list -> Share -> Add service -> Todoist > And it's wrong to say that GNOME To Do > does not follow the GNOME release schedule. https://download.gnome.org/sources/gnome-todo/3.91/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
