Quantcast

Options to suppress warning messages

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Options to suppress warning messages

Nick Hall-6
I have just seen that commit r23205 adds options to suppress warning
messages for optional modules that are not installed.  I don't like this.

It would be better to reduce the level of these messages from WARN to
INFO, so they are not displayed at the default log level.  If an option
is given to the user, it should be the ability to change the log level.

Nick.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Options to suppress warning messages

DS Blank
On Fri, Sep 27, 2013 at 12:42 PM, Nick Hall <[hidden email]> wrote:
> I have just seen that commit r23205 adds options to suppress warning
> messages for optional modules that are not installed.  I don't like this.

Yes, I agree... this isn't the best solution.

> It would be better to reduce the level of these messages from WARN to
> INFO, so they are not displayed at the default log level.  If an option
> is given to the user, it should be the ability to change the log level.

I think the option to change log level (which might be related to
--debug) is beside the point: we need to:

1) inform the user that something is not working at full capacity
because of a missing, optional, dependency

2) how can they fulfill the missing dependency?

3) make this information only visible when needed/requested (run
quietly, without a ton of technical gibberish spewn to the screen)

4) give option to disable plugins that are missing such dependencies

Yes, we could maybe do some of this with a verbose flag, but I'd
rather see this type of information saved, and made visible in some
kind of dialog. We have a dialog (the info button) but I think you can
only write to it via the log level. Maybe if we had an API that
allowed us to write to the info window without having to spew on the
command-line, that would be enough. (Especially, if we could put URL
links in there, and maybe even "links" to be able to disable the
plugin).

See the discussion on "Which errors are bugs?" in this mailing list.

-Doug

> Nick.
>
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Options to suppress warning messages

Nick Hall-6
On 27/09/13 18:02, Doug Blank wrote:

> I think the option to change log level (which might be related to
> --debug) is beside the point: we need to:
>
> 1) inform the user that something is not working at full capacity
> because of a missing, optional, dependency
>
> 2) how can they fulfill the missing dependency?
>
> 3) make this information only visible when needed/requested (run
> quietly, without a ton of technical gibberish spewn to the screen)
>
> 4) give option to disable plugins that are missing such dependencies
>
> Yes, we could maybe do some of this with a verbose flag, but I'd
> rather see this type of information saved, and made visible in some
> kind of dialog. We have a dialog (the info button) but I think you can
> only write to it via the log level.

Yes, the info button displays messages generated using the logging
system.  You probably want to use a different mechanism here.  It would
be easy to add another button to the status bar.

> Maybe if we had an API that
> allowed us to write to the info window without having to spew on the
> command-line, that would be enough. (Especially, if we could put URL
> links in there, and maybe even "links" to be able to disable the
> plugin).

Instead of generating a warning we should display a warning button in
the status bar.  Clicking this button should display a dialog which
gives the detailed information you suggest, and an option to allow the
user to hide/disable the plugin.

Nick.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Options to suppress warning messages

DS Blank
On Fri, Sep 27, 2013 at 2:04 PM, Nick Hall <[hidden email]> wrote:

> On 27/09/13 18:02, Doug Blank wrote:
>>
>> I think the option to change log level (which might be related to
>> --debug) is beside the point: we need to:
>>
>> 1) inform the user that something is not working at full capacity
>> because of a missing, optional, dependency
>>
>> 2) how can they fulfill the missing dependency?
>>
>> 3) make this information only visible when needed/requested (run
>> quietly, without a ton of technical gibberish spewn to the screen)
>>
>> 4) give option to disable plugins that are missing such dependencies
>>
>> Yes, we could maybe do some of this with a verbose flag, but I'd
>> rather see this type of information saved, and made visible in some
>> kind of dialog. We have a dialog (the info button) but I think you can
>> only write to it via the log level.
>
>
> Yes, the info button displays messages generated using the logging system.
> You probably want to use a different mechanism here.  It would be easy to
> add another button to the status bar.
>
>
>> Maybe if we had an API that
>> allowed us to write to the info window without having to spew on the
>> command-line, that would be enough. (Especially, if we could put URL
>> links in there, and maybe even "links" to be able to disable the
>> plugin).
>
>
> Instead of generating a warning we should display a warning button in the
> status bar.  Clicking this button should display a dialog which gives the
> detailed information you suggest, and an option to allow the user to
> hide/disable the plugin.

