Warning: session_start(): open(/tmp/sess_idu079g78k4c91skrh29l7mjj5, O_RDWR) failed: No space left on device (28) in /www/H01/htdocs/lib/base/lib_base.php on line 280
Flexible and easily modifiable toolbars & menus openDesktop.org
-
 KDE-Apps.org Applications for the KDE-Desktop 
 GTK-Apps.org Applications using the GTK Toolkit 
 GnomeFiles.org Applications for GNOME 
 MeeGo-Central.org Applications for MeeGo 
 CLI-Apps.org Command Line Applications 
 Qt-Apps.org Free Qt Applications 
 Qt-Prop.org Proprietary Qt Applications 
 Maemo-Apps.org Applications for the Maemo Plattform 
 Java-Apps.org Free Java Applications 
 eyeOS-Apps.org Free eyeOS Applications 
 Wine-Apps.org Wine Applications 
 Server-Apps.org Server Applications 
 apps.ownCloud.com ownCloud Applications 
--
-
 KDE-Look.org Artwork for the KDE-Desktop 
 GNOME-Look.org Artwork for the GNOME-Desktop 
 Xfce-Look.org Artwork for the Xfce-Desktop 
 Box-Look.org Artwork for your Windowmanager 
 E17-Stuff.org Artwork for Enlightenment 
 Beryl-Themes.org Artwork for the Beryl Windowmanager 
 Compiz-Themes.org Artwork for the Compiz Windowmanager 
 EDE-Look.org Themes for your EDE Desktop 
--
-
 Debian-Art.org Stuff for Debian 
 Gentoo-Art.org Artwork for Gentoo Linux 
 SUSE-Art.org Artwork for openSUSE 
 Ubuntu-Art.org Artwork for Ubuntu 
 Kubuntu-Art.org Artwork for Kubuntu 
 LinuxMint-Art.org Artwork for Linux Mint 
 Arch-Stuff.org Art And Stuff for Arch Linux 
 Frugalware-Art.org Themes for Frugalware 
 Fedora-Art.org Artwork for Fedora Linux 
 Mandriva-Art.org Artwork for Mandriva Linux 
--
-
 KDE-Files.org Files for KDE Applications 
 OpenTemplate.org Documents for OpenOffice.org
 GIMPStuff.org Files for GIMP
 InkscapeStuff.org Files for Inkscape
 ScribusStuff.org Files for Scribus
 BlenderStuff.org Textures and Objects for Blender
 VLC-Addons.org Themes and Extensions for VLC
--
-
 KDE-Help.org Support for your KDE Desktop 
 GNOME-Help.org Support for your GNOME Desktop 
 Xfce-Help.org Support for your Xfce Desktop 
--
openDesktop.orgopenDesktop.org:   Applications   Artwork   Linux Distributions   Documents    Linux42.org    OpenSkillz.com   
 
Home
Apps
Artwork
News
Groups
Knowledge
Events
Forum
People
Jobs
Register
Login


-
- Content .- Fans  . 

Flexible and easily modifiable toolbars & menus

  

KDE4 Brainstorm

Score 71%
Flexible and easily modifiable toolbars & menus
zoom


Flexible and easily modifiable toolbars & menus
zoom


Flexible and easily modifiable toolbars & menus
zoom


Downloads:  81
Submitted:  Jul 13 2006

Description:

This is an initial version of a proposal to include more flexible and easily modifiable toolbars & menus with KDE4. I'll be posting more mockups later on.

The basic idea is that modifying the toolbars and menus of KDE applications should be possible on an item by item basis (as opposed to the toolbar basis in KDE3) and accessible straight from the corresponding context menu.

The mockups depict a konqueror toolbar which has buttons of varying sizes, with some of them having text labels. There's also initial mockups of the toolbar context menu.

The context menu for menu items would be roughly similar, with options for adding the item to the toolbar, moving the item, adding/removing an icon for the item and shrinking/enlarging the icon for the item.

The main problem with this idea, i.e. positioning of toolbar items, could be resolved by using either separators or some sort of grid-based approach.

With separators the idea is that in horizontal toolbars the spacing between two vertical separators would be defined by the tallest item between them. Smaller items could then be placed on several rows (as shown by the forward/up buttons in the konqueror toolbar mockup) if the vertical spacing would allow it. Vertical separators could then be used to further divide the toolbar into manageable (usually context-specific) boxes.

The same would obviously go for vertical toolbars, with the obvious difference that the widest item would define the spacing between vertical separators and horizontal separators would be used for further division.




