aesthete-team team mailing list archive

[Phil Weir <phil.t.weir@xxxxxxxxxxxxxx>]

[Aargh, hit reply again - sent to list]

>> install_thirdparty.sh could be something as simple as
>> wget
>> http://alexgorbatchev.com/SyntaxHighlighter/download/download.php?sh_current
>>
> That sounds like the right approach. We would probably test for the presence
> or absence of each third_party package and download each absent one. So a
> bit more complicated than wget but not by much :)
 Agreed - the final of those attempts had a slightly longer (tested)
 example, but it still misses that functionality, which would be good!

>
>
>> Alternatively, I'm noticing that there is a hosted version at that
>> website, and since the presentation version only contains the
>> pre-rendered content, that may be sufficient? That would just require
>> the extra script links in the code, which would be redundant if
>> SyntaxHighlighter is present locally.
>>
> For most situations I think that would be okay. The only exception would be
> for times internet access was not available. It's probably best to have
> SyntaxHighlighter installed and use the hosted version as a backup.
>
 Indeed. MathJAX is working remotely, but there isn't much choice for
 it :s Incidentally, you can see it run if you type, say, "A fraction:
 $ \frac{a}{b} $" into a Lantern text widget (but not code!).

>> Regarding the GTK header file deps - as you pointed out previously,
>> they should be pulled in by pygtk-devel. Actually, this functionality
>> is the only remaining reason for GTK-2 dependencies to be in there,
>> but that's another story. For reference, my suggestion was, firstly,
>> checking the pkgconfig response when the Extension is being added in
>> setup.py to see whether the `pkg-config gtk+-2.0` call complained,
>> omitting the extension module if so and, secondly, to test for the
>> existence of '_aesthete_c' in the Lantern.py import (the only place it
>> is currently being imported) and prevent 'Lantern.get_paste' from
>> calling 'get_svg_from_clipboard' if so.
> P

>
> That last bit sounds complicated. I think I'd have to get my head around
> SWIG and the like first. So we don't strictly need to do this right now? It
> may be easier to check for pygtk-devel and if that isn't there then abort
> telling the user to install it, especially if we're going to git rid of GTK2
> eventually.
>
 Yep, sorry. I'll be talking about SWIG on Sunday - party-time :) True
 - for the RPM checking pygtk-devel should be sufficient. The
 difficulty may occur when the dependency moves from GTK-2 headers to
 GTK-3 but that's not happening this weekend (honestly!).
 P