On Wed, Sep 05, 2007 at 11:38:21AM -0300, bulia byak wrote:
On 9/5/07, Gustav Broberg <broberg@...370...> wrote:
That's true, but you can also choose to dock any dialog this way, on "top" of another, by dragging and dropping it at the middle of the other one. GDL allows this arrangement to be displayed as notebook with buttons or tabs (http://wiki.inkscape.org/wiki/index.php/Image:Inkscape_dock2.png).
To me, the main problem with it is that I cannot "expand" such a tab. If two dialogs are "tabbed" I can only alternate between them, but I cannot see both. That would be slightly more acceptable if they were indeed tabs as on your screenshot, but for me they are vertically stacked buttons which makes their behavior extremely counterintuitive.
Well, you can expand them by dragging the current one up or down and drop it on the group. The buttons will only be stacked vertically when there's not enough room for them on one row. I think that's more convenient than the standard gtk "tabbed" layout which will keep them on one long row and give you arrows to scroll the tab list.
One can now change to tabbed layout if it's preferred by setting "options.dock[switcherstyle]" to "4".
That said, it would be easy for me prevent dialogs from being arranged in this mode all together (it's a just one line code change), but personally I'd like to at least keep it as an option. How about preventing them from being automatically arranged as groups when the dock is full, but still allow them to be arranged manually?
I think that might work. Unasked-for tabification is unpredictable and extremely annoying. If the accidental tabification by dragging a dialog on top of one another proves to also be a problem, we can indeed add a preference setting for that, off by default.
Done, the new option is called "options.dock[cancenterdock]" (="1" by default).
You still have the icon, and icon with text is better than just icon so long as it does not take too much space - and these take minimum space thanks to their verticality. So I see no problem with these "vertical icons".
What's the policy on adding "hidden" preferences for things like this? (I noticed that we already have a hidden "icononly" option for the toolbox.)
I don't think there's much of a policy on this, except that you must document it (as everything else!) in release notes in detail.
Sure, I will. The new option is "options.dock[dockbarstyle]". Setting it to "0" will give you icons only.
More problems: besides F8, it seems to also steal F6. Please give those keys back! :)
Don't blame me, blame GTK! :)
It turns out that F6 and F8 are captured by any gtk_paned for controlling focus by keyboard. Furthermore they are reserved by HIG for that purpose. See http://developer.gnome.org/projects/gup/hig/2.0/input-keyboard.html#standard... (A Gtk::HPaned is used for dividing the canvas and the dock, obviously.)
I tried to do an ugly hack around it by using something like gtk_binding_entry_remove (my_paned_binding_set, GDK_F6, NULL), but I couldn't get it working. Any ideas on how to solve this in a proper way? A custom signal handler re-emitting those signals? Is anyone using those key bindings for controlling a paned, btw?
[...]
I also propose to reconsider the position of the dock. Now it's on the right of the canvas but below the toolbars. I think it would make sense to expand it upwards so it would be on the right of all the toolbars and the menu bar, shortening them. The right end of the menu bar is always wasted anyway; as for the toolbars, all of them are now squeezable without any loss of functionality (a drop-down replaces those items that didn't fit). Similarly, I think the dock should be on the right of the palette at bottom - but still on top of the statusbar as now, because it's difficult to read statusbar messages when statusbar becomes too short. All this should give the dock a lot more vertical space which is valuable.
Hmm, perhaps. I actually had it like that in the beginning, but I thought it looked kind of strange, so I changed it... But, I'll consider it.
-- Gustav