Changelog:

Initial version

TODO:
- Mockup of context menu for menu items
- More toolbar examples




LicenseLGPL
(Example of a modified konqueror toolbar)
Send to a friend
Subscribe
Other  Content  from jannuhat
Report inappropriate content



-

 Like opera

 
 by kriko on: Jul 13 2006
 
Score 50%

I think it would be good to copy the way to customize toolbars from Opera:
You right click on toolbar, select customize..., and have fun by removing, adding, dragging buttons. It's easy.


Reply to this

-

 Re: Like opera

 
 by jannuhat on: Jul 13 2006
 
Score 50%

Yes, both Opera and Firefox use the Customize... context menu item, which opens a separate toolbar cutomisation dialog. And it works well on both.
All KDE3 applications also have similar customisation possibilities in the menu under Settings / Configure Toolbars...

Here the idea is to bring this GUI customisation one step closer to the user. Instead of opening a separate customisation dialog, all the customisation options are directly accessible from the context menu of the toolbar and menu items. Kind of like it works in Kicker in KDE3 (and earlier), which, in the end is really a desktop-wide toolbar.

Which reminds me that I'll have to add a Lock toolbar option (like in Kicker 3.5) to the context menu.


Reply to this

-
.

 Bad idea

 
 by SibSkull on: Jul 13 2006
 
Score 50%

I think various button size is bad idea because hard to find by eyes and point by mouse. Usually eyes go through horizontal line. Another solution: begin from bigger icons and continue two toolbar with ordinary icon size.


Reply to this

-

 Re: Bad idea

 
 by jannuhat on: Jul 13 2006
 
Score 50%

"I think various button size is bad idea because hard to find by eyes and point by mouse. Usually eyes go through horizontal line."

I don't know about others, but my eyes at least don't follow horizontal (or vertical) lines. My eyes see one elliptical area at a time and when they move, they jump to the most striking visible object in my field of view no matter where it is.
That is, unless I concentrate on something like reading or looking for a certain button. (But as everyone knows, UIs themselves should require as little concentration as possible, because concentration used on the UI means less concentration on the actual task which the user wants to perform)

Using various icon sizes makes it possible to differentiate actions and action contexts in a new way.
In the mockup, for example, the huge Previous button not only makes it easier to hit this fairly often used action (thus making it easier&faster to use) but also works as a visual beacon for the whole navigational section of the toolbar.
So when you're looking for the Up button, you can first aim for the big arrow and intuitively find the correct button in the immediate vicinity (except of course that the Up button should be on top of the Forward button, unlike the mockup).

In other words, the big icons work pretty much like folders, tabs and virtual desktops. They make it possible for the user to categorise&group button positions in the toolbar.
Thus you don't have to remember where each individual button is, you only have remember how it's positioned relative to the few big buttons in the toolbar.
Of course, this feature is a lot more useful in complex programs such as KDevelop or KOffice (and MSOffice, incidently), which can have a lot of different buttons on different sides of the window.

It's basically the same thing that you do when you organise photos (real ones, that is), or any large number of similar-sized things. When you spread the photos on the table or floor, you don't put them in a perfectly aligned grid, but rather in a somewhat random order with varying photograph orientation and amount of photos in each area.
And that's simply because forming a memory map of such a varying 'landscape' is a lot easier for the human brain than doing it on a perfectly aligned grid. (Just guess why all memory games use an aligned grid)

"Another solution: begin from bigger icons and continue two toolbar with ordinary icon size."

That could basically work, but you would lose a lot of the flexibility of this approach. Flexibility which might be useful even though one were to stick to one icon size.
For example, with item-specific customisation one could easily recreate the current menubars in a toolbar, with icons next to the most prominent menus.


Reply to this

Add commentBack




-



 
 
 Who we are
Contact
More about us
Frequently Asked Questions
Register
Twitter
Blog
Explore
Apps
Artwork
Jobs
Knowledge
Events
People
Updates on identi.ca
Updates on Twitter
Content RSS   
Events RSS   

Participate
Groups
Forum
Add Content
Public API
About openDesktop.org
Legal Notice
Spreadshirt Shop
CafePress Shop
Advertising
Sponsor us
Report Abuse
 

Copyright 2007-2016 openDesktop.org Team  
All rights reserved. openDesktop.org is not liable for any content or goods on this site.
All contributors are responsible for the lawfulness of their uploads.
openDesktop is a trademark of the openDesktop.org Team