On Sunday 15 October 2006 11:45 am, Detlev Offenbach wrote: > 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?
Your dialog would have a check box for each file discovered in the standard directory and a way of selecting additional API files from anywhere in the file system. I think the whole path thing is unnecessary over-engineering. Phil _______________________________________________ PyKDE mailing list PyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
