Parent: [9e7409] (diff)

Download this file

notes.txt    189 lines (149 with data), 6.9 kB

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
Recoll KIO Slave notes/todoes/etc.
Goal: access Recoll search from other applications.
We want to allow URLs like recoll:/?? to be used inside
Konqueror/Dolphin and open dialogs, to start a search with results
displayed/used inside the application.
Todoes
======
Implementation notes:
====================
- There are two main ways to do this:
- a-la kio_beagle, using listDir() to list entries pointing to the
different operations or objects (help, status, search result
entries, bookmarks, whatever...). The nice thing is that the
results really look like file object in a directory (probably,
didn't try it actually), no need for look and feel, it's provided by
KDE
- Or a la strigi: all interactions are through html pages and get()
operations. Much simpler, but does not allow file management
operations (except by drag/drop from the result list), and can't
use it inside other application's Open dialogs.
Recoll is currently doing both things on KDE4.1 (only html for KDE4.0).
Virtual tree:
=============
recoll:
recoll:/
recoll:/help.html
recoll:/search.html
Purely synthetic top level entries. Yes, given the following, this means
that you can't search for 'help.html' directly (but you can do it through
the html interface). These have to exist in the top level directory
recoll:/some search string
recoll:/some search string/
We have a 'mode' determined by the protocol name:
recoll -> mixed
recollf -> file manager
- html mode: these redirect to recoll://search/query?q="some search string"
- file manager mode: do the search and display results.
- mixed mode: what mode is entered depends on ending /
recoll://search/query?q=...
html mode search
recoll:/some search string/recollResultxyz
xyz is the index in result list.
When generating a directory, with use bogus names for the result
entries (the displayed ones are from UDS_DISPLAY_NAME and are the real
names). When doing drag/drop or "open with" Konqueror/Dolphin builds
an url by concatenating the current directory name and the UDS_NAME,
instead of using UDS_TARGET_URL as when the entry is clicked. This
forces us to use identifying names including the result number, which
has many ennoying side effects (such as the target app not knowing the
real file path...
KIO notes:
=========
- Slaves are reused seemingly at random. Even with connection-oriented
ones (ie ftp), you can have 2 konqueror windows on different hosts
with only one slave which will have to close/reopen the connection at
each switch.
For slaves with really expensive internal state, this is very wasteful.
- Use cases for father_url+name or target_url are ill defined.
- Need a way to block autocompletion queries !
- No way to display the target URL in konqueror
Todoes
======
- Improve the html interface to support more functions
- Category filtering
- Sorting
- Find a way to use the html form to enter the query and get the
results as a directory ? - Would it be possible to use a redirect
to switch to the directory-oriented results for a query from the
html form ?
-> No, even a redirect to a form that would initially trigger a
listDir() triggers a get() when performed from a get()
KDE misc notes
==================
Debug areas: /usr/share/kde4/config/kdebug.areas
kdebugdialog [--fullmode] pour configurer
./.kde/share/config/kdebugrc
Output to ~/.xession-errors by default. How to change ?
kio_recoll misc notes:
===========================
Probleme quand l'url se termine par un / et qu'on edite le mot,
konqueror lance une recherche a chaque lettre.
Apparemment c'est l'entree "listing" du .protocol qui decide si le plugin
est trait� plutot comme un dirlister ou comme un htmlgetter. Curieusement,
le changement ne s'opere pas toujours immediatement quand on change le
fichier .proto, y compris apres avoir tue tous les process kde (changement
� la deuxieme execution de konqueror sur kde4.0). Sur kde4.0 il faut que le
.proto soit sans entree "listing"
Problemes de gestion de l'etat
===============================
Les KIO slaves ne sont pas associes a une fenetre ! ils sont
reutilises au hasard, et leur etat n'a aucune raison de correspondre a
celui de l'affichage. On peut tres bien avoir 1 fenetre 2 kio ou 1 kio
deux fenetres, et le next d'un search peut arriver au kio qui a
l'autre search, donc n'importenaouak. Il faudrait que l'etat soit
partage et accede par un identifiant uniquement determine par l'url de
la fenetre.
Meme pour une fenetre unique, au bout d'un moment le kio timeout et exite.
En fait les slaves ne peuvent pas stocker d'etat du tout. Donc:
- soit un serveur central auquel ils parlent
- soit ils relancent dynamiquement les recherches si pas de match
C'est vrai aussi bien pour les dirlists que pour la version html.
J'ai essaye de mettre une boucle timeout callback callspecial() mais
ca ne sert a rien, c'est gere dans le process kio_slave, ca ne
maintient pas l'association avec un konqueror.
KDE_FORK_SLAVES sort of solves the problem in a limited way:
- It applies to an application instance, not a KIO slave type, so it
affects other KIO usages.
- If the application has 2 sessions with the same KIO there are no
warranties that 1 kio per session will be used ?
Old KDE3 notes,
===============
kio_recoll has not been checked or worked under KDE3 for eons, no
reason to believe it works.
- Not using libtool. Probably should. compilation flags in the Makefile
were copy-pasted from a kdebase compilation tree on FreeBSD (kio/man).
- You MUST install a kio_recoll.la in lib/kde3 along with kio_recoll.so,
else kdeinit won't be able to load the lib (probably uses the libltdl
thingy?). The one in this directory was duplicated/adjusted from
kio_man.la. The contents don't seem too critical, just needs to exist.
- If you want to try, compile, then install kio_recoll.la kio_recoll.so
wherever kde keeps its plugins (ie: lib/kde3), and recoll.protocol in the
services directory (share/services ? look for other .protocol file).
- I saw after doing the build/config mockup that kdevelop can generate a
kio_slave project. This might be the next thing to do. otoh would need to
separate the kio from the main source to avoid having to distribute 2megs
of kde build config files.
Connected mode
==============
Tried to add bogus connection status to see if this would prevent switching between apps/slaves, doesnt... checked that's the same for kio_ftp
void RecollProtocol::openConnection()
{
kDebug();
connected();
}
void RecollProtocol::closeConnection()
{
kDebug();
}
void RecollProtocol::setHost(const QString& host, quint16,
const QString&, const QString&)
{
kDebug() << host;
}
void RecollProtocol::slave_status()
{
kDebug();
slaveStatus("search", true);
}
+ connected(); call in maybeopendb()