GNOME Bugzilla – Bug 408929
Allow selection of printed columns in Gantt
Last modified: 2021-06-09 20:37:41 UTC
Please display task name in gannt diagram Printing should print current visible columns (e.g. Slack) not only name/duration Make it more usable for data entry without mouse: ctrl+i -> popup task properties with ok/cancel buttons; focust on name field.
*** Bug 567894 has been marked as a duplicate of this bug. ***
(In reply to comment #0) > Please display task name in gannt diagram > > Printing should print current visible columns (e.g. Slack) not only > name/duration I've changed summary to a more explicit one. > Make it more usable for data entry without mouse: ctrl+i -> popup task > properties with ok/cancel buttons; focust on name field. This part is being handled in another report, bug 596966.
*** Bug 609780 has been marked as a duplicate of this bug. ***
This has been requested many times (see the above comments for duplicates) and could indeed be useful. I'm marking it as confirmed.
I'm starting to look into this.
Note that we want to keep consistency between the UI and exported HTML so it'd be nice to have a way to keep those in sync. We use XSLT to create the HTML export.
Created attachment 200589 [details] [review] Bug fix patch The fix is to one file only. I tested the patch out on the latest planner code using git clone. The selected visible columns are now included in the print out. I have not looked at HTML yet.
(In reply to comment #7) > The fix is to one file only. I tested the patch out on the latest planner code > using git clone. Thank you. Can you make a local commit in your clone and then run git format-patch HEAD^ to generate a patch in a more handy format? > I have not looked at HTML yet. If you do, it's great that you make separate patches and attach both to this report.
Created attachment 200747 [details] [review] Git Patch File I performed local commit, and ran "git format-patch -1 <commit>" to generate the attached patch file.
I've taken a look at HTML, and it's not a trivial change (depending on what is meant by "consistency") It appears that currently the html export and printing are not really linked in any way. The HTML export prints all three views regardless of what is selected on the "select views" tab of the Print dialog. Also, the columns are all hard-coded. Changing visibility of any columns on main planner have no bearing on html. So firstly, I'd like to understand what is meant by keeping consistency... perhaps there's something I'm missing. If by this you mean that html processing needs to be generally improved so that the export reflects how the user has setup their project, in the same way as gantt and tasks do for printing now (if my patch is applied), then may I suggest that we consider this as a separate bug? This change goes beyond the original scope of this bug. Let me know your thoughts...
Alexandre - how's the review of the patch going?
FWIW this reported in Debian as: http://bugs.debian.org/525040
BTW - I've been working with this patch for 8 months now, and it's working well.
Ok, let me clarify what consistency means and I think it could be achieved. When adding or removing new columns to the UI, they should of course be added to or removed from the printed output, but the same should be applied to the HTML export. As you said, we currently use a monolithic system to generate HTML with a single XSLT operation. We need to make it more modular and have a way to enable/disable parts of the HTML output. Currently I'm pretty sure the printed output and HTML export have the exact same columns and info. I think the best way to handle this situation is to open a new bug report for HTML, add it as a blocker for this one, and then merge patches for both bug reports in master so that the features move alongside. Please, Paul, do create the new report.
bug 680587 raised to cover HTML export.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/World/planner/-/issues/127.