After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 128983 - Gantt bar height doesn't match treeview row height
Gantt bar height doesn't match treeview row height
Status: RESOLVED FIXED
Product: planner
Classification: Other
Component: General
unspecified
Other FreeBSD
: Normal normal
: 1.0
Assigned To: planner-maint
planner-maint
: 168340 303568 319068 329278 337583 340633 341003 341335 341494 341512 343594 343871 344002 344025 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-12-10 14:38 UTC by Virgo
Modified: 2008-01-06 09:21 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
simple bug (84.01 KB, image/png)
2003-12-15 10:11 UTC, Virgo
  Details
misaligned tasks & gantt bars (73.82 KB, image/jpeg)
2005-11-30 00:54 UTC, Reece Hart
  Details
Reproduced Debian SID / XFCE 4.2.0 (75.87 KB, image/png)
2005-12-30 10:38 UTC, Julien BETI
  Details
GTK libs installed (3.98 KB, text/plain)
2005-12-30 10:40 UTC, Julien BETI
  Details
Initial patch fix (2.49 KB, patch)
2006-03-31 20:57 UTC, fmoraes
none Details | Review
Include focus line width (1.16 KB, patch)
2006-04-01 19:34 UTC, Richard Hult
none Details | Review
Align correctly tree view and canvas in resource usage view (587 bytes, patch)
2006-04-04 08:13 UTC, Alvaro del Castillo
none Details | Review
Align correctly tree view and canvas in resource usage view (1.56 KB, patch)
2006-04-04 08:24 UTC, Alvaro del Castillo
none Details | Review
Single expose call after project load (2.77 KB, patch)
2006-04-07 02:27 UTC, fmoraes
none Details | Review
Single expose call after project load (both Gantt and Usage views) (5.75 KB, patch)
2006-04-08 14:25 UTC, fmoraes
none Details | Review
Single expose call after project load (both Gantt and Usage views with task/resource inserted callbacks) (7.44 KB, patch)
2006-04-26 19:30 UTC, fmoraes
none Details | Review
Should fix something, if not all. (1012 bytes, patch)
2006-04-28 10:55 UTC, Mardy
none Details | Review
Fix the same issue in resource usage view (918 bytes, patch)
2006-06-07 18:45 UTC, David H
none Details | Review

Description Virgo 2003-12-10 14:38:37 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.
Comment 1 Richard Hult 2003-12-13 22:54:52 UTC
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.
Comment 2 Virgo 2003-12-15 10:11:48 UTC
Created attachment 22455 [details]
simple bug
Comment 3 Virgo 2003-12-15 10:18:07 UTC
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.
Comment 4 Richard Hult 2003-12-15 13:27:00 UTC
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?


Comment 5 Richard Hult 2003-12-15 13:53:33 UTC
Also, which version of GTK+ and which font/font size. And which
version of MrProject? Did you try 0.10, or Planner 0.11?
Comment 6 Virgo 2003-12-15 14:08:27 UTC
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.
Comment 7 Virgo 2003-12-15 14:10:29 UTC
Sorry!
gtk+ = 2.0.3
Comment 8 Richard Hult 2003-12-15 14:17:13 UTC
> 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.
Comment 9 Virgo 2003-12-15 14:30:58 UTC
Ok. Give me time please.
Thanks.
Comment 10 Virgo 2003-12-15 14:58:43 UTC
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
Comment 11 Richard Hult 2003-12-15 15:24:27 UTC
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.
Comment 12 Virgo 2003-12-15 15:33:30 UTC
Whether the rounding off is possible somewhere?
I try height + 1.
Comment 13 Richard Hult 2003-12-15 15:47:59 UTC
I suspect that this might be some bug in gtk+ 2.0.x that was fixed in
2.2.x...
Comment 14 Virgo 2003-12-15 16:03:58 UTC
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+.

Comment 15 Richard Hult 2003-12-15 16:08:25 UTC
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.
Comment 16 Richard Hult 2003-12-15 16:31:54 UTC
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.
Comment 17 Virgo 2003-12-16 08:12:17 UTC
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.
Comment 18 Richard Hult 2003-12-16 23:26:53 UTC
Thanks, good to know. I don't know exactly what the right way to fix
this is though. 
Comment 19 Virgo 2003-12-17 07:40:22 UTC
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.
Comment 20 Richard Hult 2003-12-17 10:23:29 UTC
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.
Comment 21 Virgo 2003-12-17 11:34:33 UTC
Tnx. Waiting for the sun....
Comment 22 Richard Hult 2005-02-18 08:57:21 UTC
Can you still reproduce this bug?
Comment 23 Richard Hult 2005-02-24 08:34:57 UTC
*** Bug 168340 has been marked as a duplicate of this bug. ***
Comment 24 Håvard Tørring 2005-11-22 08:00:12 UTC
I can still see this bug on my Ubuntu Breezy laptop.
Comment 25 Reece Hart 2005-11-30 00:54:52 UTC
Created attachment 55399 [details]
misaligned tasks & gantt bars
Comment 26 Reece Hart 2005-11-30 00:55:50 UTC
I see similar behavior with SuSE 10.0 (planner 0.13, gtk 2.8, gnome 2.12). 
Screenshot attached above ("misaligned tasks & gantt bars").
Comment 27 Julien BETI 2005-12-30 10:38:54 UTC
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
Comment 28 Julien BETI 2005-12-30 10:40:39 UTC
Created attachment 56543 [details]
GTK libs installed

