GNOME Bugzilla – Bug 128983
Gantt bar height doesn't match treeview row height
Last modified: 2008-01-06 09:21:05 UTC
Hello! If I have many tasks and they are not located in a window that does not switch on sÓrolling windows and some tasks are not accessible to me in Gantt Chat. Also in Gantt Chat do not coincide which at the left tasks (are not combined) with tasks which on the diagram. If I shall make a font less that everything is all right, but it seems not correctly. Thanks.
Hm, I've only heard of one report of this before, and not being able to debug it. It works for me no matter what font or font size I use, and there is code to handle that. If you could help debugging this, it would help a lot.
Created attachment 22455 [details] simple bug
Hello! How i can debugging this? I also attach png with bug. I use in task name both Russian Cyrillic (KOI8-R) and English. Thanks.
If you are familiar with gdb, could you please try and see if the function gantt_view_update_row_and_header_height (PlannerView *view) is called in planner-gantt-view.c?
Also, which version of GTK+ and which font/font size. And which version of MrProject? Did you try 0.10, or Planner 0.11?
Ok. I try debugging. I use gtk-2.2.4_1 font Bitstream Vera Sans and font size 9. This bug in MrProject 0.10 and Planner 0.11. May be font some font replace Bitstream Vera because it has no locale koi8-r but everywhere writes in Russian.
Sorry! gtk+ = 2.0.3
> May be font some font replace Bitstream Vera because it has no locale > koi8-r but everywhere writes in Russian. The code is supposed to go through the cells in the table to the left and see which is the heighest, and then use that value for the row height to the right... so it should work no matter what fonts. I'm interested in seeing wether that code is called at all in your case (the function mentioned above). You could try just inserting print like this in that function: row_height = MAX (row_height, height); g_print ("height: %d\n", height); If you have the source code and can build from that. It would be great to be able to nail this bug.
Ok. Give me time please. Thanks.
So. Then i open planner in console print height: 21 height: 21 Then i open my file with bad overlapping print also height: 21 height: 21
Strange... the real size seems to be 22 from what I can see from the screenshot. I wonder why it's not reported as such.
Whether the rounding off is possible somewhere? I try height + 1.
I suspect that this might be some bug in gtk+ 2.0.x that was fixed in 2.2.x...
I try + 1 and in my file all ok, but in another not all good. Ok. I try install gtk+ 2.2.x but not understood I have intsall gtk-2.2.4_1 but then i compile i see glib-2.0 >= 2.0.4 gobject-2.0 gmodule-2.0 gtk+-2.0 >= 2.0.3 libgnomecanvas-2.0 >= 2.0.1 libgnomeui-2.0 >= 2.0.1 libglade-2.0 >= 2.0.0 libbonoboui-2.0 >= 2.0.0 libgnomeprintui-2.2 >= 2.1.9 gnome-vfs-2.0 >= 2.0.2 gtk and gtk+ different things? I not found what i have installed gtk+.
How did you install? Into a different prefix? If so, you need to set the env.variables: export PKG_CONFIG_PATH=(your prefix)/lib/pkgconfig:$PKG_CONFIG_PATH export LD_LIBRARY_PATH=(your prefix)/lib:$LD_LIBRARY_PATH before running ./configure for planner.
There is one other thing you could try: Add this in planner-task-tree.c, around line 1568: switch (column) { case COL_NAME: cell = gtk_cell_renderer_text_new (); g_object_set (cell, "editable", TRUE, NULL); add this ---> gtk_cell_renderer_text_set_fixed_height_from_font (GTK_CELL_RENDERER_TEXT (cell), 1); and see if it helps.
This help! But now i not see name task in left side. This name task empty, but then i double click on task name only then i see it.
Thanks, good to know. I don't know exactly what the right way to fix this is though.
May be gtk_cell_renderer_text_set_fixed_height_from_font right way but then a new problem. The name of the task in the left part is not displayed.
It's not the right way, it could work as an ugly hack. Since I've only seen this bug on gtk 2.0.x and the current version is 2.2, with 2.4 coming up real soon, I'm not sure I want to put in cludges like that :/. We would need to add code that updates the row height on style changes and make sure that it doesn't break anything else.
Tnx. Waiting for the sun....
Can you still reproduce this bug?
*** Bug 168340 has been marked as a duplicate of this bug. ***
I can still see this bug on my Ubuntu Breezy laptop.
Created attachment 55399 [details] misaligned tasks & gantt bars
I see similar behavior with SuSE 10.0 (planner 0.13, gtk 2.8, gnome 2.12). Screenshot attached above ("misaligned tasks & gantt bars").
Created attachment 56542 [details] Reproduced Debian SID / XFCE 4.2.0 I do have the same problem but only from few days (it worked well before). Unfortunatly, I did not notice what action caused the problem, but I think that it was after an upgrade. Here are some information about my system: - Kernel 2.6.12-1-686-smp - X.org 6.8.2 - XFCE 4.2.0 - GTK libraries installed => See next attachment I'll be pleased to provide any further required information
Created attachment 56543 [details] GTK libs installed Linked to comment 27 and attachment 56542 [details] List of GTK libs installed
I still have the issue with the following tests: - Using KDE instead of XFCE - Using several window managers in XFCE - Using several themes in XFCE - Using several fonts family (sans, serif and monospaced types, even cursive) and font size.
I also tryed to change the default locale: - en_US.ISO-8859-15 - en_US.UTF-8 - en_GB.ISO-8859-1 Is there any other tests I can do ?
I've done some investigation in my company because we are several that use Planner on a Debian SID box. I was the only one with the problem 2 weeks ago (I'm the one who make most upgrades), and now we all have it. Last Friday, I also installed a windoz version of Planner using the last GTK for windowz, and I also had the problem... I clearly suspect a problem with newer version of gtk. BTW, I just relaised that I did not gave my Planner version: 0.13
I was able to reproduce this on Win Planner only if I had GTK 2.8.9 installed. Once I reinstalled GTK 2.6.10 (from the gaim.sf.net site), the problem no longer happens.
Created attachment 62483 [details] [review] Initial patch fix This is my initial attempt at the fix. It worked on my system, but please verify on other systems.
Could you try that measurment code in place of the old one (in style_set)? We shouldn't do that on every expose event, just when first setting up the tree view.
I've tried that before but it was inconsistent. That function didn't seem to be called everytime and sometimes the tree path was considered invalid because the tree was not exposed yet.
How about in the realize callback then (maybe connected with g_signal_connect_after)? Using expose here is simply not the right way.
I tried using the realize event but it doesn't work. I will also have to make a patch for the resource usage later. It seems like the background area is not available in normal cases. I am open for other suggestions on how to fix it this in a better way but the expose seems to be the only solution at the moment. Maybe someone in GTK can give us a help?
If we end up having to use the expose event, at least we need to make it not called for -every- expose event, just the first. Expose is called each time something needs to be drawn on the widget.
Created attachment 62561 [details] [review] Include focus line width Could you try this patch?
It works nicely. I have created also followin this patch the solution for the resource usage view gantt graph also. I am going to attach the patch to this bug also.
Created attachment 62715 [details] [review] Align correctly tree view and canvas in resource usage view This is the cut and paste version of the patch by richard for the alignment of Tree View and canvas widget in gantt view. It solves the problem in the resource usage view.
Comment on attachment 62715 [details] [review] Align correctly tree view and canvas in resource usage view Index: src/planner-usage-view.c =================================================================== RCS file: /cvs/gnome/planner/src/planner-usage-view.c,v retrieving revision 1.4 diff -u -b -B -p -r1.4 planner-usage-view.c --- src/planner-usage-view.c 23 Apr 2005 10:33:10 -0000 1.4 +++ src/planner-usage-view.c 4 Apr 2006 08:17:01 -0000 @@ -405,6 +405,10 @@ usage_view_create_widget (PlannerView *v chart = planner_usage_chart_new_with_model (GTK_TREE_MODEL (model)); priv->chart = PLANNER_USAGE_CHART (chart); + + planner_usage_chart_set_view (PLANNER_USAGE_CHART (priv->chart), + PLANNER_USAGE_TREE (priv->tree)); + sw = gtk_scrolled_window_new (hadj, vadj); gtk_scrolled_window_set_policy (GTK_SCROLLED_WINDOW (sw), GTK_POLICY_ALWAYS, @@ -483,6 +487,7 @@ usage_view_update_row_and_header_height { GtkTreeView *tv; PlannerUsageChart *chart; + gint focus_line_width; gint row_height; gint header_height; gint height; @@ -498,6 +503,10 @@ usage_view_update_row_and_header_height row_height = 0; header_height = 0; + gtk_widget_style_get (GTK_WIDGET (tv), + "focus-line-width", &focus_line_width, + NULL);
Created attachment 62717 [details] [review] Align correctly tree view and canvas in resource usage view
Richard's patch only works with GTK 2.7+. It misaligns on GTK 2.6 because that's prior to GTK's changes. I still think the only correct way of getting the correct height is by querying the background area of the cell. Do we have any contact in GTK-land to ask if there is a better way of getting that height?
So let's have conditional code then, adding the focus width for 2.8 and not for 2.6 (I would personally just require 2.8 since 2.6 is getting kind of old).
Looking at distrowatch.com main distributions the newer versions of distros using GTK+ 2.6 are: * Ubuntu Hoary from 2005/04/08 uses gtk 2.6.4 * SuSE 9.3 from from 2005/04/15 uses gtk 2.6.4 * Mandriva Linux from 2005/04/14 uses gtk 2.6.4 * Fedora Core 4 from 2005/06/13 uses gtk 2.6.7 * MEPIS Linux 3.3.1 from 2005/05/12 uses 2.6.4 * Damn Small Linux uses gtk 1.2.10 in the newer version * Debian GNU/Linux 3.1 from 2005/06/06 uses gtk 2.6.4 * RHEL 4 from 2005/02/15 uses gtk+ 2.4.13 Except from Debian, Damn Small Linux and RHEL all the other distributions have newer versions with gtk+ 2.8 you they can benefit from Richard patch. Debian Sarge I found is the bigger problem because it will be the stable distribution for a long time (1 year more at least).
I can ask Kris (the treeview maintainer :) when he gets back from his vacation. The "real" way would be to actually get the real height for each and every row and match them that way, instead of cheating like we do now. That will break the whole gantt view code though since it's based on the concept of fixed row height (we could btw use the fixed height mode now that it exists in the treeview, but it's not really relevant here). I would just do what I suggested: add the new lines conditionally if building with 2.8. Alternatively, if someone has a lot of spare time, try to find out if there is a way to get the height through the background area without doing it in the expose callback (that is simply not an option). It's not like this code has to be perfect, the old code was a hack, and we are abusing the treeview already.
*** Bug 329278 has been marked as a duplicate of this bug. ***
*** Bug 303568 has been marked as a duplicate of this bug. ***
Created attachment 62890 [details] [review] Single expose call after project load This patch only uses the expose callback once. If this is ok, we can apply to the resource usage as well.
Thanks, let's get this committed then. I still think that using the expose callback for this is completely wrong, but I guess I don't really care that much anymore. If I had the planner source checked out, I would have tried to get it working for example by syncing the height initially just after setting the model (manually), or basically any other way than using the expose event :)
*** Bug 337583 has been marked as a duplicate of this bug. ***
Created attachment 62979 [details] [review] Single expose call after project load (both Gantt and Usage views) Patch now includes resource usage view.
Well, there is a problem with my patch. It doesn't help when you start a new project because I hooked the single expose to the project loaded callback. This doesn't happen when working on a brand new project. Any ideas?
I tried putting a call to gantt_view_update_row_height (view); into gantt_view_insert_task_cb and gantt_view_insert_tasks_cb. This seems to solve the problem of a new project when adding tasks individually, but for some reason doesn't seem to fix the problem when using the 'insert tasks' dialog... Probably because by the time the dialog returns control to the callback function its too late. Don't have time to look into it further tonight, though.
Created attachment 64343 [details] [review] Single expose call after project load (both Gantt and Usage views with task/resource inserted callbacks) Patch to take care of the inserted task/resource callbacks on both Gantt and Resource Usage views. This seems to have eliminated the problem with a brand new project. Please give it a try.
*** Bug 319068 has been marked as a duplicate of this bug. ***
Created attachment 64461 [details] [review] Should fix something, if not all. Hi all, I'm not sure the attached patch solves this problem, but it seem to be related. The probelm it surely solves is some misalignment that occurs because the current row height calculation doesn't take into account the few pixels that might separate the rows. I gave a look at GtkTreeView sources, and the row height is calculated in a similar manner as this patch does. To test the patch, edit your ~/.gtkrc-2.0 so that it contains these lines (100 is a value that immediately shows the problem, but it also occurs with any value greater than 0): ====================== style "test" { GtkTreeView::vertical_separator = 100 } class "GtkWidget" style "test" ====================== Try this style first and after applying the patch, and you'll notice the difference. So please apply :-)
Mardy, The problem with your patch is that it is specific to GTK 2.7+. It fails on systems with GTK 2.6 because the calculation is different. Give a try on my patch http://bugzilla.gnome.org/attachment.cgi?id=64343 as it uses the background area which includes all the padding from styles and it should isolate the differences in GTK and from possible future changes.
Committed this patch with one minor change.. I moved the g_signal_connect_after in usage_view_project_loaded_cb down a bit further in the function. See the FIXME comment in that function for more info, but the bottom line is that the handler_disconnect in usage_view_expose_cb was throwing warnings. Moving the connect_after call fixes that. Nice work Francisco! We finally put this one to bed (at least until we find a better way, but that's a job for another day).
*** Bug 340633 has been marked as a duplicate of this bug. ***
*** Bug 341003 has been marked as a duplicate of this bug. ***
*** Bug 341494 has been marked as a duplicate of this bug. ***
FYI, patch attachment 64461 [details] [review] successfuly tested on Debian SID using current sources: wget -O ../patch-planner.patch http://bugzilla.gnome.org/attachment.cgi?id=64461 sudo apt-get source planner sudo patch -d planner-0.13/src < ../patch-planner.patch cd planner-0.13 sudo dpkg-buildpackage -b sudo dpkg -i ../planner_0.13-7_i386.deb I do not have the bug anymore. Thanks!
*** Bug 343594 has been marked as a duplicate of this bug. ***
*** Bug 343871 has been marked as a duplicate of this bug. ***
*** Bug 344002 has been marked as a duplicate of this bug. ***
*** Bug 344025 has been marked as a duplicate of this bug. ***
Created attachment 66925 [details] [review] Fix the same issue in resource usage view Sorry if there's a separate bug - can't find it. Exactly the same code in resource usage view as in task view (called ttable in filenames), exactly the same patch seems to fix it.
Why are we still creating patches on an issue that's already solved for 0.14? Are these patches for 0.13 version? If so, the newest patches only work on certain versions of GTK.
*** Bug 341512 has been marked as a duplicate of this bug. ***
*** Bug 341335 has been marked as a duplicate of this bug. ***