Re: [XXE] Bug: Date stille 'touched' when moving folders with Google Drive plug-in
On 6 Aug 2017, at 17:15, Hussein Shafie wrote: On 08/06/2017 10:09 AM, Leif Halvard Silli wrote: And that, in turn, means that I can just as well let XXE interface with the local Google Drive folder on my harddisk. And thus, since I need that app, the Google Drive plug in is not all that useful, even for working with Google Drive. XMLmind XML Editor - Using Google Drive™ as an XML Document Repository 1. Why use this add-on? http://www.xmlmind.com/xmleditor/_distrib/doc/gdrive/why_use_it.html 3. Teamwork on the Google Drive http://www.xmlmind.com/xmleditor/_distrib/doc/gdrive/teamwork.html 4. Working with revisions (or “who did what and when?”) http://www.xmlmind.com/xmleditor/_distrib/doc/gdrive/working_with_revisions.html Those instructions were very useful to us when we first started to use XXE+Google Drive for our HTML-based book projects (see below). However, if the Google Drive plug-in is not useful to anyone, we'll be glad to discontinue it. Less code to maintain. Less end-user support. Let me give you a more nuanced picture of our experience, then. It would have been nice and useful to use both the Google Drive plug-in **and** the Google Drive App, if only the Google Drive App was not so annoying for the type of output that the XXE DITA and Docbook conversion creates. But the fact that Dropbox handles numerous small files better does not mean that it is a good authoring strategy to keep regenerating the same numorous icon files, over and over ... ! Thus, there are two things XML Mind could do with XXE so that the Google Drive experience - and even the day to day Docbook and DITA experience - would become less annoying: 1. The XXE HTML-conversion tools could be made to generate the navigation icon files only once - instead of generating them on every single conversion. 2. The XXE HTML-conversion tools could, instead of a single image file for each button, switch to generate a single CSS sprite (a single, combined, image file with all the navigation icons) for all the navigation buttons. I can say that I have found the Google Drive plug-in quite useful when working on XHTML files. For instance, we have two books made as XHTML files which are glued together via XInclude. (We combined XXE’s Google Drive plug-in with the Google Drive app.) And I believe that one reason why it worked quite well in that case was that, when one is working on XHTML files, one is working on the end product. Thus I have control over the number of image files that get created. Plus that the images, in such a case, is not regenerated over and over. (We still work on those books, and thus we will probably continue to use Google Drive plug-in and app the same way, for those projects.) But when working with DocBook or DITA, the situation is unfortunately different. The last step - namely conversion to HTML - causes numerous navigation icon files to be created. And this happens over and over - on every conversion. Even if, as far as I can tell, for all the icon files, the date is the only thing that changes). On the Web, numerous small images is a bad authoring practise that causes Web pages to load more slowly. Therefore, for the Web, the technique called “CSS sprites” have been developed. As W3Schools explains, an CSS sprite is [”a collection of images put into a single image”](https://www.w3schools.com/css/css_image_sprites.asp). Thus, instead of many small images, the browser loads a larger image consisting of many smaller images. Via CSS, only the relevant part of the image is displayed. This implies using CSS background images instead of pointing directly to the image via the @src attribute of an element. (I am no expert at creating sprites my self - I just know the basic technique.) Even when generating documents on a harddisk, it takes considerable more time to generate numerous small images compared with a single larger one. An even faster solution would be if the image would be generated only on the first generation - and not on the subsequent generations. (In fact, two only generate the images on the first conversion would *considerably* bring down the synchronization activity of Google Drive!) I am mentioning this because there are several issues that contribute to how well or bad the user experience turns out. If the XXE conversion functionality for DITA and Docbook had, for its HTML output, used CSS sprites instead of images for its navigation buttons, there should be a massive speed gain when syncing (via the Google Drive app). Such a thing should also bring a considerable speed bump during the conversion process - it would be good even for non-Google Drive users. I realize that for the Docbook conversion, you rely on the ’official’ XSL stylesheets - which do not use CSS sprites. But perhaps you could switch to CSS sprites for the DITA conversion ... ? Btw, for Web sites, in general, my Web page design tool has, for many
Re: [XXE] Bug: Date stille 'touched' when moving folders with Google Drive plug-in
On 08/06/2017 10:09 AM, Leif Halvard Silli wrote: And that, in turn, means that I can just as well let XXE interface with the local Google Drive folder on my harddisk. And thus, since I need that app, the Google Drive plug in is not all that useful, even for working with Google Drive. XMLmind XML Editor - Using Google Drive™ as an XML Document Repository 1. Why use this add-on? http://www.xmlmind.com/xmleditor/_distrib/doc/gdrive/why_use_it.html 3. Teamwork on the Google Drive http://www.xmlmind.com/xmleditor/_distrib/doc/gdrive/teamwork.html 4. Working with revisions (or “who did what and when?”) http://www.xmlmind.com/xmleditor/_distrib/doc/gdrive/working_with_revisions.html However, if the Google Drive plug-in is not useful to anyone, we'll be glad to discontinue it. Less code to maintain. Less end-user support. -- XMLmind XML Editor Support List xmleditor-support@xmlmind.com http://www.xmlmind.com/mailman/listinfo/xmleditor-support
Re: [XXE] Bug: Date stille 'touched' when moving folders with Google Drive plug-in
On 4 Aug 2017, at 17:25, Hussein Shafie wrote: On 08/04/2017 03:19 PM, Leif Halvard Silli wrote: You said you fixed this last time I reported it. Definitely not the same issue. You reported an issue about renaming a folder on your Mac: http://www.mail-archive.com/xmleditor-support@xmlmind.com/msg11536.html This issue has indeed been solved. Sorry for mixing up! However, this seems not to be the case. Today I, for instance, 1. Chose a file in Google Drive via the interface of the XXE Google Drive plug-in 2. Chose 'Copy' file. 3. Pasted the file. Doing something this on my Linux box using the shell creates a copy of the file and this copy has a new date: the date of the creation of the copy, not the date of the original file. $ cp foo bar If I want to avoid this, I've to execute: $ cp -p foo bar Therefore this behavior can be considered to be normal. If we change it, other users may complain for the opposite reasons than yours. Since these commands, in XXE, are keyboard shortcurts, and since I am, by accident, a Mac user, I have different expectations: In the the MacOS Finder you can copy and paste files, via the normal shortcuts for that (same as copy and paste in an editing app). The resulting copy will be a duplicate, also with regard to metadata such a file creation date. 4. Opened the Web version of Google Drive and located the file I had pasted. 5. Checked the last change date of the file I had pasted. * Expected: Old date * Instead: THe last change date was set to the moment when I pasted the file. Unless this is a limitation of Google Drive, then this seems like a XXE bug. *Any* action performed on the Google Drive using XXE seems to modify the date of the accessed files. For example: opening a document without even modifying it. The lock added by XXE to the document changes the date of the file. This is certainly a problem, but we don't plan to improve this situation in the near future. Sorry for that. OK. The result, for me, is that, in order to do ”serious stuff” with files, I must use the Google Drive app. That’s OK. Except that I find the Google Drive app extremely slow at syncing thousands of small files. (And the kind of document production that is typically performed with DocBook and DITA tends to cause thousands of small (image) files to be created.) And that, in turn, means that I can just as well let XXE interface with the local Google Drive folder on my harddisk. And thus, since I need that app, the Google Drive plug in is not all that useful, even for working with Google Drive. And that - in turn - means that I have moved some XXE related projects to Dropbox and the Dropbox app. “Everyone” says that Dropbox is much faster for smaller files. And, after a few tests, I find that to indeed be the case ... Leif Halvard Silli -- XMLmind XML Editor Support List xmleditor-support@xmlmind.com http://www.xmlmind.com/mailman/listinfo/xmleditor-support
Re: [XXE] Bug: Date stille 'touched' when moving folders with Google Drive plug-in
On 08/04/2017 03:19 PM, Leif Halvard Silli wrote: You said you fixed this last time I reported it. Definitely not the same issue. You reported an issue about renaming a folder on your Mac: http://www.mail-archive.com/xmleditor-support@xmlmind.com/msg11536.html This issue has indeed been solved. However, this seems not to be the case. Today I, for instance, 1. Chose a file in Google Drive via the interface of the XXE Google Drive plug-in 2. Chose 'Copy' file. 3. Pasted the file. Doing something this on my Linux box using the shell creates a copy of the file and this copy has a new date: the date of the creation of the copy, not the date of the original file. $ cp foo bar If I want to avoid this, I've to execute: $ cp -p foo bar Therefore this behavior can be considered to be normal. If we change it, other users may complain for the opposite reasons than yours. 4. Opened the Web version of Google Drive and located the file I had pasted. 5. Checked the last change date of the file I had pasted. * Expected: Old date * Instead: THe last change date was set to the moment when I pasted the file. Unless this is a limitation of Google Drive, then this seems like a XXE bug. *Any* action performed on the Google Drive using XXE seems to modify the date of the accessed files. For example: opening a document without even modifying it. The lock added by XXE to the document changes the date of the file. This is certainly a problem, but we don't plan to improve this situation in the near future. Sorry for that. For now, it seems like I need to rely on other interfaces than XXE for moving files inside my Google drive. -- XMLmind XML Editor Support List xmleditor-support@xmlmind.com http://www.xmlmind.com/mailman/listinfo/xmleditor-support