I like this idea! Do you think we need both the Info dialog, and this
new dialog? It seems that they do very similar things (report an
issue, provide a link to more info, and possibly allow user to disable
something).

Now, we need an API... something like:

user.report_issue(filename, message, URL, plugin_id=None)

where None means that there is no plugin to be hidden (such as things
using pyICU or spelling checker).

It could be used something like:

user.report_issue("/home/name/gramps/gramps40/.plugins/myaddon/myaddon.py",
                             _("MyAddon needs the package XYZ."),
                             "http://gramps-project.org/additional-detail.html",
                             "myaddon")

After gramps gtk starts up, the "issue" button when be shown; clicking
it will show:

1. MyAddon needs the package XYZ. Click here for more info. [Disable Button]
2. OtherAddon needs the package ABC. Click here for more info. [Disable Button]
3. Spelling Checking needs the package python-ispell. Click here for more info.

Disabling a plugin will mark it "hidden" with the message to use the
Program Manager to re-enable it.

The CLI (and webapp) would have a report_issue method that did
nothing, or reported to the logger?

Anything else?

-Doug

> Nick.
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Options to suppress warning messages

Paul Franklin-5
> Anything else?

Some of these are about things which are not "third-party"
addons in the classical sense (spell checking, maps, image
metadata, Hebrew dates) -- but which are still optional, and
could be argued to be not needed for the main/primary use
of gramps.

So I don't know how/if that affects your suggestions.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Options to suppress warning messages

Nick Hall-6
In reply to this post by DS Blank
On 27/09/13 20:59, Doug Blank wrote:

> On Fri, Sep 27, 2013 at 2:04 PM, Nick Hall<[hidden email]>  wrote:
>> >On 27/09/13 18:02, Doug Blank wrote:
>>> >>
>>> >>I think the option to change log level (which might be related to
>>> >>--debug) is beside the point: we need to:
>>> >>
>>> >>1) inform the user that something is not working at full capacity
>>> >>because of a missing, optional, dependency
>>> >>
>>> >>2) how can they fulfill the missing dependency?
>>> >>
>>> >>3) make this information only visible when needed/requested (run
>>> >>quietly, without a ton of technical gibberish spewn to the screen)
>>> >>
>>> >>4) give option to disable plugins that are missing such dependencies
>>> >>
>>> >>Yes, we could maybe do some of this with a verbose flag, but I'd
>>> >>rather see this type of information saved, and made visible in some
>>> >>kind of dialog. We have a dialog (the info button) but I think you can
>>> >>only write to it via the log level.
>> >
>> >
>> >Yes, the info button displays messages generated using the logging system.
>> >You probably want to use a different mechanism here.  It would be easy to
>> >add another button to the status bar.
>> >
>> >
>>> >>Maybe if we had an API that
>>> >>allowed us to write to the info window without having to spew on the
>>> >>command-line, that would be enough. (Especially, if we could put URL
>>> >>links in there, and maybe even "links" to be able to disable the
>>> >>plugin).
>> >
>> >
>> >Instead of generating a warning we should display a warning button in the
>> >status bar.  Clicking this button should display a dialog which gives the
>> >detailed information you suggest, and an option to allow the user to
>> >hide/disable the plugin.
> I like this idea! Do you think we need both the Info dialog, and this
> new dialog? It seems that they do very similar things (report an
> issue, provide a link to more info, and possibly allow user to disable
> something).
>
> Now, we need an API... something like:
>
> user.report_issue(filename, message, URL, plugin_id=None)
>
> where None means that there is no plugin to be hidden (such as things
> using pyICU or spelling checker).
>
> It could be used something like:
>
> user.report_issue("/home/name/gramps/gramps40/.plugins/myaddon/myaddon.py",
>                               _("MyAddon needs the package XYZ."),
>                               "http://gramps-project.org/additional-detail.html",
>                               "myaddon")
>
> After gramps gtk starts up, the "issue" button when be shown; clicking
> it will show:
>
> 1. MyAddon needs the package XYZ. Click here for more info. [Disable Button]
> 2. OtherAddon needs the package ABC. Click here for more info. [Disable Button]
> 3. Spelling Checking needs the package python-ispell. Click here for more info.
>
> Disabling a plugin will mark it "hidden" with the message to use the
> Program Manager to re-enable it.
>
> The CLI (and webapp) would have a report_issue method that did
> nothing, or reported to the logger?
>
> Anything else?

