OpenCPN Bug Report / Feature Request Tracker

[jpiebrig]

Hi,

Sorry, I haven't seen that before, that's quite enough. Thanks both to you.

Jean-Pierre

[Netsurfer]

@Dave + all

Since there have been no protest yet , I suppose that you (slightly) agree with the configuration of the tracker so far.

Flyspray also offers the option to set up different categories (for each project separately). At the moment there is only one category (Backend / Core) for each project.

What do you think about using (additional) categories?
Does it make sense in your opinion?
If so, what categories would you propose?

Just as an example: I am personally of the opinion that there is some room left for further improvements of the Windows installer. As it does not belong to the Backend/ Core of OCPN it might have its own category.

Another point to think over or to discuss is the question if it would be better or has any advantages, if we use a separate project just for Feature Requests?

IMHO doing so has some great advantages like

• version (and build) independent
• only one task type needed
• individual fields for the task list
• easier to maintain
• more clarity for the user

Please let me know what you think about it.

Thanks,

Gunther

[nohal]

Originally Posted by Netsurfer

Since there have been no protest yet , I suppose that you (slightly) agree with the configuration of the tracker so far.

Gunther,
thanks a lot for taking care of it

Flyspray also offers the option to set up different categories (for each project separately). At the moment there is only one category (Backend / Core) for each project.

What do you think about using (additional) categories?
Does it make sense in your opinion?
If so, what categories would you propose?

Definitely welcome in my eyes - The first two i can imagine is Installer and Rasterization rules
Additionally - Would it be possible to create a separate task type for code patches? I think it would help the people contributing code get some attention...

Another point to think over or to discuss is the question if it would be better or has any advantages, if we use a separate project just for Feature Requests?

IMHO doing so has some great advantages like

• version (and build) independent
• only one task type needed
• individual fields for the task list
• easier to maintain
• more clarity for the user

Please let me know what you think about it.

You know I'm not a big fan of many different projects (especially if they can't be grouped)

Pavel

[Netsurfer]

Pavel,

Originally Posted by nohal

Additionally - Would it be possible to create a separate task type for code patches? I think it would help the people contributing code get some attention...

Yes, this would be possible. Can you just explain it a little more for my understanding, please?

You know I'm not a big fan of many different projects (especially if they can't be grouped)

I know , but moving all Feature Requests to their separate project has IMHO many advantages. Even for contributors it is easier to recognize where to put their request. And no struggle with any version numbers and specific categories.

Gunther

[nohal]

Originally Posted by Netsurfer

Yes, this would be possible. Can you just explain it a little more for my understanding, please?

Gunther,
this task type would be used for code contribution - eg. anchor watch, route manager, celestial navigation patch, etc. would use it when submitted - Most of the "Patches" tracker on sourceforge would fall in this category. Letting people submit contributions as feature requests could not get them the attention they deserve...

Pavel

[Netsurfer]

Pavel,

Originally Posted by nohal

this task type would be used for code contribution - eg. anchor watch, route manager, celestial navigation patch, etc. would use it when submitted ...

I see.
So do you think such a task type would also make sense for each plugin?

And do you agree that it is unnecessary for the 'OpenCPN - stable' project?

Gunther

[sinbad7]

Dave..

Regarding Littlechay's problem initiating an 'extended' .html command with an # anchor: file:///C:/NavWeb/SGNotes.html#CobblersCove

Could there be a possibility that your 'Additional information' feature in OCPN only accepts links ending with htm or html? The above command works perfectly when executed outside OCPN in my Vista Home version.

Tore

It is not a general OpenCPN problem as this feature works OK in Linux/OpenCPN, while in windows (XP) the parser silently drops the html anchor. It could be an wx/win implementation problem. Please enter this as a bug in the tracker.

Thomas

[cagney]

Originally Posted by sinbad7

It is not a general OpenCPN problem as this feature works OK in Linux/OpenCPN, while in windows (XP) the parser silently drops the html anchor. It could be an wx/win implementation problem. Please enter this as a bug in the tracker.

Thomas

Tore

This thread is not the "tracker". I have entered the issue.
Have a look here FS#646 : Waypoint with "Additional information", html anchor problem.

While you are there have a look around at the different issues!

Thomas