Re: Converter problem with Mac OS packages
Le 8 juin 07 à 10:28, Mael Hilléreau a écrit : What is the status of this patch? What do you mean by "status" exactly? I don't know if it was tested by others than me. But to be integrated, it is clear that the code needs more testing, and then some #ifdefs in order to be applied only to Mac OS. Well, of course, we need to find a consensus on how updates should be done... At the end, will we use a timestamp alone or in conjunction with CRC? IMHO, the timestamp is sufficient and I didn't encounter inconsistencies while using the existing patch (in which the CRC isn't used for directories). In contrast, you (Andre and Jean-Marc) think a Timestap+CRC would be better. Andre said that some problems could arise when saving a file more than one time within a second. For my part, I think that this situation won't arise when dealing with external graphics. Perhaps you had a more general point of view and thought about other conversions such as in math previews, or anything else... But as I'm new to LyX sources, I don't know much about how the preview mechanism is led. I think we really need to clarify how an update should be triggered. We could start by describing the problem as follows: * Approach: Timestamp (i), Timestamp+CRC (ii) * Contents changed? Yes (1), no (2) * Timestamp changed? Yes (a), no (b) All possible situations are: * 1a: this case leads to an update in (i) and (ii). If we use (i) the test is cheaper; * 1b: this situation is inconsistent: the editor updated the contents but not the timestamp of the directory, or it updated the timestamp but didn't change it (less than 1 sec interval). If we use (i) this situation cannot be detected whereas it can if we use (ii); * 2a: this situation is inconsistent: the user updated the file without changing its contents. It cannot be reached if situation 1b can (excluding the 1 sec problem), and conversely. If we use (ii) the test is cheaper assuming that the conversion process is more expensive than the CRC; * 2b: no modification is made in both (i) and (ii). If we use (i), the test is cheaper. Recall: IMO 1a and 2b are the most frequently, 2a is rare and 1b never occurs when dealing with external graphics. That's why I would pitch on approach (i). The questions are mainly: should we consider that situation 1b can arise or not? And is it worthwhile to save time in 2a if we loose time in 1a and 2b? Could anyone give us more information/suggestions/ point of views about this? Finally, what kind of #ifdef should be used: Should we select Mac OS only, or should we create some variable for OSes providing graphics as directories (e.g. #ifdef HAVE_GRAPHICS_DIR)? Mael.
Re: Converter problem with Mac OS packages
Le 8 juin 07 à 11:08, José Matos a écrit : On Friday 08 June 2007 09:28:03 Mael Hilléreau wrote: What do you mean by "status" exactly? I don't know if it was tested by others than me. But to be integrated, it is clear that the code needs more testing, and then some #ifdefs in order to be applied only to Mac OS. Mael. Thanks for reporting the status of this patch. :-) You're welcome :) Mael.
Re: Converter problem with Mac OS packages
On Friday 08 June 2007 09:28:03 Mael Hilléreau wrote: > What do you mean by "status" exactly? I don't know if it was tested > by others than me. But to be integrated, it is clear that the code > needs more testing, and then some #ifdefs in order to be applied only > to Mac OS. > > Mael. Thanks for reporting the status of this patch. :-) -- José Abílio
Re: Converter problem with Mac OS packages
Le 7 juin 07 à 23:58, José Matos a écrit : On Tuesday 05 June 2007 21:32:05 Mael Hilléreau wrote: Le 5 juin 07 à 19:14, Andre Poenitz a écrit : Pleas send patches (also) to the mailing list unless they are exceptionally large. And please create 'unified diffs'. People here are used to them... Sorry about that, I updated the last patch (see attached file). Mael. What is the status of this patch? What do you mean by "status" exactly? I don't know if it was tested by others than me. But to be integrated, it is clear that the code needs more testing, and then some #ifdefs in order to be applied only to Mac OS. Mael.
Re: Converter problem with Mac OS packages
On Tuesday 05 June 2007 22:11:14 Jean-Marc Lasgouttes wrote: > > He is just trying to please his new boss :) > > JMarc As it can be seen here in the second photo taken in Berlin (first person standing in the left side): http://labs.trolltech.com/blogs/2007/05/30/qt-430-released/ -- José Abílio
Re: Converter problem with Mac OS packages
On Tuesday 05 June 2007 21:32:05 Mael Hilléreau wrote: > Le 5 juin 07 à 19:14, Andre Poenitz a écrit : > > Pleas send patches (also) to the mailing list unless they are > > exceptionally large. And please create 'unified diffs'. People > > here are used to them... > > Sorry about that, I updated the last patch (see attached file). > > Mael. What is the status of this patch? -- José Abílio
Re: Converter problem with Mac OS packages
Le 6 juin 07 à 08:03, Andre Poenitz a écrit : This was joking. Nevertheless, IMHO the timestamp is a good solution for almost 99,% of time. The remaining 0,0001% being outdated screens, unless you can compile/modif/save/recompile in less than 1 sec... (however, assuming that file formats are different for on screen preview and for output...) Anyway, we may agree that when dealing with graphics, the CRC should only be computed when timestamps are identical, do we? Not sure. Different timestamps and equal contents might be possible in which case it'd probably be not the worst solution to do nothing. It seems to me that you're thinking of situations which are really improbable... As I said above, one never opens a figure into its editor in order to save the file without changing it! If you don't think so, please could you give me an example? Mael.
Re: Converter problem with Mac OS packages
> "Mael" == Mael Hilléreau <[EMAIL PROTECTED]> writes: Mael> Le 6 juin 07 à 00:04, Jean-Marc Lasgouttes a écrit : >> The complexity depends on the total size of the data. A big file is >> worse than a small directory. Mael> Just a last word on this: the complexity doesn't depend on the Mael> total size of the data, it depends on the total amount of data Mael> processing, which may not be proportional. Yes. (Ha! I got the last word!) JMarc
Re: Converter problem with Mac OS packages
On Wed, Jun 06, 2007 at 01:01:30AM +0200, Mael Hilléreau wrote: > Le 6 juin 07 à 00:40, Andre Poenitz a écrit : > > >On Wed, Jun 06, 2007 at 12:37:31AM +0200, Mael Hilléreau wrote: > >>Le 6 juin 07 à 00:23, Andre Poenitz a écrit : > >> > It would make sense to compute checksum only if the timestamp is > different: it then saves the conversion process in the case no new > modifications exist (i.e. the file was saved but not modified). > >>> > >>>That assumes that changed files cannot have the same time stamp. > >>>Even if that might hold true in most cases > >>>POSIX guarantees only 1 sec resolution, FAT has 2 IIRC. > >>> > >>>One can have tons of changes in that time > >> > >>??? > >>I think you're incredibly productive if you can modify AND save a > >>graphic file more than one time per second! > > > >We are talking about automated conversion, aren't we? > > I thought we were talking about automated conversion arising after a > manual external file modification. But if not, could you explain > further? > > >!! But if we suppose that, > >>then you won't care to wait the next second for a screen update to > >>come up ;) > > > >Is it only screen update, or is it also correctness of conversion? > > This was joking. Nevertheless, IMHO the timestamp is a good solution > for almost 99,% of time. The remaining 0,0001% being outdated > screens, unless you can compile/modif/save/recompile in less than 1 > sec... (however, assuming that file formats are different for on > screen preview and for output...) > > Anyway, we may agree that when dealing with graphics, the CRC should > only be computed when timestamps are identical, do we? Not sure. Different timestamps and equal contents might be possible in which case it'd probably be not the worst solution to do nothing. Andre'
Re: Converter problem with Mac OS packages
Le 6 juin 07 à 00:04, Jean-Marc Lasgouttes a écrit : The complexity depends on the total size of the data. A big file is worse than a small directory. Just a last word on this: the complexity doesn't depend on the total size of the data, it depends on the total amount of data processing, which may not be proportional. Mael.
Re: Converter problem with Mac OS packages
Le 6 juin 07 à 00:40, Andre Poenitz a écrit : On Wed, Jun 06, 2007 at 12:37:31AM +0200, Mael Hilléreau wrote: Le 6 juin 07 à 00:23, Andre Poenitz a écrit : It would make sense to compute checksum only if the timestamp is different: it then saves the conversion process in the case no new modifications exist (i.e. the file was saved but not modified). That assumes that changed files cannot have the same time stamp. Even if that might hold true in most cases POSIX guarantees only 1 sec resolution, FAT has 2 IIRC. One can have tons of changes in that time ??? I think you're incredibly productive if you can modify AND save a graphic file more than one time per second! We are talking about automated conversion, aren't we? I thought we were talking about automated conversion arising after a manual external file modification. But if not, could you explain further? !! But if we suppose that, then you won't care to wait the next second for a screen update to come up ;) Is it only screen update, or is it also correctness of conversion? This was joking. Nevertheless, IMHO the timestamp is a good solution for almost 99,% of time. The remaining 0,0001% being outdated screens, unless you can compile/modif/save/recompile in less than 1 sec... (however, assuming that file formats are different for on screen preview and for output...) Anyway, we may agree that when dealing with graphics, the CRC should only be computed when timestamps are identical, do we? Mael.
Re: Converter problem with Mac OS packages
On Wed, Jun 06, 2007 at 12:37:31AM +0200, Mael Hilléreau wrote: > Le 6 juin 07 à 00:23, Andre Poenitz a écrit : > > >>It would make sense to compute checksum only if the timestamp is > >>different: it then saves the conversion process in the case no new > >>modifications exist (i.e. the file was saved but not modified). > > > >That assumes that changed files cannot have the same time stamp. > >Even if that might hold true in most cases > >POSIX guarantees only 1 sec resolution, FAT has 2 IIRC. > > > >One can have tons of changes in that time > > ??? > I think you're incredibly productive if you can modify AND save a > graphic file more than one time per second! We are talking about automated conversion, aren't we? !! But if we suppose that, > then you won't care to wait the next second for a screen update to > come up ;) Is it only screen update, or is it also correctness of conversion? Andre'
Re: Converter problem with Mac OS packages
Le 6 juin 07 à 00:23, Andre Poenitz a écrit : It would make sense to compute checksum only if the timestamp is different: it then saves the conversion process in the case no new modifications exist (i.e. the file was saved but not modified). That assumes that changed files cannot have the same time stamp. Even if that might hold true in most cases POSIX guarantees only 1 sec resolution, FAT has 2 IIRC. One can have tons of changes in that time ??? I think you're incredibly productive if you can modify AND save a graphic file more than one time per second!!! But if we suppose that, then you won't care to wait the next second for a screen update to come up ;) Mael.
Re: Converter problem with Mac OS packages
On Wed, Jun 06, 2007 at 12:04:35AM +0200, Jean-Marc Lasgouttes wrote: > > "Mael" == Mael Hilléreau <[EMAIL PROTECTED]> writes: > > >> I am not sure we have evidence that the checksum is costing us too > >> much. > > Mael> Perhaps true for regular files (O(n) complexity), but not really > Mael> for packages(O(n^2) complexity, supposing that there are no > Mael> subdirectories)... > > The complexity depends on the total size of the data. A big file is > worse than a small directory. Not necessarily true. Reading large files is fairly cheap on Windows, reading lots of small files is not, even if the small files comprise one a fraction of the total size of the big size. > Mael> But the first question to answer is: do we need it?? > > I think we do, but I do not remember whiy it is better than our old > time-base version. One advantage is that you detect when a file has > been updated without change: typical of the .aux file written by LaTeX. > > Mael> Further, if we need it for files, do we need it for directories? > > Yes if we want directories to masquerade as files. > > It should be possible to feed in order all the bytes of all the files > in the directory to the crc checker. If we have a proper directory > iterator in boost, it should be fairly easy. It would btw be sufficient not to crc all the files in a directory but only the _checksums_ of the files contained in the directory. Andre'
Re: Converter problem with Mac OS packages
On Tue, Jun 05, 2007 at 11:28:53PM +0200, Jean-Marc Lasgouttes wrote: > > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: > > Andre> Can anybody remind me why we use checksums and not modification > Andre> or access times? Was that the '2 seconds granularity on FAT > Andre> problem'? > > I am not sure we have evidence that the checksum is costing us too > much. Good point. Andre'
Re: Converter problem with Mac OS packages
On Tue, Jun 05, 2007 at 11:17:39PM +0200, Mael Hilléreau wrote: > Le 5 juin 07 à 23:06, Andre Poenitz a écrit : > > >>In the long run this certainly would make sense since our homegrown > >>solution is pretty expensive (checksum of the whole file) compared > >>to the Qt solution (use system notifications when available, polling > >>only as fallback). > > > >Can anybody remind me why we use checksums and not modification or > >access times? Was that the '2 seconds granularity on FAT problem'? > > It would make sense to compute checksum only if the timestamp is > different: it then saves the conversion process in the case no new > modifications exist (i.e. the file was saved but not modified). That assumes that changed files cannot have the same time stamp. Even if that might hold true in most cases POSIX guarantees only 1 sec resolution, FAT has 2 IIRC. One can have tons of changes in that time But I am not sure this actually was the reason we went for checksums... Andre'
Re: Converter problem with Mac OS packages
On Tue, Jun 05, 2007 at 11:11:14PM +0200, Jean-Marc Lasgouttes wrote: > > "Mael" == Mael Hilléreau <[EMAIL PROTECTED]> writes: > > Mael> Le 5 juin 07 à 19:01, Andre Poenitz a écrit : > >> We should use QFileSystemWatcher instead of reinventing the wheel. > > Mael> FileMonitor class is already written. Do you mean it should it > Mael> be removed?? > > He is just trying to please his new boss :) I try to hide my spare time activities from him. Apart from that I think I changed my stance regarding Qt usage in LyX a while (two years or so I'd think...) Andre'
Re: Converter problem with Mac OS packages
Le 6 juin 07 à 00:04, Jean-Marc Lasgouttes a écrit : "Mael" == Mael Hilléreau <[EMAIL PROTECTED]> writes: I am not sure we have evidence that the checksum is costing us too much. Mael> Perhaps true for regular files (O(n) complexity), but not really Mael> for packages(O(n^2) complexity, supposing that there are no Mael> subdirectories)... The complexity depends on the total size of the data. A big file is worse than a small directory. Of course, but this is not the general case. Also note that this operation is performed once a second, approximatively. Mael> But the first question to answer is: do we need it?? I think we do, but I do not remember whiy it is better than our old time-base version. One advantage is that you detect when a file has been updated without change: typical of the .aux file written by LaTeX. I can trust you but... concerning graphics, identifying this case isn't really useful: we could just convert each time a modification arises, which should be detected using the timestamp. In fact, it is very rare to open a figure into its editor in order to save the file without changing it! Mael> Further, if we need it for files, do we need it for directories? Yes if we want directories to masquerade as files. Indeed, this seems logic... It should be possible to feed in order all the bytes of all the files in the directory to the crc checker. If we have a proper directory iterator in boost, it should be fairly easy. This looks like making a tar file, and then computing its CRC. Mael.
Re: Converter problem with Mac OS packages
> "Mael" == Mael Hilléreau <[EMAIL PROTECTED]> writes: >> I am not sure we have evidence that the checksum is costing us too >> much. Mael> Perhaps true for regular files (O(n) complexity), but not really Mael> for packages(O(n^2) complexity, supposing that there are no Mael> subdirectories)... The complexity depends on the total size of the data. A big file is worse than a small directory. Mael> But the first question to answer is: do we need it?? I think we do, but I do not remember whiy it is better than our old time-base version. One advantage is that you detect when a file has been updated without change: typical of the .aux file written by LaTeX. Mael> Further, if we need it for files, do we need it for directories? Yes if we want directories to masquerade as files. It should be possible to feed in order all the bytes of all the files in the directory to the crc checker. If we have a proper directory iterator in boost, it should be fairly easy. JMarc
Re: Converter problem with Mac OS packages
Le 5 juin 07 à 23:28, Jean-Marc Lasgouttes a écrit : "Andre" == Andre Poenitz <[EMAIL PROTECTED] chemnitz.de> writes: Andre> Can anybody remind me why we use checksums and not modification Andre> or access times? Was that the '2 seconds granularity on FAT Andre> problem'? I am not sure we have evidence that the checksum is costing us too much. Perhaps true for regular files (O(n) complexity), but not really for packages(O(n^2) complexity, supposing that there are no subdirectories)... But the first question to answer is: do we need it?? Further, if we need it for files, do we need it for directories? Mael.
Re: Converter problem with Mac OS packages
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> Can anybody remind me why we use checksums and not modification Andre> or access times? Was that the '2 seconds granularity on FAT Andre> problem'? I am not sure we have evidence that the checksum is costing us too much. JMarc
Re: Converter problem with Mac OS packages
Le 5 juin 07 à 23:06, Andre Poenitz a écrit : In the long run this certainly would make sense since our homegrown solution is pretty expensive (checksum of the whole file) compared to the Qt solution (use system notifications when available, polling only as fallback). Can anybody remind me why we use checksums and not modification or access times? Was that the '2 seconds granularity on FAT problem'? It would make sense to compute checksum only if the timestamp is different: it then saves the conversion process in the case no new modifications exist (i.e. the file was saved but not modified). Mael. -- Mael Hilléreau http://mael.hillereau.free.fr
Re: Converter problem with Mac OS packages
> "Mael" == Mael Hilléreau <[EMAIL PROTECTED]> writes: Mael> Le 5 juin 07 à 19:01, Andre Poenitz a écrit : >> We should use QFileSystemWatcher instead of reinventing the wheel. Mael> FileMonitor class is already written. Do you mean it should it Mael> be removed?? He is just trying to please his new boss :) JMarc
Re: Converter problem with Mac OS packages
On Tue, Jun 05, 2007 at 11:04:22PM +0200, Andre Poenitz wrote: > On Tue, Jun 05, 2007 at 10:23:26PM +0200, Mael Hilléreau wrote: > > Le 5 juin 07 à 19:01, Andre Poenitz a écrit : > > > > >We should use QFileSystemWatcher instead of reinventing the wheel. > > > > FileMonitor class is already written. Do you mean it should it be > > removed?? > > In the long run this certainly would make sense since our homegrown > solution is pretty expensive (checksum of the whole file) compared > to the Qt solution (use system notifications when available, polling > only as fallback). Can anybody remind me why we use checksums and not modification or access times? Was that the '2 seconds granularity on FAT problem'? Andre'
Re: Converter problem with Mac OS packages
On Tue, Jun 05, 2007 at 10:23:26PM +0200, Mael Hilléreau wrote: > Le 5 juin 07 à 19:01, Andre Poenitz a écrit : > > >We should use QFileSystemWatcher instead of reinventing the wheel. > > FileMonitor class is already written. Do you mean it should it be > removed?? In the long run this certainly would make sense since our homegrown solution is pretty expensive (checksum of the whole file) compared to the Qt solution (use system notifications when available, polling only as fallback). This assumes that QFileSystemWatcher does what we need, which I do not know. Andre'
Re: Converter problem with Mac OS packages
Le 5 juin 07 à 19:14, Andre Poenitz a écrit : Pleas send patches (also) to the mailing list unless they are exceptionally large. And please create 'unified diffs'. People here are used to them... Sorry about that, I updated the last patch (see attached file). Mael. -- Mael Hilléreau http://mael.hillereau.free.fr graphics-as-macos-packages3.patch Description: Binary data
Re: Converter problem with Mac OS packages
Le 5 juin 07 à 19:01, Andre Poenitz a écrit : We should use QFileSystemWatcher instead of reinventing the wheel. FileMonitor class is already written. Do you mean it should it be removed?? Mael. -- Mael Hilléreau http://mael.hillereau.free.fr
Re: Converter problem with Mac OS packages
On Tue, Jun 05, 2007 at 11:32:28AM +0200, Mael Hilléreau wrote: > Le 5 juin 07 à 11:05, Mael Hilléreau a écrit : > > >Le 4 juin 07 à 10:00, Jean-Marc Lasgouttes a écrit : > > > >>The more I think about it, the more I think that adapting the crc > >>computation to directories is the way to go. It could be useful on > >>other OSes to accept directories as file names. > > > >I made a new patch in which directories (graphics) are monitored, > >but only through the timestamp (this solution works for omnigraffle > >packages since the directory is "touched" by the software each time > >a figure is saved). I have two questions. > > I forgot, of course it is available at bugzilla: http:// > bugzilla.lyx.org/show_bug.cgi?id=3768 Pleas send patches (also) to the mailing list unless they are exceptionally large. And please create 'unified diffs'. People here are used to them... Andre'
Re: Converter problem with Mac OS packages
On Tue, Jun 05, 2007 at 11:05:19AM +0200, Mael Hilléreau wrote: > Le 4 juin 07 à 10:00, Jean-Marc Lasgouttes a écrit : > > >The more I think about it, the more I think that adapting the crc > >computation to directories is the way to go. It could be useful on > >other OSes to accept directories as file names. > > I made a new patch in which directories (graphics) are monitored, but > only through the timestamp (this solution works for omnigraffle > packages since the directory is "touched" by the software each time a > figure is saved). I have two questions. > > Firstly, could you explain why do you think it's needed to add a CRC > computation to this checking? > > Secondly, how do you imagine a CRC algorithm for directories? I can > see two different possibilities: > > * Compute CRC for all included files (and subdirectories??), and then > mix them? Then how to mix? > > * Tar or zip the package and then compute CRC for the resulting file? > > Don't you think it would be somewhat heavy when dealing with big > directories (including many files)? (monitoring implies one operation > per second, approximatively) > > I'm waiting for your comments. We should use QFileSystemWatcher instead of reinventing the wheel. Andre'
Re: Converter problem with Mac OS packages
Le 5 juin 07 à 11:05, Mael Hilléreau a écrit : Le 4 juin 07 à 10:00, Jean-Marc Lasgouttes a écrit : The more I think about it, the more I think that adapting the crc computation to directories is the way to go. It could be useful on other OSes to accept directories as file names. I made a new patch in which directories (graphics) are monitored, but only through the timestamp (this solution works for omnigraffle packages since the directory is "touched" by the software each time a figure is saved). I have two questions. I forgot, of course it is available at bugzilla: http:// bugzilla.lyx.org/show_bug.cgi?id=3768 Mael. -- Mael Hilléreau http://mael.hillereau.free.fr
Re: Converter problem with Mac OS packages
Le 4 juin 07 à 10:00, Jean-Marc Lasgouttes a écrit : The more I think about it, the more I think that adapting the crc computation to directories is the way to go. It could be useful on other OSes to accept directories as file names. I made a new patch in which directories (graphics) are monitored, but only through the timestamp (this solution works for omnigraffle packages since the directory is "touched" by the software each time a figure is saved). I have two questions. Firstly, could you explain why do you think it's needed to add a CRC computation to this checking? Secondly, how do you imagine a CRC algorithm for directories? I can see two different possibilities: * Compute CRC for all included files (and subdirectories??), and then mix them? Then how to mix? * Tar or zip the package and then compute CRC for the resulting file? Don't you think it would be somewhat heavy when dealing with big directories (including many files)? (monitoring implies one operation per second, approximatively) I'm waiting for your comments. Mael. -- Mael Hilléreau http://mael.hillereau.free.fr
Re: Converter problem with Mac OS packages
Le 4 juin 07 à 10:00, Jean-Marc Lasgouttes a écrit : It is because only the files in frontend/qt4 and support/ have access to the qt files. We try hard to keep a separation between the core code and the gui toolkit. The more I think about it, the more I think that adapting the crc computation to directories is the way to go. It could be useful on other OSes to accept directories as file names. In fact, this would have been necessary anyway (for updating only when required)... So if I understand, we should keep the test as dealing with directories that have an extension? Mael. -- Mael Hilléreau http://mael.hillereau.free.fr
Re: Converter problem with Mac OS packages
> "Mael" == Mael Hilléreau <[EMAIL PROTECTED]> writes: Mael> I switched to 1.5.0rc1 and tried using QFileInfo::isBundle(), Mael> but the header isn't found by make: The #include Mael> leads me to the following error, despite I'm Mael> using qt4.3: Mael> GraphicsCacheItem.cpp:27:28: error: QtCore/QFileInfo: No such Mael> file or directory Mael> I don't understand this error since it doesn't arise when I Mael> compile whithout the #include directive... It is because only the files in frontend/qt4 and support/ have access to the qt files. We try hard to keep a separation between the core code and the gui toolkit. The more I think about it, the more I think that adapting the crc computation to directories is the way to go. It could be useful on other OSes to accept directories as file names. JMarc
Re: Converter problem with Mac OS packages
Le 4 juin 07 à 09:42, Jean-Marc Lasgouttes a écrit : Mael> Surely. But I don't really know how to manage this since I'm not Mael> a Mac developer. What headers do we need to #include? With qt 4.3 (which we may assume for lyx/mac), QFileInfo::isBundle returns this information. The problem is to find a way to convey this information in a platform independent way. I switched to 1.5.0rc1 and tried using QFileInfo::isBundle(), but the header isn't found by make: The #include leads me to the following error, despite I'm using qt4.3: GraphicsCacheItem.cpp:27:28: error: QtCore/QFileInfo: No such file or directory I don't understand this error since it doesn't arise when I compile whithout the #include directive... Mael. -- Mael Hilléreau http://mael.hillereau.free.fr
Re: Converter problem with Mac OS packages
> "Mael" == Mael Hilléreau <[EMAIL PROTECTED]> writes: Mael> Le 29 mai 07 à 12:17, Jean-Marc Lasgouttes a écrit : >> I think it would be better to real OSX code to determine whether a >> directory is a bundle (maybe CFBundleCreate?). Mael> Surely. But I don't really know how to manage this since I'm not Mael> a Mac developer. What headers do we need to #include? With qt 4.3 (which we may assume for lyx/mac), QFileInfo::isBundle returns this information. The problem is to find a way to convey this information in a platform independent way. >> Otherwise, there would be the solution to always accept a directory >> as a file (and use a isReadable instead of isFileReadable), but >> then CRC should be computed by iterating on the files inside the >> directory. Mael> Yes and at this point, more code needs to be written. Yes. JMarc
Re: Converter problem with Mac OS packages
Le 29 mai 07 à 12:17, Jean-Marc Lasgouttes a écrit : I think it would be better to real OSX code to determine whether a directory is a bundle (maybe CFBundleCreate?). Surely. But I don't really know how to manage this since I'm not a Mac developer. What headers do we need to #include? Otherwise, there would be the solution to always accept a directory as a file (and use a isReadable instead of isFileReadable), but then CRC should be computed by iterating on the files inside the directory. Yes and at this point, more code needs to be written. Could you open a bug about this problem? Done: http://bugzilla.lyx.org/show_bug.cgi?id=3768 Mael. -- Mael Hilléreau http://mael.hillereau.free.fr
Re: Converter problem with Mac OS packages
Andre Poenitz wrote: On Tue, May 29, 2007 at 12:17:04PM +0200, Jean-Marc Lasgouttes wrote: "Mael" == Mael Hilléreau <[EMAIL PROTECTED]> writes: Mael> Le 27 mai 07 à 00:55, Mael Hilléreau a écrit : According to Apple's "Bundle Programming Guide", The Finder identifies packages by any of the following mechanisms: * The directory has a known extension: .app, .bundle, .framework, .plugin, .kext, and so on. * The directory has its bundle bit set. * The directory has a known structure type indicating it is a modern or versioned bundle. As a conclusion, as it is really not easy to distinguish between folders, applications, ..., and packages corresponding to graphics (such as '.graffle' files), I would suggest to replace the function call by a different one, and to consider folders having an extension to be valid files (only for Mac OS of course...). In the case the chosen package isn't supported (i.e. it is a folder or anything else but supported graphics), LyX won't crash because the file format won't be recognized. I think it would be better to real OSX code to determine whether a directory is a bundle (maybe CFBundleCreate?). QFileInfo::isBundle(). Unfortunately only since 4.3, i.e. today or so ;-} It was decided that the Mac port will ship with Qt4.3 IIRC. So a solution with an #ifdef is OK. Abdel.
Re: Converter problem with Mac OS packages
Le 29 mai 07 à 20:37, Andre Poenitz a écrit : I think it would be better to real OSX code to determine whether a directory is a bundle (maybe CFBundleCreate?). QFileInfo::isBundle(). Unfortunately only since 4.3, i.e. today or so ;-} Ok, so we must switch to 1.5.0b3 in order to use this method? Mael. -- Mael Hilléreau http://mael.hillereau.free.fr
Re: Converter problem with Mac OS packages
Le 29 mai 07 à 12:17, Jean-Marc Lasgouttes a écrit : I think it would be better to real OSX code to determine whether a directory is a bundle (maybe CFBundleCreate?). Surely. But I don't really know how to manage this since I'm really not familiar with Mac OS programming. What headers do we need to #include? Otherwise, there would be the solution to always accept a directory as a file (and use a isReadable instead of isFileReadable), but then CRC should be computed by iterating on the files inside the directory. Yes and at this point, more code needs to be written. Could you open a bug about this problem? Done: http://bugzilla.lyx.org/show_bug.cgi?id=3768 Mael. -- Mael Hilléreau http://mael.hillereau.free.fr
Re: Converter problem with Mac OS packages
On Tue, May 29, 2007 at 12:17:04PM +0200, Jean-Marc Lasgouttes wrote: > > "Mael" == Mael Hilléreau <[EMAIL PROTECTED]> writes: > > Mael> Le 27 mai 07 à 00:55, Mael Hilléreau a écrit : > >> According to Apple's "Bundle Programming Guide", > >> > >> The Finder identifies packages by any of the following mechanisms: > >> * The directory has a known extension: .app, .bundle, .framework, > >> .plugin, .kext, and so on. * The directory has its bundle bit set. > >> * The directory has a known structure type indicating it is a > >> modern or versioned bundle. > >> > >> As a conclusion, as it is really not easy to distinguish between > >> folders, applications, ..., and packages corresponding to graphics > >> (such as '.graffle' files), I would suggest to replace the function > >> call by a different one, and to consider folders having an > >> extension to be valid files (only for Mac OS of course...). In the > >> case the chosen package isn't supported (i.e. it is a folder or > >> anything else but supported graphics), LyX won't crash because the > >> file format won't be recognized. > > I think it would be better to real OSX code to determine whether a > directory is a bundle (maybe CFBundleCreate?). QFileInfo::isBundle(). Unfortunately only since 4.3, i.e. today or so ;-} Andre'
Re: Converter problem with Mac OS packages
> "Mael" == Mael Hilléreau <[EMAIL PROTECTED]> writes: Mael> Le 27 mai 07 à 00:55, Mael Hilléreau a écrit : >> According to Apple's "Bundle Programming Guide", >> >> The Finder identifies packages by any of the following mechanisms: >> * The directory has a known extension: .app, .bundle, .framework, >> .plugin, .kext, and so on. * The directory has its bundle bit set. >> * The directory has a known structure type indicating it is a >> modern or versioned bundle. >> >> As a conclusion, as it is really not easy to distinguish between >> folders, applications, ..., and packages corresponding to graphics >> (such as '.graffle' files), I would suggest to replace the function >> call by a different one, and to consider folders having an >> extension to be valid files (only for Mac OS of course...). In the >> case the chosen package isn't supported (i.e. it is a folder or >> anything else but supported graphics), LyX won't crash because the >> file format won't be recognized. I think it would be better to real OSX code to determine whether a directory is a bundle (maybe CFBundleCreate?). Otherwise, there would be the solution to always accept a directory as a file (and use a isReadable instead of isFileReadable), but then CRC should be computed by iterating on the files inside the directory. Could you open a bug about this problem? JMarc
Re: Converter problem with Mac OS packages
Le 27 mai 07 à 00:55, Mael Hilléreau a écrit :
According to Apple's "Bundle Programming Guide",
The Finder identifies packages by any of the following mechanisms:
* The directory has a known
extension: .app, .bundle, .framework, .plugin, .kext, and so on.
* The directory has its bundle bit set.
* The directory has a known structure type indicating it is a
modern or versioned bundle.
As a conclusion, as it is really not easy to distinguish between
folders, applications, ..., and packages corresponding to graphics
(such as '.graffle' files), I would suggest to replace the function
call by a different one, and to consider folders having an
extension to be valid files (only for Mac OS of course...). In the
case the chosen package isn't supported (i.e. it is a folder or
anything else but supported graphics), LyX won't crash because the
file format won't be recognized.
I think (not tested) that replacing the line 381 (in
GraphicsCacheItem.C) with the following should do the job:
if (!(fs::exists(filename_) && (!fs::is_directory(filename_) ||
fs::extension(filename_) != "") && fs::is_readable(filename_))) {
... assuming that 'fs' is known (namespace fs = boost::filesystem;)
I made a patch which enables inserting Mac OS packages (i.e. folders)
as graphics (see attached file). It works with '.graffle' packages
only if you add a copier for OmniGraffle: rm -fr $$o; cp -R $$i $$o
There's a remaining problem when one edits the file: the graphic is
neither updated in lyx window (until lyx is restarted...) nor in the
resulting PDF (until the rest of the document is modified, e.g. some
text).
Please, tell me what you think of this.
I'm still waiting for comments...
Mael.
--
Mael Hilléreau
http://mael.hillereau.free.fr
graphics-as-macos-packages.patch
Description: Binary data
Re: Converter problem with Mac OS packages
Le 26 mai 07 à 22:11, Mael Hilléreau a écrit :
I found in the source (LyX 1.4.4) the function call (file
converter.C, line 313):
bool Converters::convert(Buffer const * buffer,
string const & from_file, string const & to_file_base,
string const & from_format, string const & to_format,
string & to_file, bool try_default)
{
...
if (IsFileReadable(to_file)) {
return true;
...
}
Sorry, I made a mistake in previous message, the right function call
is here (file GraphicsCacheItem.C, line 380):
...
// First, check that the file exists!
if (!IsFileReadable(filename_)) {
if (status_ != ErrorNoFile) {
setStatus(ErrorNoFile);
lyxerr[Debug::GRAPHICS]
<< "\tThe file is not readable" << endl;
}
return;
}
...
Indeed, this function is defined as (fileTools.c, line 159):
// Is a file readable ?
bool IsFileReadable(string const & path)
{
return fs::exists(path) && !fs::is_directory(path) &&
fs::is_readable(path);
}
A short (and bad) fix would be to remove the "!fs::is_directory
(path)" clause for the Mac OS version. But there's surely a way to
check only for directories corresponding to packages. As I don't
know Mac OS programming, does anybody have a clue?
According to Apple's "Bundle Programming Guide",
The Finder identifies packages by any of the following mechanisms:
* The directory has a known
extension: .app, .bundle, .framework, .plugin, .kext, and so on.
* The directory has its bundle bit set.
* The directory has a known structure type indicating it is a modern
or versioned bundle.
As a conclusion, as it is really not easy to distinguish between
folders, applications, ..., and packages corresponding to graphics
(such as '.graffle' files), I would suggest to replace the function
call by a different one, and to consider folders having an extension
to be valid files (only for Mac OS of course...). In the case the
chosen package isn't supported (i.e. it is a folder or anything else
but supported graphics), LyX won't crash because the file format
won't be recognized.
I think (not tested) that replacing the line 381 (in
GraphicsCacheItem.C) with the following should do the job:
if (!(fs::exists(filename_) && (!fs::is_directory(filename_) ||
fs::extension(filename_) != "") && fs::is_readable(filename_))) {
... assuming that 'fs' is known (namespace fs = boost::filesystem;)
Please, tell me what you think of this.
Mael.
--
Mael Hilléreau
http://mael.hillereau.free.fr
Re: Converter problem with Mac OS packages
Le 26 mai 07 à 18:31, Mael Hilléreau a écrit :
Would it be possible to enable the MacOS version of LyX to work
with graphics stored as MacOS packages? I mean would it be possible
to replace the kind of "test -f $$i" by a kind of "test -r $$i" in
order to check for folders too?
I found in the source (LyX 1.4.4) the function call (file
converter.C, line 313):
bool Converters::convert(Buffer const * buffer,
string const & from_file, string const & to_file_base,
string const & from_format, string const & to_format,
string & to_file, bool try_default)
{
...
if (IsFileReadable(to_file)) {
return true;
...
}
Indeed, this function is defined as (fileTools.c, line 159):
// Is a file readable ?
bool IsFileReadable(string const & path)
{
return fs::exists(path) && !fs::is_directory(path) && fs::is_readable
(path);
}
A short (and bad) fix would be to remove the "!fs::is_directory
(path)" clause for the Mac OS version. But there's surely a way to
check only for directories corresponding to packages. As I don't know
Mac OS programming, does anybody have a clue?
Mael.
--
Mael Hilléreau
http://mael.hillereau.free.fr
Converter problem with Mac OS packages
Hi developers,
I wrote an applescript to enable converters for OmniGraffle graphics
format (see "A shell for launching figure editor under Mac OS" thread
in lyx-users list, or the LyX Mac wiki). However, I found that LyX
doesn't support graphics if they are stored as Mac OS X packages. Mac
OS X packages are unix folders disguised to look like single files.
When LyX converts graphics, a test for checking that the input file
exists is performed (perhaps something like a "test -f $$i" but in C
language...). The problem is that when this file is a Mac OS package
(which is the case of '.graffle' figures only if they include images;
see example below), it is actually a unix folder, and thus isn't
recognized as a file! This results in a "File not found" error
message, and no converter call. However, the file may really exist as
a folder (a package).
Would it be possible to enable the MacOS version of LyX to work with
graphics stored as MacOS packages? I mean would it be possible to
replace the kind of "test -f $$i" by a kind of "test -r $$i" in order
to check for folders too?
Note that this problem may occur with other programs that Omnigraffle.
An example is available here: http://mael.hillereau.free.fr/public/
Test.zip. It's a lyx document with two graphics inserted
('test1.graffle' including an image and so being a package, and
'test2.graffle' not including images and thus being a regular file).
You'll need to setup the 'og-export' applescript I wrote (available
in the LyX wiki : http://wiki.lyx.org/Mac/Mac) as well as Omnigraffle
(an evaluation version is downloadable on the omnigroup site) in
order to compile the lyx document.
Mael.
--
Mael Hilléreau
http://mael.hillereau.free.fr