The existing functionality just provides a gui handler for the standard
logging functionality.  It extends a rotate handler and the button is
only visible for 3 minutes.  This type of logging will be familiar to
most programmers and is probably sufficient for most purposes.

In fact, if we just made the existing messages more user friendly it
would help.

This proposed new functionality gives extra information and the ability
to disable plugins.  The API and dialog design you suggest seems like
the right approach.

Nick.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Options to suppress warning messages

DS Blank
In reply to this post by Paul Franklin-5
On Fri, Sep 27, 2013 at 4:15 PM, Paul Franklin <[hidden email]> wrote:
>> Anything else?
>
> Some of these are about things which are not "third-party"
> addons in the classical sense (spell checking, maps, image
> metadata, Hebrew dates) -- but which are still optional, and
> could be argued to be not needed for the main/primary use
> of gramps.
>
> So I don't know how/if that affects your suggestions.

I was thinking that if there isn't something that can be disabled, the
plugin_id would be None, and all you would see is the message and
link.

-Doug

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Options to suppress warning messages

DS Blank
In reply to this post by Nick Hall-6
Feature request summarizing "Which errors are bugs?" and this thread:

http://www.gramps-project.org/bugs/view.php?id=7092

-Doug

On Fri, Sep 27, 2013 at 5:42 PM, Nick Hall <[hidden email]> wrote:

> On 27/09/13 20:59, Doug Blank wrote:
>>
>> On Fri, Sep 27, 2013 at 2:04 PM, Nick Hall<[hidden email]>  wrote:
>>>
>>> >On 27/09/13 18:02, Doug Blank wrote:
>>>>
>>>> >>
>>>> >>I think the option to change log level (which might be related to
>>>> >>--debug) is beside the point: we need to:
>>>> >>
>>>> >>1) inform the user that something is not working at full capacity
>>>> >>because of a missing, optional, dependency
>>>> >>
>>>> >>2) how can they fulfill the missing dependency?
>>>> >>
>>>> >>3) make this information only visible when needed/requested (run
>>>> >>quietly, without a ton of technical gibberish spewn to the screen)
>>>> >>
>>>> >>4) give option to disable plugins that are missing such dependencies
>>>> >>
>>>> >>Yes, we could maybe do some of this with a verbose flag, but I'd
>>>> >>rather see this type of information saved, and made visible in some
>>>> >>kind of dialog. We have a dialog (the info button) but I think you can
>>>> >>only write to it via the log level.
>>>
>>> >
>>> >
>>> >Yes, the info button displays messages generated using the logging
>>> > system.
>>> >You probably want to use a different mechanism here.  It would be easy
>>> > to
>>> >add another button to the status bar.
>>> >
>>> >
>>>>
>>>> >>Maybe if we had an API that
>>>> >>allowed us to write to the info window without having to spew on the
>>>> >>command-line, that would be enough. (Especially, if we could put URL
>>>> >>links in there, and maybe even "links" to be able to disable the
>>>> >>plugin).
>>>
>>> >
>>> >
>>> >Instead of generating a warning we should display a warning button in
>>> > the
>>> >status bar.  Clicking this button should display a dialog which gives
>>> > the
>>> >detailed information you suggest, and an option to allow the user to
>>> >hide/disable the plugin.
>>
>> I like this idea! Do you think we need both the Info dialog, and this
>> new dialog? It seems that they do very similar things (report an
>> issue, provide a link to more info, and possibly allow user to disable
>> something).
>>
>> Now, we need an API... something like:
>>
>> user.report_issue(filename, message, URL, plugin_id=None)
>>
>> where None means that there is no plugin to be hidden (such as things
>> using pyICU or spelling checker).
>>
>> It could be used something like:
>>
>>
>> user.report_issue("/home/name/gramps/gramps40/.plugins/myaddon/myaddon.py",
>>                               _("MyAddon needs the package XYZ."),
>>
>> "http://gramps-project.org/additional-detail.html",
>>                               "myaddon")
>>
>> After gramps gtk starts up, the "issue" button when be shown; clicking
>> it will show:
>>
>> 1. MyAddon needs the package XYZ. Click here for more info. [Disable
>> Button]
>> 2. OtherAddon needs the package ABC. Click here for more info. [Disable
>> Button]
>> 3. Spelling Checking needs the package python-ispell. Click here for more
>> info.
>>
>> Disabling a plugin will mark it "hidden" with the message to use the
>> Program Manager to re-enable it.
>>
>> The CLI (and webapp) would have a report_issue method that did
>> nothing, or reported to the logger?
>>
>> Anything else?
>
>
> The existing functionality just provides a gui handler for the standard
> logging functionality.  It extends a rotate handler and the button is only
> visible for 3 minutes.  This type of logging will be familiar to most
> programmers and is probably sufficient for most purposes.
>
> In fact, if we just made the existing messages more user friendly it would
> help.
>
> This proposed new functionality gives extra information and the ability to
> disable plugins.  The API and dialog design you suggest seems like the right
> approach.
>
> Nick.
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Options to suppress warning messages

