From: Doug B. <dou...@gm...> - 2013-09-17 11:03:39
|
On Tue, Sep 17, 2013 at 6:31 AM, Tim Lyons <guy...@gm...> wrote: > (I've removed the gramps user list cc). > > > > > On 17 Sep 2013, at 04:43, John Ralls wrote: > >> >> There are three universes here: >> Linux: Packagers are responsible for building everything that isn't >> already packaged >> by someone else. The user need only fire up her package manager and tell >> it to install >> Gramps and it will find all of the prebuilt dependencies and install them >> (except Gentoo, >> where it will build them for the user on her machine). No special >> expertise required. >> >> AIO packages for Win32 and MacOSX. The bundler (me in the latter case) >> decides what >> goes in. The user doesn't have a choice about adding dependencies, so if >> an addon requires >> one and it isn't in the bundle, too bad. >> >> MacPorts, Fink, Homebrew, and similar are somewhere in between, in that >> while the user >> has to do the build, someone is maintaining the necessary scripts. The >> user has to be capable >> of installing the developer tools and running the scripts, but most of the >> time needn't know >> more. If she does, she might be able to work out how to build extra >> dependencies for some >> addon she really wants to try. >> >> IME most genealogical software users aren't interested in anything more >> complicated than >> using an AIO package, so addons which require extra dependencies are out >> of the question. >> Almost none use Linux. I see about 10% Mac Laptops at the National >> Genealogical Society >> conferences, and perhaps double that at RootsTech. >> >> An aside about htmlview, a "core plugin", on MacOSX: WebKitGtk is huge, >> takes hours to >> compile even on a very fast computer, and their team is actively hostile >> to the Quartz >> backend--they incorporated changes some years ago to ensure that WebKitGtk >> won't build >> without X11. IMO opening webpages in the browser for viewing is fine, so I >> don't include >> WebKitGtk in the bundle, and htmlview, a core plugin, raises a warning. I >> think it would be >> a good thing if it didn't, but I don't like the idea of special-casing it >> somehow. >> >> So do we add a gpr flag about extra dependencies and a preference that >> hides addons which >> have that flag set by default? >> > > I like this analysis a lot. (I would add the Linux power users who do > manually installs etc to the third group, but that's not important). > > Based on this, could we just remove things that use WebKitGtk completely > from Gramps - it seems very non-essential and is just another thing that has > to be maintained. Seems to bloat Gramps, and goes against the philosophy of > doing one job well - swiss army knives may be handy when nothing else is > available, but special tools usually beat them. Removing it just seems to > cut the Gordian knot. > > > > > > As for addon, I rather like the idea addons that need extra dependencies are > out of the question (i.e. we never allow them at all). > > If this is not accepted, then I want addons to work like this: > User clicks on install addon (in the check now preferences), then if the > addon has some dependency that is not satisfied, it comes back with a > dialogue that the addon cannot be installed, and you need to click OK on > that. > Subsequently (and this is the important bit) if you check addons again, it > offers to install that addon again - i.e. it behaves as if the addon was > not installed. If you select the addon again, you get the same result. > > The important bit is that if you forget why the addon didn't install > properly, you can try again and see what the result was. So when someone > says 'why don't you try addon xyz it's great' you don't rely on memory of > why it didn't work. > > I am describing this UI rather than saying that I don't want the addon to be > installed and then ignored. I don't think the addon should be installed and > then run to check it, but the important thing is the effect. I don't like > the idea of hiding things and hate the idea of having to look somewhere else > (like the plugin manager) to see why the addon is not working. I think we can do something like this, but make it even more effective. For example, consider an addon that requires package-1.2.3. So, you get package-1.2.3 (install or build it) and the addon is fine. But then later, package-1.2.3 is removed, or breaks because of one of its dependencies breaks. Then we are in the same state as before: the addon can't be used until something is fixed. It seems we should do this check for each addon each time we attempt to load it. So it could work this way: At start up, all of the installed and non-hidden plugins/addons are tested by running a function in the plugin/addon. If the test fails, then the user needs to be informed and make a decision: The following plugin/addon failed to load. Options: 1. Disable it (you can enable it later with the Plugin Manager) 2. Find out more information (opens webpage) 3. See exact error details 4. Ignore for now (Perhaps we could have a single dialog for all, rather than one per fail. In command-line mode, we can issue a warning, or just ignore). We need a link for option 2 to provide installation instructions, but we already have an api for providing a web page for each addon/plugin. Most addons would just return a positive in the test, as most don't have any other dependencies. This plan wouldn't require major changes, but I think satisfies the goals to make it easier to understand what is happening without having to require zero external dependencies. (I wouldn't want to kill experimental addons that are attempting to make cool new functionality by building on other libraries). -Doug > > Regards, > Tim. > > > >> Regards, >> John Ralls >> >> >> >> >> > |