On Apr 21, 2011, at 0:26, Ivo Geradts wrote:
> Thanks a lot Christiaan for your quick reply.
>
>> On AFP volumes we cannot use filesystem notifications to get notified about
>> this, so we just check the mod date every 2 sec. So it will be noted any
>> time between immediate and 2 secs. There is a Revert menu action, but that
>> may not always be active, because we first need to know whether there's
>> something to revert, there's no way we can change that.
> The strange thing is that sometimes a reload may actually take over 5 sec
> after the TeX run has finished; it turns out that the reload behaviour can be
> quite unpredictable. Therefore, I suggested that the user may benefit from
> the option to do the reload manually. Unfortunately, my 'Revert' menu is
> still greyed out after a TeX run, when the preference 'Check for file
> changes' is off. It would be nice to be able to access this menu permanently,
> also when Skim is not looking at modification dates.
>
We cannot, and this has been discussed, to death.
>> Also reloading on activating is not an option, because that would lead to
>> many unnecessary reloads. You should realize that reload feature is buggy by
>> design, simply because it is impossible to do 100% correct, and we would
>> rather not have it at all.
> I would not mind the unnecessary reloads as Skim does them very fast. I agree
> that this approach is not very elegant, but in my situation (working on a
> remote home directory served by AFP) this would be more effective than
> waiting for the reload to kick in automatically after an unpredictable number
> of seconds.
>
You're not the only user, so that's irrelevant.
>> The best way, and the only correct way, to reload the file is to have it
>> done yourself using a script that combines the tex process and the revert.
> I see. The problem with this is is that in our situation TeX is running on
> the server and Skim is running on clients, so it is not easy to make these
> two processes communicate. Further, as I mentioned above, the 'Revert' is
> currently not available.
>
>>> (2) Another thing is that PDF-TeX Sync support (using synctex), which is
>>> working great in OS X, is broken in OS X Server. Is there a way to debug
>>> the synctex behaviour in OS X Server? I would be glad if I could be of any
>>> help to fix this issue.
>>
>> Here we don't really use any file system stuff, except the file mod date. So
>> I would not know why that should not be working. Are you putting the output
>> files in a different directory, i.e. is your synctex file in a different
>> directory from the pdf file? That is possible, but not supported.
> The TeX file and the resulting pdf are located in the same directory. Exactly
> the same pdf is syncing nicely to the TeX file on a client running OS X, but
> it refuses to do so on the server running OS X Server. Does Skim write errors
> to a log file, which I can look into?
>
> Thanks again! Best, Ivo.
There are some logs written in Console.app.
Christiaan
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Skim-app-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/skim-app-users