Tim Lyons
Administrator
The trouble with the 'Warning Button' [1] is that I suspect that almost noone notices that it is there, and I suspect that even fewer will click it in time to discover why something they thought should work is not working.

So the use case is: I have been working on my tree for some time, I start to input a note, and discover that spell checking is not working. How do I discover that this is due to an optional module being missing.

Similarly (as mentioned in the bugs thread): 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 don't think the suggestions help much.

One possibility would be to pop up a dialogue on start-up telling the user what the problems are. I know people won't like a dialogue on startup that need to be dismissed, but at least this would make sure the user was informed about the problem.

The problem with disabling things like a plugin is that when the user has forgotten that was what he did he will have difficulty in finding out how to re-enable the plugin.

I think the typical interface on other products is something that enables you to try again at any time. For example for spell check, you would click on 'Turn on spell check' and the response would be 'I'm sorry Dave, I can't do that because as I told you before the optional module XYZ is not installed....to install it..."

Regards,
Tim.

BTW, IMHO the correct answer to the OP question about whether the missing OsmGpsMap is a bug is: The distributed Gramps for OpenSuse 12.3 is Gramps 3.4.2. On the Download page you clicked on 'Advanced user only' and then should have read the warning:

"This should only be attempted by experienced users, and after you have backed up your Family Tree.

"The version of Gramps that has been included in your distribution will have been tested to work with the components in that distribution. If you try to install a different version of Gramps there is a possibility that the components needed for the new version of Gramps are not available for your distribution, or they are available, but don't work properly. You might not discover that there is a problem till you have already done some work with the new version of Gramps. "

So as you discovered, the latest version of Gramps did not work with the components in your distribution.


[1] As it isn't for info, calling it an info button seems perverse!  http://www.gramps-project.org/wiki/index.php?title=Gramps_4.0_Wiki_Manual_-_Main_Window#Warnings
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Options to suppress warning messages

Paul Franklin-5
> One possibility would be to pop up a dialogue on start-up telling the user
> what the problems are. I know people won't like a dialogue on startup that
> need to be dismissed, but at least this would make sure the user was
> informed about the problem.

I hate the idea of such a dialog, popping up every time
I start gramps.  I will get sick and tired of seeing it by the
time I have seen it three times, maybe twice.  Especially
if it concerns things I know I am not interested in and will
never be interested in.

I would /strongly/ argue that /if/ such a dialog exists,
the user be given a checkbox to "don't show this warning
message again" or words to that effect.

I don't think our users need to be forced to do anything.

We need to have a UI which copes with neophytes but
also allows more advanced users to do what they want.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Options to suppress warning messages

Nick Hall-6
On 28/09/13 16:10, Paul Franklin wrote:
One possibility would be to pop up a dialogue on start-up telling the user
> what the problems are. I know people won't like a dialogue on startup that
> need to be dismissed, but at least this would make sure the user was
> informed about the problem.
I hate the idea of such a dialog, popping up every time
I start gramps.  I will get sick and tired of seeing it by the
time I have seen it three times, maybe twice.  Especially
if it concerns things I know I am not interested in and will
never be interested in.

I would /strongly/ argue that /if/ such a dialog exists,
the user be given a checkbox to "don't show this warning
message again" or words to that effect.

I don't think our users need to be forced to do anything.

We need to have a UI which copes with neophytes but
also allows more advanced users to do what they want.

I'm not against changing the user interface.  I just didn't like the idea of a list of options to suppress warnings in the preferences.

We need to think about how we handle different types and severity of message.  Informational messages can be viewed via the "Info" button in the status bar and error messages trigger the error reporting wizard which seems acceptable.  The problem is with warning messages.

