From: Tim L. <guy...@gm...> - 2013-09-16 17:08:15
|
John is dealing with the no handlers problem - he doesn't want to subscribe to the user list. I have copied this to the dev list, and I suggest we continue discussion there. On 16 Sep 2013, at 16:59, Doug Blank wrote: > On Mon, Sep 16, 2013 at 10:45 AM, Tim Lyons <guy...@gm...> > wrote: > >> DS Blank wrote >>>> 2013-09-13 17:06:02.602: WARNING: geography.gpr.py: line 61: >>>> OsmGpsMap >>>> module not loaded. Geography functionality will not be available. >>>> To build it for Gramps see >>>> http://www.gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion#OsmGpsMap_for_Geography >>> >>> Apparently you know that you need additional libraries to use this >>> one. >> >> We need to arrange for this message to not be present. We could >> move the >> modules that use OsmGpsMap (and the other modules that are not >> available as >> released binaries i.e spell and exif) out of core gramps and into >> the addon >> repository (but we would still need to deal with the problem when >> users try >> to include them), or we could press for the relevant dependencies >> to be >> cleaned up and made available for official distributions. Or both. > > A general point: if you run Gramps and something (either something in > core, or an addon) attempts to load, but cannot because of a missing > dependency, what should happen? > > Currently we have various messages that appear at that moment, > including "ERROR:" and other stack traces. Tim is suggesting that > dependency-optional non-load messages should not be reported here. If > not here, then when and where? > > We should perhaps just output to the info dialog and not spew so much > at the command line? No, I'm not suggesting that the error messages should be suppressed - I don't think hiding errors is a good idea. If there are missing dependencies, then this should be reported, and I think the current ERROR/WARNING and "!" icon in the GUI is reasonable. However, a normal user using the normal package installation method should have the dependencies resolved for him and never get any such error messages. This can't be the case if you have to manually build certain packages from source (I know that is hopefully a temporary problem with Gramps 4.x). I suppose I am saying that there should be no dependency-optional packages in core Gramps. And we should NOT depend on things that need to be manually built. > > Or perhaps you should be able to look at the plugin list in the Plugin > Manager and see all of those that fail because of a missing > dependency. But then you only know of something that isn't available > if you go looking for it in the Plugin Manager. If we move everything that depends on optional packages into addons (generally, but spell checking is a problem), then the "Install Selected Addons" in the "Avaialable Gramps Updates for Addons" should really check whether the optional packages are present before installing the addons. So you would get a message like "Sorry, I can't install the Geography package because OsmGpsMap is not installed. Use your package manager to install py_OsmGpsMap (or whatever) and then try again to install Geopgraphy". > > But loading messages should probably not be marked "ERROR", so that is > another bug. > >> >> DS Blank wrote >>>> ERROR: Plugin file >>>> /home/harvey/.gramps/gramps40/plugins/ChangeGivenNames/ >>>> ChangeGivenNames.py >>>> has a version of "4.0.2" which is invalid for Gramps "4.0.1". >>> >>> Not really an error: this says that you need at least Gramps 4.0.2 >>> to >>> use this updated addon. You have 4.0.1. >> >> Sounds like an error, as it seems unlikely and wrong that >> ChangeGivenNames >> should be compatible with 4.0.2 but not 4.0.1, when the last digit >> version >> change should only be for a bug fix, not a functionality change. If >> this is >> really a requirement then should the addon code check and use all >> three >> digits of the version before offering to include the addon. > > As I mentioned, this is working as designed. For better or worse, the > signature of Tools was changed after the release of 4. Normally, you > are right that a tool written for 4.0.2 would work for Gramps 4.0.1, > but not in this case, and the updater is smart enough to be able to > mark and identify this situation. > > But again, it should probably not report this when starting up. So > what if a tool is no longer available? It will be removed from the > menu, but we need to provide a way to find out what is missing/needs > to be updated. I'm not sure I understand the sequence of events that caused this error. If the user installed the new version of the addon when he had Gramps 4.0.1, then he should not have been offered that particular addon if it was incompatible with the current version of Gramps. It is not at all user friendly if a tool is not available, and it is not obvious why not. On Nabble (but he hasn't worked out how to send it to the actual list) there is a user who says he has tried to install the GraphView addon, but the addon is not displayed. How on earth is the user supposed to diagnose the problem. It eventually occurred to me that he might get a clue by looking at the Loaded Plugins tab in the Plugin Manager, but this is really non-obvious. > >> >> DS Blank wrote >>>> ERROR: Plugin file >>>> /home/harvey/.gramps/gramps40/plugins/Census/CensusFix.py has a >>>> version >>>> of "3.4" which is invalid for Gramps "4.0.1".' >>> >>> Looks like you have some 3.4 code mixed up in your 4.0 addons. You >>> can >>> delete CensusFix.py I presume, or just ignore this. >> >> Is this a mistake on the part of the user, or the addon repository? > > It could have come from either... it isn't in the downloadables now, > but it could have been in the repository at one time. Again, I'm not sure what the sequence of events was. Perhaps it was a problem with the repository that just existed for a short time, in which case, it was just a bug, and there is not much structural that we could do to fix it. > >> >> DS Blank wrote >>>> I count 4 warnings/errors here. >>>> >>>> Can anyone tell me which ones are bugs to be reported (if not >>>> already) >>>> and which I can correct for myself (and how?) >>> >>> Maybe the only thing to report is that the errors/warnings are >>> hard to >>> interpret. Everything appears to be working as designed. >> >> Well, it may be working, but that doesn't mean that there are no >> bugs! It >> should be working and appear to be working. > > There are bugs... lots of them. But none of the items mentioned here > are things that aren't working as designed. I like your premise: "if > Gramps is working, it should be quiet". > > I think we need a better design on how we report: > > 1) the need/request to update Gramps > 2) the need/request to install another package to gain additional > functionality (how, when, how often) > > And that could be another "Request for Feature/Enhancement". (BTW, > addons have a dependency list for listing other addons that should be > loaded first. Unfortunately that can't really work for Linux distro > packages as they don't have standard names, and Windows doesn't have > packages at all.) For a start, lets distinguish core gramps from addons. For core gramps, I don't like optional dependencies. However, I recognise that there are problems with Gramps 4.x untll some key packages (especially spell checking) are upgraded so they work for us. For core gramps, I think we should fix the issue about making it quiet. For addons, and upgrades, I think we have some good models in other software which comes back to the user to say things like "addon xyz is no longer compatible with your new version of Gramps, would you like me to look for a compatible version(and if none, please allow me to disable it)". Regards, Tim. |
From: Paul F. <pf....@gm...> - 2013-09-17 00:20:30
|
> I suppose I am saying that there should be no dependency-optional > packages in core Gramps. And we should NOT depend on things that need > to be manually built. I agree with both those those statements 100%. > If we move everything that depends on optional packages into addons > (generally, but spell checking is a problem), then the "Install > Selected Addons" in the "Avaialable Gramps Updates for Addons" should > really check whether the optional packages are present before > installing the addons. I would think this could be relatively easily done, by putting an "import" into the relevant foo.gpr.py file which checks for /every dependency/ the plugin needs (with possible imports of the gi.repository first, for fussy ones), and /only/ if /every/ dependency is present would the plugin be loaded/mentioned. |
From: Doug B. <dou...@gm...> - 2013-09-17 00:31:15
|
On Mon, Sep 16, 2013 at 8:20 PM, Paul Franklin <pf....@gm...> wrote: >> I suppose I am saying that there should be no dependency-optional >> packages in core Gramps. And we should NOT depend on things that need >> to be manually built. > > I agree with both those those statements 100%. I appreciate the sentiment of those statements, but I don't think that this practical. For example, some dependencies were available on Fedora 13, but had to be manually built on Ubuntu 12.04. What then? And some things get added to a distribution because they are used. If we don't use them, then they never will get included. A catch-22. >> If we move everything that depends on optional packages into addons >> (generally, but spell checking is a problem), then the "Install >> Selected Addons" in the "Avaialable Gramps Updates for Addons" should >> really check whether the optional packages are present before >> installing the addons. > > I would think this could be relatively easily done, by putting > an "import" into the relevant foo.gpr.py file which checks for > /every dependency/ the plugin needs (with possible imports > of the gi.repository first, for fussy ones), and /only/ if /every/ > dependency is present would the plugin be loaded/mentioned. gpr files were meant to be as close to a config file as possible, with little chance of failing. But I like the idea of a bit of code in the addon/plugin that would try to run, and if it failed, then the addon/plugin would give a message, and de-activate (hide) itself. Maybe that bit of code is just the loading of it. -Doug > ------------------------------------------------------------------------------ > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Tim L. <guy...@gm...> - 2013-09-17 10:48:45
|
On 17 Sep 2013, at 01:31, Doug Blank wrote: > On Mon, Sep 16, 2013 at 8:20 PM, Paul Franklin <pf....@gm...> > wrote: >>> I suppose I am saying that there should be no dependency-optional >>> packages in core Gramps. And we should NOT depend on things that >>> need >>> to be manually built. >> >> I agree with both those those statements 100%. > > I appreciate the sentiment of those statements, but I don't think that > this practical. For example, some dependencies were available on > Fedora 13, but had to be manually built on Ubuntu 12.04. What then? Doesn't the package manager check whether the dependency is available in the distribution's repository, and if not, it tells you you can't install Gramps (or at least the Gramps that gets installed is the one that has satisfied dependencies). I don't know, because I have not used Linux in that way. As a Linux (Ubuntu) user, I use the GUI package manager, and that just offers quite an old version of Gramps. The dependencies are know to be available in the repository. So, Gramps 4.x is/would not be available through the package manager on Ubuntu 12.04 because dependencies are not available. > > And some things get added to a distribution because they are used. If > we don't use them, then they never will get included. A catch-22. > I think the answer is that the Gramps project needs to put in a request to the distribution to add the package they are thinking of using. Do we need to request the remaining manual build packages (map, spell and exif)? Regards, Tim. |
From: Doug B. <dou...@gm...> - 2013-09-16 17:43:31
|
On Mon, Sep 16, 2013 at 1:08 PM, Tim Lyons <guy...@gm...> wrote: > John is dealing with the no handlers problem - he doesn't want to subscribe > to the user list. > > I have copied this to the dev list, and I suggest we continue discussion > there. Oh, thanks; I didn't realize that that conversation was on the users mailing list. (I'm removing users from the CC as this is really development issues). I think you may be proposing some changes in the way that Gramps works. Some points: 1. There are sections of code that perform best when there are additional packages installed, but it has been made to work without those. We have a list of "optional dependencies" and that includes features such as: spell checking, sorting, geo-location features, languages, and maybe image functions. 2. It is not considered an error to not have these optional dependencies. 3. Installing an addon means to copy it to your download directory. There is checking that occurs for correct version matches, but that happens when the "listing file" is iterated over. There is no running of code of an addon before it is downloaded, so there is no way to run code to check to see if an addon should be downloaded. Further comments below: > > On 16 Sep 2013, at 16:59, Doug Blank wrote: > >> On Mon, Sep 16, 2013 at 10:45 AM, Tim Lyons <guy...@gm...> wrote: >> > > >>> DS Blank wrote >>>>> >>>>> 2013-09-13 17:06:02.602: WARNING: geography.gpr.py: line 61: OsmGpsMap >>>>> module not loaded. Geography functionality will not be available. >>>>> To build it for Gramps see >>>>> >>>>> http://www.gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion#OsmGpsMap_for_Geography >>>> >>>> >>>> Apparently you know that you need additional libraries to use this one. >>> >>> >>> We need to arrange for this message to not be present. We could move the >>> modules that use OsmGpsMap (and the other modules that are not available >>> as >>> released binaries i.e spell and exif) out of core gramps and into the >>> addon >>> repository (but we would still need to deal with the problem when users >>> try >>> to include them), or we could press for the relevant dependencies to be >>> cleaned up and made available for official distributions. Or both. >> >> >> A general point: if you run Gramps and something (either something in >> core, or an addon) attempts to load, but cannot because of a missing >> dependency, what should happen? >> >> Currently we have various messages that appear at that moment, >> including "ERROR:" and other stack traces. Tim is suggesting that >> dependency-optional non-load messages should not be reported here. If >> not here, then when and where? >> >> We should perhaps just output to the info dialog and not spew so much >> at the command line? > > > No, I'm not suggesting that the error messages should be suppressed - I > don't think hiding errors is a good idea. If there are missing dependencies, > then this should be reported, and I think the current ERROR/WARNING and "!" > icon in the GUI is reasonable. The question is really: are these missing dependencies error messages? Since you can't check before you download, then you end up with addons that might require more to use. > However, a normal user using the normal package installation method should > have the dependencies resolved for him and never get any such error > messages. This can't be the case if you have to manually build certain > packages from source (I know that is hopefully a temporary problem with > Gramps 4.x). > > I suppose I am saying that there should be no dependency-optional packages > in core Gramps. And we should NOT depend on things that need to be manually > built. I don't think that we can say that because Gramps runs on lots of platforms, with various ways of satisfying dependencies. > >> >> Or perhaps you should be able to look at the plugin list in the Plugin >> Manager and see all of those that fail because of a missing >> dependency. But then you only know of something that isn't available >> if you go looking for it in the Plugin Manager. > > > If we move everything that depends on optional packages into addons > (generally, but spell checking is a problem), then the "Install Selected > Addons" in the "Avaialable Gramps Updates for Addons" should really check > whether the optional packages are present before installing the addons. So > you would get a message like "Sorry, I can't install the Geography package > because OsmGpsMap is not installed. Use your package manager to install > py_OsmGpsMap (or whatever) and then try again to install Geopgraphy". > As addon downloads don't work that way, then we need a different strategy. Is there any problem with them just staying dormant, with a simple informational message, that might not appear on the command-line, but only when you look for it? >> >> But loading messages should probably not be marked "ERROR", so that is >> another bug. >> >>> >>> DS Blank wrote >>>>> >>>>> ERROR: Plugin file >>>>> >>>>> /home/harvey/.gramps/gramps40/plugins/ChangeGivenNames/ChangeGivenNames.py >>>>> has a version of "4.0.2" which is invalid for Gramps "4.0.1". >>>> >>>> >>>> Not really an error: this says that you need at least Gramps 4.0.2 to >>>> use this updated addon. You have 4.0.1. >>> >>> >>> Sounds like an error, as it seems unlikely and wrong that >>> ChangeGivenNames >>> should be compatible with 4.0.2 but not 4.0.1, when the last digit >>> version >>> change should only be for a bug fix, not a functionality change. If this >>> is >>> really a requirement then should the addon code check and use all three >>> digits of the version before offering to include the addon. >> >> >> As I mentioned, this is working as designed. For better or worse, the >> signature of Tools was changed after the release of 4. Normally, you >> are right that a tool written for 4.0.2 would work for Gramps 4.0.1, >> but not in this case, and the updater is smart enough to be able to >> mark and identify this situation. >> >> But again, it should probably not report this when starting up. So >> what if a tool is no longer available? It will be removed from the >> menu, but we need to provide a way to find out what is missing/needs >> to be updated. > > > I'm not sure I understand the sequence of events that caused this error. If > the user installed the new version of the addon when he had Gramps 4.0.1, > then he should not have been offered that particular addon if it was > incompatible with the current version of Gramps. There is only one listing file per major gramps version (3.4, 4.0, 4.1/trunk). As such, there may be things in the listing that are too old or too new for your version of Gramps. Either way, those have already been downloaded, and are in the plugins directory. > It is not at all user friendly if a tool is not available, and it is not > obvious why not. On Nabble (but he hasn't worked out how to send it to the > actual list) there is a user who says he has tried to install the GraphView > addon, but the addon is not displayed. How on earth is the user supposed to > diagnose the problem. It eventually occurred to me that he might get a clue > by looking at the Loaded Plugins tab in the Plugin Manager, but this is > really non-obvious. This is the main question that needs to be solved. How do you know that something is available but needs more? How do you get the additional dependencies once you know and decide you need them? > > >> >>> >>> DS Blank wrote >>>>> >>>>> ERROR: Plugin file >>>>> /home/harvey/.gramps/gramps40/plugins/Census/CensusFix.py has a version >>>>> of "3.4" which is invalid for Gramps "4.0.1".' >>>> >>>> >>>> Looks like you have some 3.4 code mixed up in your 4.0 addons. You can >>>> delete CensusFix.py I presume, or just ignore this. >>> >>> >>> Is this a mistake on the part of the user, or the addon repository? >> >> >> It could have come from either... it isn't in the downloadables now, >> but it could have been in the repository at one time. > > > Again, I'm not sure what the sequence of events was. Perhaps it was a > problem with the repository that just existed for a short time, in which > case, it was just a bug, and there is not much structural that we could do > to fix it. > Perhaps not bringing attention to itself would be fine for most people. But for those that are interested, there should be an obvious manner to discover what the issue is. >> >>> >>> DS Blank wrote >>>>> >>>>> I count 4 warnings/errors here. >>>>> >>>>> Can anyone tell me which ones are bugs to be reported (if not already) >>>>> and which I can correct for myself (and how?) >>>> >>>> >>>> Maybe the only thing to report is that the errors/warnings are hard to >>>> interpret. Everything appears to be working as designed. >>> >>> >>> Well, it may be working, but that doesn't mean that there are no bugs! It >>> should be working and appear to be working. >> >> >> There are bugs... lots of them. But none of the items mentioned here >> are things that aren't working as designed. I like your premise: "if >> Gramps is working, it should be quiet". >> >> I think we need a better design on how we report: >> >> 1) the need/request to update Gramps >> 2) the need/request to install another package to gain additional >> functionality (how, when, how often) >> >> And that could be another "Request for Feature/Enhancement". (BTW, >> addons have a dependency list for listing other addons that should be >> loaded first. Unfortunately that can't really work for Linux distro >> packages as they don't have standard names, and Windows doesn't have >> packages at all.) > > > > > For a start, lets distinguish core gramps from addons. For core gramps, I > don't like optional dependencies. However, I recognise that there are > problems with Gramps 4.x untll some key packages (especially spell checking) > are upgraded so they work for us. Again, lots of platforms with various levels of support for dependencies. > For core gramps, I think we should fix the issue about making it quiet. I guess that means making missing optional dependencies not an "error", and then deciding how we will report it. > For addons, and upgrades, I think we have some good models in other software > which comes back to the user to say things like "addon xyz is no longer > compatible with your new version of Gramps, would you like me to look for a > compatible version(and if none, please allow me to disable it)". We could add a function to plugins such that some code could be run after downloaded to see if it should be "hidden" or "visible" (technical term used by the plugin system to indicate if a plugin is active or not). If not active, it wouldn't even try to get loaded. In effect, this would appear to be like you describe, although in reality it would really be installed, but just marked hidden. -Doug > Regards, > Tim. > |
From: Tim L. <guy...@gm...> - 2013-09-17 00:13:15
|
DS Blank wrote > 3. Installing an addon means to copy it to your download directory. > There is checking that occurs for correct version matches, but that > happens when the "listing file" is iterated over. There is no running > of code of an addon before it is downloaded, so there is no way to run > code to check to see if an addon should be downloaded. Well, if it is just a question of optional dependencies, the 'listing file' could contain a list of the optional dependencies and this could be processed before deciding whether to download the addon. I don't like the idea of discovering there is some limitation AFTER the addon has already been downloaded. I need to think some more about other optional dependencies. The main issue is how the user knows what he had got. We don't want the user complaining that Gramps doesn't work as advertised in the manual, or more likely doesn't do something the way it does it for his friend or doesn't do the neat trick that is mentioned in some list posting, when this is because something he doesn't even know about is missing. Some applications pop up a box every so often saying that updates are available - I know this is annoying, but at least it warns you that you may have problems that have already been fixed. Maybe the Granps about box could contain something like "Known Issues": You are running Gramps version 3.4.2. A later version 3.4.6 is available for your platform. (The very latest version 4.0.1 is not yet available for your platform). Geography functionality is not available because you have not installed osm... (followed by platform specific advice on how to fix this). etc. Although in theory, Gramps is available for many platforms, in practice, unless you are an experienced Linux user who can install from a deb etc, there is only Windows, Mac and Linux official distributions. For Windows and Mac the user can't really install any optional packages himself - he just has the ones build into his distribution. And for non power Linux users, the situation is not much different, unless the dependencies are available in the official repository, they are effectively unavailable. Of course, all this discussion is predicated on how Aunt Martha experiences Gramps, not a Linux power user. Regards, Tim. -- View this message in context: http://gramps.1791082.n4.nabble.com/Re-Gramps-users-Which-errors-are-bugs-tp4662533p4662540.html Sent from the GRAMPS - Dev mailing list archive at Nabble.com. |
From: John R. <jr...@ce...> - 2013-09-17 03:43:21
|
On Sep 16, 2013, at 10:08 AM, Tim Lyons <guy...@gm...> wrote: > John is dealing with the no handlers problem - he doesn't want to > subscribe to the user list. > > I have copied this to the dev list, and I suggest we continue > discussion there. > > On 16 Sep 2013, at 16:59, Doug Blank wrote: > >> On Mon, Sep 16, 2013 at 10:45 AM, Tim Lyons <guy...@gm...> >> wrote: >> > > >>> DS Blank wrote >>>>> 2013-09-13 17:06:02.602: WARNING: geography.gpr.py: line 61: >>>>> OsmGpsMap >>>>> module not loaded. Geography functionality will not be available. >>>>> To build it for Gramps see >>>>> http://www.gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion#OsmGpsMap_for_Geography >>>> >>>> Apparently you know that you need additional libraries to use this >>>> one. >>> >>> We need to arrange for this message to not be present. We could >>> move the >>> modules that use OsmGpsMap (and the other modules that are not >>> available as >>> released binaries i.e spell and exif) out of core gramps and into >>> the addon >>> repository (but we would still need to deal with the problem when >>> users try >>> to include them), or we could press for the relevant dependencies >>> to be >>> cleaned up and made available for official distributions. Or both. >> >> A general point: if you run Gramps and something (either something in >> core, or an addon) attempts to load, but cannot because of a missing >> dependency, what should happen? >> >> Currently we have various messages that appear at that moment, >> including "ERROR:" and other stack traces. Tim is suggesting that >> dependency-optional non-load messages should not be reported here. If >> not here, then when and where? >> >> We should perhaps just output to the info dialog and not spew so much >> at the command line? > > No, I'm not suggesting that the error messages should be suppressed - > I don't think hiding errors is a good idea. If there are missing > dependencies, then this should be reported, and I think the current > ERROR/WARNING and "!" icon in the GUI is reasonable. > > However, a normal user using the normal package installation method > should have the dependencies resolved for him and never get any such > error messages. This can't be the case if you have to manually build > certain packages from source (I know that is hopefully a temporary > problem with Gramps 4.x). > > I suppose I am saying that there should be no dependency-optional > packages in core Gramps. And we should NOT depend on things that need > to be manually built. > >> >> Or perhaps you should be able to look at the plugin list in the Plugin >> Manager and see all of those that fail because of a missing >> dependency. But then you only know of something that isn't available >> if you go looking for it in the Plugin Manager. > > If we move everything that depends on optional packages into addons > (generally, but spell checking is a problem), then the "Install > Selected Addons" in the "Avaialable Gramps Updates for Addons" should > really check whether the optional packages are present before > installing the addons. So you would get a message like "Sorry, I can't > install the Geography package because OsmGpsMap is not installed. Use > your package manager to install py_OsmGpsMap (or whatever) and then > try again to install Geopgraphy". [SNIP] > > For a start, lets distinguish core gramps from addons. For core > gramps, I don't like optional dependencies. However, I recognise that > there are problems with Gramps 4.x untll some key packages (especially > spell checking) are upgraded so they work for us. > > For core gramps, I think we should fix the issue about making it quiet. > > For addons, and upgrades, I think we have some good models in other > software which comes back to the user to say things like "addon xyz is > no longer compatible with your new version of Gramps, would you like > me to look for a compatible version(and if none, please allow me to > disable it)". 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? Regards, John Ralls |
From: Tim L. <guy...@gm...> - 2013-09-17 10:31:26
|
(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. Regards, Tim. > Regards, > John Ralls > > > > > |
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 >> >> >> >> >> > |
From: Tim L. <guy...@gm...> - 2013-09-25 15:03:23
|
I suggest that we remove the HTML view completely. As mentioned below, it is problematic at least for one packager (the Mac one). It just does something that is probably better and more flexibly done by the user's browser. It is not at all obvious that the view even exists. The view and how to enable it does not seem to have been documented in the user manual till 4.0. In the 3.1 user manual it was described as 'experimantal'. The mechanism to activate the view is very complicated [1]. I could only document it for 4.0 by looking at the code to see how to activate it. It produces a warning when the optional dependency is not present. It is yet another thing to maintain (it doesn't look very simple and there are options for two different renderer implementations). Let's just delete it. (As I understand it, the Geography view is independent of the renderer for the HTML view, so the Geography view would not be affected). Regards, Tim. [1] http://www.gramps-project.org/wiki/index.php?title=Gramps_4.0_Wiki_Manual_-_Categories#Hidden_Html_View_Category Tim Lyons 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. -- View this message in context: http://gramps.1791082.n4.nabble.com/Re-Gramps-users-Which-errors-are-bugs-tp4662533p4662705.html Sent from the GRAMPS - Dev mailing list archive at Nabble.com. |
From: Benny M. <ben...@gm...> - 2013-09-26 08:59:38
|
2013/9/25 Tim Lyons <guy...@gm...> > I suggest that we remove the HTML view completely. > > As mentioned below, it is problematic at least for one packager (the Mac > one). It just does something that is probably better and more flexibly done > by the user's browser. It is not at all obvious that the view even exists. > The view and how to enable it does not seem to have been documented in the > user manual till 4.0. In the 3.1 user manual it was described as > 'experimantal'. The mechanism to activate the view is very complicated [1]. > I could only document it for 4.0 by looking at the code to see how to > activate it. It produces a warning when the optional dependency is not > present. It is yet another thing to maintain (it doesn't look very simple > and there are options for two different renderer implementations). > > Let's just delete it. > If the geography no longer uses the base on which html view works, then that is an option. I don't mind it going, though I remember some user who indicated using it. As to gramps-addons, I don't agree that we can't allow things in gramps-addons that need extra dependencies. We want contributors to work together in gramps-addons, not publishing their things on their own website or a forum. At least, that was the reason for gramps-addons. A good practices where an addon registers and on first run checks it's extra dependancy and shows a box: dependency not satisfied, this addon cannot run, seems sufficient to me. This would only require a stub addon that when the real addon fails, the stub is used instead with the name of the addon that failed, with the info on crash and above box present. What AIO people would need is statistics on how many times things are downloaded from http://sourceforge.net/p/gramps-addons/code/2065/log/?path=/branches/gramps40/download/ I wonder if we can extract that from sourceforge... Benny > > (As I understand it, the Geography view is independent of the renderer for > the HTML view, so the Geography view would not be affected). > > Regards, > Tim. > > > [1] > > http://www.gramps-project.org/wiki/index.php?title=Gramps_4.0_Wiki_Manual_-_Categories#Hidden_Html_View_Category > > > > Tim Lyons 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. > > > > > > -- > View this message in context: > http://gramps.1791082.n4.nabble.com/Re-Gramps-users-Which-errors-are-bugs-tp4662533p4662705.html > Sent from the GRAMPS - Dev mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Enno B. <enn...@gm...> - 2013-09-25 16:18:49
|
Tim, > I suggest that we remove the HTML view completely. While I understand your reasoning, and never use the built-in browser either, I wonder if this will affect the possible display of HTML like texts in notes, which I like to have some time. I like to use that to clip web pages which I now clip to evernote, and we may also need it to support the xhtml text type of GedcomX: https://github.com/FamilySearch/gedcomx/blob/master/specifications/conceptual-model-specification.md#138-text-types This type can be used in documents, which look like the notes we now have in Gramps. regards, Enno |
From: Tim L. <guy...@gm...> - 2013-09-25 18:57:24
|
enno wrote > Tim, >> I suggest that we remove the HTML view completely. > While I understand your reasoning, and never use the built-in browser > either, I wonder if this will affect the possible display of HTML like > texts in notes, which I like to have some time. I like to use that to > clip web pages which I now clip to evernote No, removing the HTML view would have no effect on the HTML notes. (As for the xhtml text type of GedcomX I similarly very much doubt that it would have any effect at all, and anyway, we should cross that bridge when we come to it, not make possible future enhancements affect out current support). Tim. -- View this message in context: http://gramps.1791082.n4.nabble.com/Re-Gramps-users-Which-errors-are-bugs-tp4662533p4662710.html Sent from the GRAMPS - Dev mailing list archive at Nabble.com. |