[PyKDE] PyQt4 installation issue

[Detlev Offenbach]

On Sunday 15 October 2006 12:16, Phil Thompson wrote:
> On Sunday 15 October 2006 9:36 am, Detlev Offenbach wrote:
> > On Saturday 14 October 2006 20:24, Phil Thompson wrote:
> > > On Saturday 14 October 2006 6:17 pm, Detlev Offenbach wrote:
> > > > Hi,
> > > >
> > > > the latest snapshot of PyQt4 creates an API file for QScintilla.
> > > > However, this file is not installed by "make install". For Linux I
> > > > propose to put it in "/usr/share/QScintilla". Furthermore, the
> > > > configure script should get an option to specify the installation
> > > > path for the API file.
> > > >
> > > > -a dir  where the PyQt4 .api file will be installed
> > > > [default /usr/share/QScintilla]
> > >
> > > I haven't decided yet how this should be handled. For example I might
> > > create a Scintilla subdirectory in $QTDIR with lexer specific
> > > subdirectories in that - and maybe autoload any API files found there.
> >
> > Please no automatism. Give the user the chance to decide, if he wants to
> > have autocompletion and calltips. If decides against it, it is not
> > neccessary to load the API files. If you introduce a global API storage
> > area, you must include provisions for a per user API storage area as
> > well.
> >
> > > Or
> > > maybe have an configurable API path that is searched.
> >
> > One per lexer type?
> >
> >
> > What should happen, if a user just wants to load a subset of the API
> > files available for a specific lexer (e.g. for Python there might be a
> > python.api and PyQt4.api; the user just wants to use the later one). With
> > the current API solution, it is the responsibility of the application to
> > provide these services to the user. Eric4 (and eric3) do this.
> > QScintilla2 is a widget meant to be integrated into an application and
> > should provide the programmer an API to access the service needed. I
> > think, the current QScintilla2 API is good in this respect.
>
> Agreed that QScintilla should not mandate any policy. Also, the producer of
> any API file (eg, PyQt, PyKDE) should be decoupled from any consumer (eg
> eric, another QScintilla based editor).
>
> How about, when loading an API file, if the file is not found and no
> directory path was included in the name, then it looks for a file in a
> standard location. 

Ok, how about a configurable API search path. This could be configurable via 
an environment variable (e.g. QSCINTILLA_API_PATH) and overridable via an API 
call (e.g. setApiSearchPath(QStringList searchPath)) accompanied by the 
relevant getter method.

> There should also be a lexer method that returns the 
> names of the files (excluding the .api extension) of all the files in the
> lexer specific standard directory.

As mentioned before, if there is a global standard directory, there should be 
a per user standard directory as well. 

>
> That way, PyQwt could install a .api in a standard place. 

The install should offer to install into the standard directory, but that 
should be overridable by the user. For example, a user might want to install 
a package like PyQwt locally to test it or he has not the rights to install 
it globally. How does QScintilla know about the API file in that case?

> Eric would be 
> able to display a project specific dialog that allowed users to select
> which APIs they wanted to use.
>

Detlev
-- 
Detlev Offenbach
detlev at die-offenbachs.de