A dialog with a "don't show again" option sounds good to me.

Nick.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Options to suppress warning messages

Tim Lyons
Administrator
In reply to this post by Tim Lyons
Yes, OK, a warning every time you start Gramps may be a bit annoying!

Tim Lyons wrote
For example for spell check, you would click on 'Turn on spell check' and the response would be 'I'm sorry Dave, I can't do that because as I told you before the optional module XYZ is not installed....to install it..."
Having thought about it some more, I think that this may be a much better approach than the current mechanism.

I think we may have got things the wrong way round, by checking at start-up whether there is a problem. Then we need to have a long discussion about what to do at that point.

Why not change it round, so that you only check when you try to use the feature that relies on an optional module? That way, the user is told about the problem at exactly the right time.

- when you try to turn on spell-check, it tells you it can't,
- the Geography category of views is always shown, but if you select it when the OsmGpsMap module is missing selecting that category tells you that it is not available - there is a nice big display area to put an explanation of how to resolve the problem.
- similarly, the HTML view category is displayed, but selecting it displays an explanation of why it is not available,
- if you try the Image Metadata gramplet when "GExiv2 module not loaded. " you will get an explanation displayed of what to do in the gramplet area.
- If you select something else like a report that depends on a missing module, then when you click on the report you will get a dialogue explaining what to do.


I expect that you may complain that you don't want a view displayed in the Navigator [1] when it won't work. I suggest that a feature be implemented to allow a plugin to be deleted from the user's plugin directory (instead of just hidden which is problematic).

I suggest that the HTML view be made a plugin in the plugin repository, and then this would apply to Geography, HTML View and Image Metadata (as well as possibly some others).

Of course, when you deleted the plugin, it would then be available to be loaded by the Preferences 'Check now' dialogue - just as I suggested originally.

I am making this suggestion from the point of view of the user, rather than the developer. I appreciate that it sounds simpler for the developer for there to be a single API to report issues, but unfortunately this does not make it easy for the user, because he is told about the problem at the wrong time, and if the problem item is marked as hidden, there is no obvious way back for the user.

BTW, there is a discussion about 'module not present warnings' here [2]. Note that it explains that Mac an Windows AIO users cannot do anything directly.

Regards,
Tim.

[1] http://www.gramps-project.org/wiki/index.php?title=Gramps_4.0_Wiki_Manual_-_Main_Window#Navigator
[2] http://www.gramps-project.org/wiki/index.php?title=Gramps_4.0_Wiki_Manual_-_Main_Window#Module_not_loaded_warnings
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Options to suppress warning messages

John Ralls-2

On Sep 28, 2013, at 10:18 AM, Tim Lyons <[hidden email]> wrote:

>
> - when you try to turn on spell-check, it tells you it can't,
> - the Geography category of views is always shown, but if you select it when
> the OsmGpsMap module is missing selecting that category tells you that it is
> not available - there is a nice big display area to put an explanation of
> how to resolve the problem.
> - similarly, the HTML view category is displayed, but selecting it displays
> an explanation of why it is not available,
> - if you try the Image Metadata gramplet when "GExiv2 module not loaded. "
> you will get an explanation displayed of what to do in the gramplet area.
> - If you select something else like a report that depends on a missing
> module, then when you click on the report you will get a dialogue explaining
> what to do.
>
>
> I expect that you may complain that you don't want a view displayed in the
> Navigator [1] when it won't work. I suggest that a feature be implemented to
> allow a plugin to be deleted from the user's plugin directory (instead of
> just hidden which is problematic).

I rather like this, but with a toggle menu item in the View menu for "Hide/Show Disabled UI Features"
rather than something buried in the preferences.

Regards,
John Ralls


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Options to suppress warning messages

Tim Lyons
Administrator

On 28 Sep 2013, at 18:35, John Ralls wrote:

