Skip to main content

Hybrid Menubar and Toolbar Tabber

The customary method of organizing application menubars and toolbars is in a vertical sequence. To save space, sometimes multiple tool sets can be embedded into a single bar. This is fine but what usually results is a duplication if the functionality offered in a pull-down menu and some toolbar button. This can cause a lot of clutter, not only on screen, but in the coding where the duplication is a occurring.

For a user the on-screen clutter can be obtrusive as it begins to eat away at the screen space used by an application in both the horizontal and vertical dimensions. Too many on screen toolbars reduces the size of user work zones and tool many items per bar can result in windows whose resizing becomes constrained.  

Multiple toolbars can be toggled on or off, but then a menu item, nested somewhere in menu in the toolbar needs to be created, the result more clutter. Complex GUI elements are not only demanding in terms of coding, but offputting to any new user who has grown shy of 'bloated apps'. Users become menu weary. 

The solution? Why not switch between toolbars as needed, and leave those not so often used options such as would be found in the File, Settings and Help menu in the menubar.

Switching between toolbars is easily sorted, place them in the pages of a notebook. But, one might ask, will this take up three rows on screen, with one each for the menubar, notebook tabs and the toolbars. Well no, not really. The solution lies in embedding the menubar into the notebook tab bar using the -startWiget option. And, for those who prefer the Help menu tucked on the right hand side of the menu bar, its even possible to embed this separately using the -endWidget option. The result, a clean and simple solution with a modern feel to it.

Here's a screen shot, showing this at work in a proof of concept script.


#!/bin/sh
# the next line restarts using tclsh \
exec tclsh "$0" "$@"

if { [catch { package present Gnocl } ] } { package require Gnocl }
    
set frame [gnocl::vBox]
set nb [gnocl::notebook]
$frame add $nb
set menuBar [gnocl::menuBar]
$nb configure -startWidget $menuBar
set container [gnocl::vBox]
    
$frame add $container -fill 1 -expand 1
gnocl::window -child $frame -setSize 0.3 -onDelete exit

set menu(file) [gnocl::menu ]
set menu(help) [gnocl::menu ]

$menu(file) add [gnocl::menuItem -text "%#New" -onClicked {puts "That's new"}]
$menu(file) add [gnocl::menuItem -text "%#Open" -onClicked {puts "That's new"}]
$menu(file) add [gnocl::menuItem -text "%#Save" -onClicked {puts "That's new"}]
$menu(file) add [gnocl::menuSeparator]
$menu(file) add [gnocl::menuItem -text "%#Quit" -onClicked exit ]
set item(help) [gnocl::menuItem -icon %#Help -text "%__Help" -onClicked { gnocl::dialog -text HELP!}]
set item(about) [gnocl::menuItem -icon %#About -text "%__About" -onClicked { gnocl::aboutDialog }]

$menu(help) add $item(help)
$menu(help) add $item(about)

set file [gnocl::menuItem -text "%__File" -submenu $menu(file)]
set help [gnocl::menuItem -text "%__Help" -submenu $menu(help) ]

$menuBar configure -children [list $file $help]


$nb addPage [gnocl::richTextToolBar  -iconSize small] %__Markup

set tb1 [gnocl::toolBar -style icons -iconSize small]
$nb addPage $tb1 %__Edit

set tb2 [gnocl::toolBar -style icons  -iconSize small]
$nb addPage $tb2 %__Tools

    
$tb1 add item -icon %#Cut   
$tb1 add item -icon %#Copy
$tb1 add item -icon %#Paste
$tb1 add item -icon %#Delete
$tb1 add item -icon %#Undo
$tb1 add item -icon %#Redo

$tb2 add item -icon %#GoBack   
$tb2 add item -icon %#GoDown
$tb2 add item -icon %#GoForward
$tb2 add item -icon %#GoUp
$tb2 add item -icon %#GotoFirst
$tb2 add item -icon %#GotoLast


$container add [gnocl::text -name txt -margins {4} -useMarkup 1] -fill 1 -expand 1

set stat [gnocl::statusBar]
$container add $stat -fill 1
    
txt lorem ;# using widget alias automatically created using the gnocl::text -name option
    
$stat push ready...


Other enhancement that could be implemented included a tearoff capability for the toolbar notebook tabs and the use of menu ribbons outlined in a previous blogpost (clear here to read).


Comments

Popular posts from this blog

gnocl::calendar

Given this module some attention today. Added some of the more package wide options to the module and created customised handler for setting the month. (For some odd reason months are are counted 0-11 whereas days are 1-31.) There's still a little more to do to this one including the addition of code to store diary details. Here's the working test script to show the range of options at work. The percentage substitution string item %e explores something that I've been toying with, the name of the signal/event that initiated the call. Ok, a script can keep its own internal trace but who knows, it might prove useful. #--------------- # calendarTest.tcl #--------------- # Author:   William J Giddings # Date:     07/05/09 #--------------- #!/bin/sh # the next line restarts using tclsh \ exec tclsh "$0" "$@" #--------------- package require Gnocl set cal [gnocl::calendar] $cal configure -day 8 -month 7 -year 1956 $cal configure -rowHeight 1 -colWidth 1 $ca...

Gnocl Dashboard

Over the past few programming sessions I've been working on producing a central point, a dashboard, around which it's possible to see the various Gnocl widgets and commands in operation. In many ways like the demo script which shipped with the earlier releases of Gnocl but offers much more. The introspection functionality provides details of the various options and sub-commands of each Gnocl procedure which are displayed under the associated tab. Sample scripts are included for each item which offers newcomers a clearer insight into how make the most of what's on offer.

Getting Widget Style Properties

Until the move over to Gtk4, Gnocl is still built against the Gtk 2.21 libraries. One of the inconveniences of Gtk is getting and setting widget style settings which are considered to be set globally by the desktop style settings and not for the programmer to tinker around with. Needless to say, there are times when different defaults are preferred, largely to draw the users attention to 'something a bit different'. The function gtk_widget_modify_font  is a convenience function to set the widget basefont as shown in this snippet from the button.c module,  if ( options[baseFontIdx].status == GNOCL_STATUS_CHANGED ) { GtkWidget *label; label = gnoclFindChild ( GTK_WIDGET ( para->button ), GTK_TYPE_LABEL ); PangoFontDescription *font_desc = pango_font_description_from_string ( Tcl_GetString ( options[baseFontIdx].val.obj ) ); gtk_widget_modify_font ( GTK_WIDGET ( label ), font_desc ); pango_font_description_free ( font_desc ); } Unfortunately, there's no d...