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 à 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 applie
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.
Than
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...
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 th
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
> "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>
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 time
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,
w
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
modif
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 s
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
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
> Mae
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 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 notifi
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
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, su
> "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)
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 hav
> "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: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
> "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
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 writt
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 certain
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://m
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
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 c
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
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 ne
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 monit
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 t
> "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: Qt
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 f
> "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 si
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?
Oth
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 fo
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 met
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
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, .fr
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 s
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 cons
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
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
45 matches
Mail list logo