>
> On Sep 28, 2013, at 10:18 AM, Tim Lyons <[hidden email]> wrote:
>
>>
>> - when you try to turn on spell-check, it tells you it can't,
>> - the Geography category of views is always shown, but if you  
>> select it when
>> the OsmGpsMap module is missing selecting that category tells you  
>> that it is
>> not available - there is a nice big display area to put an  
>> explanation of
>> how to resolve the problem.
>> - similarly, the HTML view category is displayed, but selecting it  
>> displays
>> an explanation of why it is not available,
>> - if you try the Image Metadata gramplet when "GExiv2 module not  
>> loaded. "
>> you will get an explanation displayed of what to do in the gramplet  
>> area.
>> - If you select something else like a report that depends on a  
>> missing
>> module, then when you click on the report you will get a dialogue  
>> explaining
>> what to do.
>>
>>
>> I expect that you may complain that you don't want a view displayed  
>> in the
>> Navigator [1] when it won't work. I suggest that a feature be  
>> implemented to
>> allow a plugin to be deleted from the user's plugin directory  
>> (instead of
>> just hidden which is problematic).
>
> I rather like this, but with a toggle menu item in the View menu for  
> "Hide/Show Disabled UI Features"
> rather than something buried in the preferences.

Good, but I'd rather not 'Disable UI Features' at all. I would rather  
the view is either there or not. The problem is that for the user  
there are then two ways to get at a new view:
(1) Use the Preferences 'Check now' to load the add-on in the first  
place,
(2) Use the "Hide/Show Disabled UI Features".

I would prefer to completely remove the feature by deleting it from  
the user's local plugin directory. There could be a button on the  
message explaining about the missing feature, which deleted the plugin  
- no need to go to a preferences dialogue or the plugin manager.





But, if I can't persuade you on this, I quite like your suggestion,  
and anyway think it is much better that the current approaches.

(Note that for Spell checking and the exif gramplet, you wouldn't be  
able to Hide/Show, but the messages would only appear when you  
requested something, they would not be there all the time.)

I still want to move the HTML view to the gramps addon repository,  
anyway!

Regards,
Tim.



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Options to suppress warning messages

John Ralls-2

On Sep 28, 2013, at 10:50 AM, Tim Lyons <[hidden email]> wrote:

>
> On 28 Sep 2013, at 18:35, John Ralls wrote:
>
>>
>> On Sep 28, 2013, at 10:18 AM, Tim Lyons <[hidden email]> wrote:
>>
>>>
>>> - when you try to turn on spell-check, it tells you it can't,
>>> - the Geography category of views is always shown, but if you select it when
>>> the OsmGpsMap module is missing selecting that category tells you that it is
>>> not available - there is a nice big display area to put an explanation of
>>> how to resolve the problem.
>>> - similarly, the HTML view category is displayed, but selecting it displays
>>> an explanation of why it is not available,
>>> - if you try the Image Metadata gramplet when "GExiv2 module not loaded. "
>>> you will get an explanation displayed of what to do in the gramplet area.
>>> - If you select something else like a report that depends on a missing
>>> module, then when you click on the report you will get a dialogue explaining
>>> what to do.
>>>
>>>
>>> I expect that you may complain that you don't want a view displayed in the
>>> Navigator [1] when it won't work. I suggest that a feature be implemented to
>>> allow a plugin to be deleted from the user's plugin directory (instead of
>>> just hidden which is problematic).
>>
>> I rather like this, but with a toggle menu item in the View menu for "Hide/Show Disabled UI Features"
>> rather than something buried in the preferences.
>
> Good, but I'd rather not 'Disable UI Features' at all. I would rather the view is either there or not. The problem is that for the user there are then two ways to get at a new view:
> (1) Use the Preferences 'Check now' to load the add-on in the first place,
> (2) Use the "Hide/Show Disabled UI Features".
>
> I would prefer to completely remove the feature by deleting it from the user's local plugin directory. There could be a button on the message explaining about the missing feature, which deleted the plugin - no need to go to a preferences dialogue or the plugin manager.
>
>
>
>
>
> But, if I can't persuade you on this, I quite like your suggestion, and anyway think it is much better that the current approaches.
>
> (Note that for Spell checking and the exif gramplet, you wouldn't be able to Hide/Show, but the messages would only appear when you requested something, they would not be there all the time.)
>
> I still want to move the HTML view to the gramps addon repository, anyway!

Geography is a core plugin, and I don't think it should be relegated to addons. But it's going to be disabled if osm-gps-maps isn't correctly installed whether you like it or not. It can either be always hidden (the current situation) or made visible with a menu toggle, and it can display the "What you need to do to make me work" screen only if it's visible for the user to select it.

Gramplets can be hidden, and if they are, they don't get their gpr checks run and so don't trip the warning message. ISTM when a user downloads one, the gpr check should run and if it fails it can put up a message box explaining that it has failed its prereqs and will be hidden. The prereqs can be listed and the user instructed to install them if possible, then to unhide the gramplet, which will rerun the gpr check with the same results if it fails.

Enabling spell checking is a menu item, so its action should be to display the how-to-make-me-work message box if gtkspell3 isn't correctly installed. That's probably what you meant.

Regards,
John Ralls


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Options to suppress warning messages

Nick Hall-6
In reply to this post by Tim Lyons
On 28/09/13 18:18, Tim Lyons wrote:
> Why not change it round, so that you only check when you try to use the
> feature that relies on an optional module? That way, the user is told about
> the problem at exactly the right time.

I don't see a problem with that.  We only need to give a warning when
the user tries to use a feature.

> - when you try to turn on spell-check, it tells you it can't,

OK.

> - the Geography category of views is always shown, but if you select it when
> the OsmGpsMap module is missing selecting that category tells you that it is
> not available - there is a nice big display area to put an explanation of
> how to resolve the problem.

I don't think we really want an empty view.  We should check the views
when we build the navigation bar and give the appropriate feedback to
the user.

> - similarly, the HTML view category is displayed, but selecting it displays
> an explanation of why it is not available,

Again, if its not available, or if I decide I don't want to use it, then
we shouldn't display the view (or category if it is the only view in the
category).


