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
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
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...
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
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
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...
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
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.
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
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
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
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é
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
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
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
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
> "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>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
> "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
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
> "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
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
> "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>
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,
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
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
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'?
>
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
>
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
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
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
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,
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?
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
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
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 QtCore/QFileInfo leads me to the following error, despite I'm
Mael using qt4.3:
Mael GraphicsCacheItem.cpp:27:28: error:
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
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?
> "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
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
> "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:
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
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
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
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,
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:
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
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
> "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,
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
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
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
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
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
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
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
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
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
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
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
90 matches
Mail list logo
