GNOME Bugzilla – Bug 338289
The "new list" button/widget is ugly and weird
Last modified: 2008-10-22 19:14:20 UTC
It would be nice if evolution instead would use the button firefox uses for browsing back and forward in the history.
johan, can you please elaborate a bit? i don't get at all what you are talking about. which "new list" button? where?
Created attachment 63376 [details] The "new" widget in evolution
Created attachment 63377 [details] The firefox history browsing widget.
ok. but not *instead* of the new button, no way. this would break the workflow of thousands of people. so where's your point? evo should provide a history to go back and forth? what would you expect of that, where is the advantage towards now?
Created attachment 63454 [details] A mockup of what the new button could look like
I am not proposing to change the functionality of the new button. I'm simply suggesting to change the appearance of the new button to match that of the firefox history button. This would make the new button look like one button with an arrow on it, instead of two different buttons that are kind of grouped together. I'm attaching a mockup of what this might look like.
ahh... sorry, i totally misunderstood you. okay, then i guess that this bug report is a duplicate of bug 327330, bug 307776, bug 262210, bug 254503, bug 252814 or bug 245342? :-) (i myself don't know if those bug reports are *all* the same, but they *could* be, that's why i'm writing them down here)
Srini, can you comment on this please ?
It is a bug, either with up or with the theme. IIRC dobey/someone patched up Industrial theme to make it look like toolbutton. I guess Firefox uses XUL with Gtk backend to do this, and we have hacked up to add this button. Ideally the toolkit should have a support for such a button IMO. If so then all the issues will be solved.
The new-button looks a lot better in evo 2.8.1 so this bug should probably be closed.
I think the problem is, that gtk needs a way to remove left or right borders from a button. If this was added, two buttons could be placed next to each other, but have the shape of one.
Created attachment 104593 [details] Button implementation I've written a button which I think is useable. It's written in pygtk as I don't speak C, but it demonstrates the idea.
Created attachment 104594 [details] Screenshot of the python button
Thomas, does it have the same functionality as the current new button ? Clicking New would launch the default menu item. and clicking 'v' would show a dropdown menu?
It is only a proof of concept, but if you run it, you see that it actually contains of two buttons stacked on top of each other. You can asign different actions to them. One can open the dialog, one can bring up the menu.
Created attachment 104630 [details] Looking a little better (With relief)
Created attachment 104632 [details] Screenshto of new version
Created attachment 104634 [details] Button implementation with out relief (used by the toolbar) Btw. as it is python files, you can just download and run them to view the button in action.
It current'y assumes the button border is 3px, as the gtk.Button.props.inner_border.width property is not readable from python - http://bugzilla.gnome.org/show_bug.cgi?id=484030 but if translating to C this could be made more nicely.
http://bugzilla.gnome.org/show_bug.cgi?id=375313 is closely related to this bug.
Karl, I think GtkMenuToolButton is the one nautilus uses and I somehow feel that the "Back"+"v" and "Forward"+"v" are totally disconnected. They dont feel/appear like together. Neither the mouseover shades them collectively. I understand the shading thing you mentioned. I'm wondering what can be a better soln. Thomas, I'm not sure, if I can write a new button from the pycode. I donno much python also and not much Gtk+ internals :(
> I'm not sure, if I can write a new button from the pycode. I donno much > python also and not much Gtk+ internals :( Well, it shouldn't be too hard. It is simply a gtk.Layout with two buttons. The v button is placed on top of the normal button. In pseudo (pygtk) it looks something like this: layout = gtk.Layout() button = gtk.Button(...) button.set_relief(gtk.RELIEF_NONE) layout.put(button, 0, 0) arrow_button = gtk.Button() arrow_button.add(gtk.Arrow(gtk.ARROW_DOWN, gtk.SHADOW_NONE)) arrow_button.set_relief(gtk.RELIEF_NONE) balloc = button.get_allocation() aballoc = arrow_button.get_allocation() # Make the size of the arrow_button fit perfectly to the button arrow_button.set_size_request(aballoc.width, balloc.height) # Extend button so there is space for the arrow_button. button.set_size_request(balloc.width+aballoc.width, balloc.height) button.props.xalign = 0 # Add the arrow_button where it belongs layout.put(arrow_button, balloc.width, 0) The actual code is cluttered a little by the widgets size not being determined before show. Also, in combobutton_relief.py, a custom button is created for the v, which doesn't draw the left most 3 pixels. For this version I don't see any use in evolution though, as toolbars are always RELIEF_NONE.
I just noticed, that in emails with attachments, the down most widget is a button with an v. In this button however, the v button isn't pressed when you click it.
You are right. Because, both has different actions. May be I'm wrong. Once is a inline viewer and at times.. that is even disabled.
Well the first one has an action on the main button and a list and the v. The seccond one has an action and changes image on the main button and a list on the v. There is no reason the v button on the seccond button shouldn't be "pressable" but only "clickable". That is no press animation.
Folding this into bug #552010. Once BonoboUI is dropped, we can use a standard GtkMenuToolButton, which I'm already doing on my "kill-bonobo" branch. See [1] for more details. [1] http://www.go-evolution.org/KillBonobo *** This bug has been marked as a duplicate of 552010 ***