> - if you try the Image Metadata gramplet when "GExiv2 module not loaded. "
> you will get an explanation displayed of what to do in the gramplet area.

You are trying to fix a problem that doesn't exist here.  If the GExiv2
module is not available the gramplet is not loaded.

The problem is that most users don't see the warning, and if they do it
is not easy for them to understand.


> - If you select something else like a report that depends on a missing
> module, then when you click on the report you will get a dialogue explaining
> what to do.

OK.

>
> I expect that you may complain that you don't want a view displayed in the
> Navigator [1] when it won't work. I suggest that a feature be implemented to
> allow a plugin to be deleted from the user's plugin directory (instead of
> just hidden which is problematic).

I don't think we should either delete or hide the plugin.

If the user fixes the problem the plugin will be loaded.  If not, the
user will continue to get warnings, unless they select a "don't show
again" option.


>
> I suggest that the HTML view be made a plugin in the plugin repository, and
> then this would apply to Geography, HTML View and Image Metadata (as well as
> possibly some others).

Geography should certainly remain as core.  I would prefer that the
Image Metadata gramplet to remain core functionality.

The HTML view was needed to render the Geography view.  I'm not sure if
it is used any more.

Nick.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Options to suppress warning messages

Nick Hall-6
In reply to this post by John Ralls-2
On 28/09/13 19:17, John Ralls wrote:
> Geography is a core plugin, and I don't think it should be relegated to addons. But it's going to be disabled if osm-gps-maps isn't correctly installed whether you like it or not. It can either be always hidden (the current situation) or made visible with a menu toggle, and it can display the "What you need to do to make me work" screen only if it's visible for the user to select it.
>
> Gramplets can be hidden, and if they are, they don't get their gpr checks run and so don't trip the warning message. ISTM when a user downloads one, the gpr check should run and if it fails it can put up a message box explaining that it has failed its prereqs and will be hidden. The prereqs can be listed and the user instructed to install them if possible, then to unhide the gramplet, which will rerun the gpr check with the same results if it fails.
>
> Enabling spell checking is a menu item, so its action should be to display the how-to-make-me-work message box if gtkspell3 isn't correctly installed. That's probably what you meant.

I agree with this.

If a plugin is missing a dependancy we need to display a clear, easy to
understand message in a dialog.

The user must then be given the option not to see the warning again, or
to hide then plugin (which will prevent subsequent warnings).  We could
hide then plugin by default.

The dialog should appear when Gramps attempts to load a plugin or enable
the functionality.

Nick.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Options to suppress warning messages

John Ralls-2
In reply to this post by Nick Hall-6

On Sep 28, 2013, at 12:53 PM, Nick Hall <[hidden email]> wrote:

>
> Geography should certainly remain as core.  I would prefer that the
> Image Metadata gramplet to remain core functionality.

Then perhaps you could refactor it to use exif.py [1], a much lighter-weight python-only parser that gexiv2.

Unless someone steps up soon to take over maintaining EditExifMetadata (which you moved out of core last spring), I think it should be dropped altogether.

