Le 1 oct. 06 à 08:50, Yen-Ju Chen a écrit :
With the experimental GtkMozEmbed on hand,
I would like to have some discussion about the BookmarkKit.
Frankly, the most important question I have is what kind of storage we
should use ?
We can go for one bookmark per file (as Mac OSX), single file
(property list),
or system-wide database (CoreData/sqlite3).
CoreData/sqlite3 is the best choice I think.
OSX switch to per-file based system because of the indexing.
This is a limitation of current Spotlight version, not a technical
one related to indexing.
They probably miss enough time to introduce an API allowing arbitrary
objects indexing. In Mac OS X Leopard, I read they are going to move
AddressBook, Mail and other similar application stores to CoreData
(away from per-file based system in other words)
And it is indeed the best situation for LuceneKit.
My plan was to provide an abstraction layer over LuceneKit, that
would allow to index objects implementing a dedicated protocol or
being exported as core objects (in CoreObject sense).
But since this kind of data is structured,
a system-wide database is not a bad solution considering sqlite3 does
offer searching.
If we can decide the storage system, we can also use it for
AddessesKit,
and probably Grr.
And if the CoreData is ready, it is not a bad idea to integrate
everything together.
At first sight, I don't think it's a really good idea to put
everything together, it's probably better to put each kind of object
in separate database.
It's true it could allow better search speed : it's faster to run a
single query on a single database than several ones.
For a system-wide search request, even if we don't reindex the
objects in this database with LuceneKit and we rather search both
LuceneKit index and this global database, the speed should be quite
good. If we have several different databases we will need to reindex
them in LuceneKit to keep a decent search speed.
I think it's not easy to tune the number of databases/indexes choice
in order to keep the best possible search speed in as many cases as
possible.
However we won't probably be able to avoid other databases for third-
party applications unless we decide to make this system database
open, but it could be rapidly screwed up by too many entries then.
I'm also really not sure CoreData has been designed to scale in such
important way (handling a bunch of schemas), this should be checked.
As a last note. The last time I checked it, GSCoreData wasn't totally
ready. We should ask Saso about it :-)
Another question is how do we display bookmark in GNUstep GUI ?
Well, why not a system-wide menulet and optionally a dedicated menu
in each application.
Most application display it as submenu of a horizontal menu.
But since we can have a vertical menu (standard GNUstep GUI),
At this time, our menu is horizontal, I think it's going to stay as
the default choice, not sure we should really spend time on such
point then.
Yet I would like to offer the possibility to switch to vertical menu
if the user prefers (better for big screen).
would it be a little too wide (main menu + bookmark submenu with
website title) ?
It's a job of the user to give short and descriptive names for his
bookmarks, not ours ;-)
hm, I don't see how a bookmark submenu would be more wide when
displayed vertically…
By the way, do people think it is fine to put this experimental web
browser into SVN ?
Yes. I won't include it in the default build process though.
You can create a branch if you prefer too.
If so, we need a name for it. I prefer not to use GtkMozEmbed.
Probably a lizard name, such as anoles, etc
I'm sure many people will have good suggestions on this point ;-)
I did check the WebKit, but it is far from usable on Linux/FreeBSD.
And who knows when it will be available.
On the Linux/FreeBSD side, mozilla is still a better solution.
Linking to libraries is always better than porting libraries
considering we don't have enough man power now.
right.
Cheers,
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
_______________________________________________
Etoile-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-discuss