Linked to comment 27 and attachment 56542 [details]
List of GTK libs installed
Comment 29 Julien BETI 2006-01-11 15:12:10 UTC
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.
Comment 30 Julien BETI 2006-01-11 15:14:46 UTC
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 ?
Comment 31 Julien BETI 2006-01-11 16:34:34 UTC
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
Comment 32 fmoraes 2006-02-22 02:38:13 UTC
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.
Comment 33 fmoraes 2006-03-31 20:57:24 UTC
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.
Comment 34 Richard Hult 2006-03-31 21:39:12 UTC
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.
Comment 35 fmoraes 2006-03-31 23:20:15 UTC
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.
Comment 36 Richard Hult 2006-04-01 06:43:40 UTC
How about in the realize callback then (maybe connected with g_signal_connect_after)? Using expose here is simply not the right way.
Comment 37 fmoraes 2006-04-01 16:55:29 UTC
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?
Comment 38 Richard Hult 2006-04-01 19:16:42 UTC
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.
Comment 39 Richard Hult 2006-04-01 19:34:12 UTC
Created attachment 62561 [details] [review]
Include focus line width

Could you try this patch?
Comment 40 Alvaro del Castillo 2006-04-04 08:10:43 UTC
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.
Comment 41 Alvaro del Castillo 2006-04-04 08:13:47 UTC
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 42 Alvaro del Castillo 2006-04-04 08:21:33 UTC
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);
Comment 43 Alvaro del Castillo 2006-04-04 08:24:34 UTC
Created attachment 62717 [details] [review]
Align correctly tree view and canvas in resource usage view
Comment 44 fmoraes 2006-04-04 13:54:48 UTC
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?
Comment 45 Richard Hult 2006-04-04 14:03:30 UTC
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).

Comment 46 Alvaro del Castillo 2006-04-04 14:40:42 UTC
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).
Comment 47 Richard Hult 2006-04-04 20:06:12 UTC
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.

Comment 48 fmoraes 2006-04-05 00:21:00 UTC
*** Bug 329278 has been marked as a duplicate of this bug. ***
Comment 49 Kurt Maute 2006-04-06 13:14:07 UTC
*** Bug 303568 has been marked as a duplicate of this bug. ***
Comment 50 fmoraes 2006-04-07 02:27:50 UTC
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.
Comment 51 Richard Hult 2006-04-08 08:04:20 UTC
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 :)
Comment 52 Kurt Maute 2006-04-08 12:14:10 UTC
*** Bug 337583 has been marked as a duplicate of this bug. ***
Comment 53 fmoraes 2006-04-08 14:25:01 UTC
Created attachment 62979 [details] [review]
Single expose call after project load (both Gantt and Usage views)

Patch now includes resource usage view.
Comment 54 fmoraes 2006-04-09 21:14:36 UTC
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?
Comment 55 Kurt Maute 2006-04-12 01:26:35 UTC
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.
Comment 56 fmoraes 2006-04-26 19:30:28 UTC
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.
Comment 57 fmoraes 2006-04-27 22:06:13 UTC
*** Bug 319068 has been marked as a duplicate of this bug. ***
Comment 58 Mardy 2006-04-28 10:55:05 UTC
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 :-)
Comment 59 fmoraes 2006-04-28 14:23:58 UTC
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.
Comment 60 Kurt Maute 2006-04-29 14:05:10 UTC
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).
Comment 61 Kurt Maute 2006-05-04 14:23:01 UTC
*** Bug 340633 has been marked as a duplicate of this bug. ***
Comment 62 Kurt Maute 2006-05-08 12:46:20 UTC
*** Bug 341003 has been marked as a duplicate of this bug. ***
Comment 63 Kurt Maute 2006-05-14 12:38:56 UTC
*** Bug 341494 has been marked as a duplicate of this bug. ***
Comment 64 Julien BETI 2006-05-24 12:01:03 UTC
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!
Comment 65 Elijah Newren 2006-06-01 16:25:31 UTC
*** Bug 343594 has been marked as a duplicate of this bug. ***
Comment 66 Elijah Newren 2006-06-05 16:11:46 UTC
*** Bug 343871 has been marked as a duplicate of this bug. ***
Comment 67 Kurt Maute 2006-06-06 13:05:15 UTC
*** Bug 344002 has been marked as a duplicate of this bug. ***
Comment 68 Elijah Newren 2006-06-06 18:26:22 UTC
*** Bug 344025 has been marked as a duplicate of this bug. ***
Comment 69 David H 2006-06-07 18:45:40 UTC
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.
Comment 70 fmoraes 2006-06-07 18:55:04 UTC
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.
Comment 71 Maurice van der Pot 2008-01-06 09:20:14 UTC
*** Bug 341512 has been marked as a duplicate of this bug. ***
Comment 72 Maurice van der Pot 2008-01-06 09:21:05 UTC
*** Bug 341335 has been marked as a duplicate of this bug. ***