>
> The HTML view was needed to render the Geography view.  I'm not sure if
> it is used any more.

It's not, since Serge converted Geography to osm-gps-map in 3.3.

Regards,
John Ralls

[1] https://github.com/ianare/exif-py


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Options to suppress warning messages

Nick Hall-6
On 28/09/13 21:18, John Ralls wrote:
> On Sep 28, 2013, at 12:53 PM, Nick Hall <[hidden email]> wrote:
>
>> Geography should certainly remain as core.  I would prefer that the
>> Image Metadata gramplet to remain core functionality.
> Then perhaps you could refactor it to use exif.py [1], a much lighter-weight python-only parser that gexiv2.

We did look at exif.py but it doesn't allow us to write tags.  Rob was
interested in editing the tags.

I have a couple of plans:

1. Update latitude/longitude fields in places from exif metadata.
2. Write media notes into exif comments.

I describe the content of photographs in Gramps notes.


>
> Unless someone steps up soon to take over maintaining EditExifMetadata (which you moved out of core last spring), I think it should be dropped altogether.

I'm not very interested in this.   Is there anything better than
gexiv2?  I think it still uses pyexiv2 which has been discontinued. I
don't mind having a look if people find it useful.


>
>> The HTML view was needed to render the Geography view.  I'm not sure if
>> it is used any more.
> It's not, since Serge converted Geography to osm-gps-map in 3.3.

I know its not used for the Geography view, but there is code to display
a web page which switches to the HTML view.  I seem to remember having
to provide this functionality when I did some work on the navigation
sidebar.

Nick.

>
> Regards,
> John Ralls
>
> [1] https://github.com/ianare/exif-py
>
>
>


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Options to suppress warning messages

John Ralls-2

On Sep 28, 2013, at 1:45 PM, Nick Hall <[hidden email]> wrote:

> On 28/09/13 21:18, John Ralls wrote:
>> On Sep 28, 2013, at 12:53 PM, Nick Hall <[hidden email]> wrote:
>>
>>> Geography should certainly remain as core.  I would prefer that the
>>> Image Metadata gramplet to remain core functionality.
>> Then perhaps you could refactor it to use exif.py [1], a much lighter-weight python-only parser that gexiv2.
>
> We did look at exif.py but it doesn't allow us to write tags.  Rob was interested in editing the tags.
>
> I have a couple of plans:
>
> 1. Update latitude/longitude fields in places from exif metadata.
> 2. Write media notes into exif comments.
>
> I describe the content of photographs in Gramps notes.

I understand that it doesn't write, but I also think that MetaDataViewer doesn't either. If you want to write notes into image metadata (XMP [1], not Exif [2], which is for the camera's data), that will indeed require either Exiv2 or python-xmp-toolkit [3], which is also dependent upon a (different) C++ library. It sure looks to me that that's more aligned with EditExifMetadata than MetaDataViewer; at the least it would require copying/moving/rewriting a bunch of functionality from the former to the latter.

Extracting Lat/Long from Exif to Gramps data fields can be done with exif.py.

>
>
>>
>> Unless someone steps up soon to take over maintaining EditExifMetadata (which you moved out of core last spring), I think it should be dropped altogether.
>
> I'm not very interested in this.   Is there anything better than gexiv2?  I think it still uses pyexiv2 which has been discontinued. I don't mind having a look if people find it useful.

Actually, gexiv2 is an improvement over pyexiv2. Both are bindings of the C++ exiv2 library; gexiv2 uses gobject-introspection to do the wrapping, while pyexiv2 uses Boost Python and scons.

>
>>
>>> The HTML view was needed to render the Geography view.  I'm not sure if
>>> it is used any more.
>> It's not, since Serge converted Geography to osm-gps-map in 3.3.
>
> I know its not used for the Geography view, but there is code to display a web page which switches to the HTML view.  I seem to remember having to provide this functionality when I did some work on the navigation sidebar.

You're thinking of gramps.gui.display.display_url, which is the only place that htmlview is called except for Doug Blank's webapp. That function will use htmlview if it's available and the default browser if it's not. Libmapservice *does* use display_url(), with the comment """Show the url in an external browser""".

Regards,
John Ralls

[1] http://en.wikipedia.org/wiki/Extensible_Metadata_Platform
[2] http://en.wikipedia.org/wiki/Exif
[3] http://code.google.com/p/python-xmp-toolkit/
------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
12
Loading...