Auto-resize status bar text

[qwertitis]

Current statusbar misses a resize grip and actually consists of several GtkStatusbars. This patch replaces the multitude of GtkStatusbars with one single instance, adding GtkFrames to that one instead.

[Steven Sheehy (steven-sheehy)]

Instead of creating the frames manually in the code, can't you create them in glade and set its attributes appropriately? I would prefer as much GUI declaration to be done in glade as possible.

On a side note, can you please assign defects to yourself and set to In Progress for defects you're submitting patches for in the future?

[qwertitis (qwertitis-deactivatedaccount)]

Glade-2 won't accept GtkStatusbar as a container, Glade-3 will do it (but won't show place-holders, so it's a fight against the gui). I couldn't get libglade to load the children of a GtkStatusbar though, it seems to just ignore them.

I'll set the attributes in future bugs.

[qwertitis (qwertitis-deactivatedaccount)]

glade-3 bug: (glade doesn't allow adding other to Statusbar)
http://bugzilla.gnome.org/show_bug.cgi?id=432996
libglade bug: (libglade doesn't add child widgets to statusbar)
http://bugzilla.gnome.org/show_bug.cgi?id=475213

[Steven Sheehy (steven-sheehy)]

Ok, instead of creating the GtkFrames inside the GtkStatusbar, what about if we simply replace the unnecessary GtkStatusbars with GtkFrames? So we'll have the main statusbar and the frames inside the original HBox. It's a little redundant since GtkStatusbar is an HBox, but it's better than creating them in the code.

[qwertitis (qwertitis-deactivatedaccount)]

The biggest problem with that solution is probably theme compatibility, since the GtkFrames still need that special style property, I'd guess. One can only hope that when that glade bug is fixed, they take care of setting this up properly too.

I'm also uncertain whether there are themes that require those GtkFrames to be children of GtkStatusbar or not.

A practical pitfall is that GtkStatusbar doesn't use its text contents to calculate requested width. That's the reason for that original, kinda-but-not-really-working hack, that I just noticed I didn't completely remove. This limitation causes the statusbar to be either very thin, or filling the whole surface. Using the method you described, I don't think it's possible to mimic the current layout exactly. There will be something funny going on near that final GtkStatusbar.

[Steven Sheehy (steven-sheehy)]

I ended up rewriting the status bar to be a series of GtkLabels. We miss out on the shadow and the resize grip, but we don't have to deal with the GtkStatusBar bugs and we get proper label auto-resizing. I also added icons and tool tips so users can actually tell what those numbers down there mean (I had to look some of them up myself).

[macio (s-maciek)]

Anyway this bug still does exist in :
LinuxDC++ version: 1.0.3+bzr
Core version: 0.75
Or was it fixed and I have just missed the solution ? I really would like to find out how to stop auto-resizing text window and users window each time when I launch linuxdcpp.

[Razzloss (razzloss)]

Statusbar bug? It should be fixed. Make sure you're running the latest revision (the version information you gave doesn't really help that much, it should specify the bzr revision used to build your client. I've been meaning to add the bzr revision to at least console output, but haven't got that far yet...)

Though your comment about text window suggests you're not commenting on the right bug. Maybe bug #354979 is something you're after? (apparently that isn't fixed yet)

--RZ