Naming and User interface Conventions

Chia sẻ: Nhan Nguyen | Ngày: | Loại File: PDF | Số trang:119

Thêm vào BST

Báo xấu

193
lượt xem 6
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Like other open source projects, the code base for the Eclipse project should avoid using names that reference a particular company or their commercial products.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Naming and User interface Conventions

Naming Conventions From Eclipsepedia Contents • 1 General o 1.1 Eclipse Workspace Projects o 1.2 Java Packages o 1.3 API Packages o 1.4 Internal Implementation Packages o 1.5 Test Suite Packages o 1.6 Examples Packages o 1.7 Additional rules • 2 Classes and Interfaces • 3 Methods • 4 Variables • 5 Constants • 6 Plug-ins and Extension Points • 7 System Files and Settings General Like other open source projects, the code base for the Eclipse project should avoid using names that reference a particular company or their commercial products. Eclipse Workspace Projects When Eclipse is being used to develop plug-ins for the Eclipse project, the name of the Eclipse workspace project should match the name of the plug-in. For example, org.eclipse.core.runtime plug-in is developed in an Eclipse workspace project named org.eclipse.core.runtime. Java Packages The Eclipse Platform consists of a collection of Java packages. The package namespace is managed in conformance with Sun's package naming guidelines; subpackages should not be created without prior approval from the owner of the package subtree. The packages for the open-source Eclipse project are all subpackages org.eclipse. The first package name segment after org.eclipse is generally the subproject name, followed by the component name.
org.eclipse..[.*]- General form of package names The following subprojects are assigned at the time of writing: org.eclipse.jdt.[.*] - Java development tooling org.eclipse.pde.[.*] - Plug-in development environment The following package name segments are reserved: internal - indicates an internal implementation package that contains no API tests - indicates a non-API package that contains only test suites examples - indicates a non-API package that contains only examples These name are used as qualifiers and appear between the subproject and component name: org.eclipse..internal.[.*] - internal package org.eclipse..tests.[.*] - tests org.eclipse..examples.[.*] - examples In the case of the Eclipse Platform proper, there is no subproject name, and the qualifiers appear immediately after the component name: org.eclipse.[.*] - Eclipse Platform proper org.eclipse..internal[.*] - Eclipse Platform internal package org.eclipse..tests[.*] - Eclipse Platform tests org.eclipse..examples[.*] - Eclipse Platform examples The following components of the Eclipse Platform proper are assigned at the time of writing: org.eclipse.ant[.*] - Ant support org.eclipse.compare[.*] - Compare support org.eclipse.core[.*] - Platform core org.eclipse.debug[.*] - Debug org.eclipse.help[.*] - Help support org.eclipse.jdi[.*] - Eclipse implementation of Java Debug Interface (JDI) org.eclipse.jface[.*] - JFace org.eclipse.platform[.*] - Documentation org.eclipse.scripting[.*] - Scripting support org.eclipse.sdk[.*] - SDK configuration org.eclipse.search[.*] - Search support org.eclipse.swt[.*] - Standard Widget Toolkit org.eclipse.ui[.*] - Workbench org.eclipse.update[.*] - Plug-in live update org.eclipse.vcm[.*] - Version and Configuration Management org.eclipse.webdav[.*] - WebDAV support
For example, org.eclipse.jdt.internal.core.compiler - Correct usage org.eclipse.jdt.core.internal.compiler - Incorrect. internal should immediately follow subproject name. org.eclipse.core.internal.resources - Correct usage org.eclipse.internal.core.resources - Incorrect. internal should never immediately follow org.eclipse. org.eclipse.core.resources.internal - Incorrect. internal should immediately follow Eclipse Platform component name. API Packages API packages are ones that contain classes and interfaces that must be made available to ISVs. The names of API packages need to make sense to the ISV. The number of different packages that the ISV needs to remember should be small, since a profusion of API packages can make it difficult for ISVs to know which packages they need to import. Within an API package, all public classes and interfaces are considered API. The names of API packages should not contain internal, tests, or examples to avoid confusion with the scheme for naming non-API packages. Internal Implementation Packages All packages that are part of the platform implementation but contain no API that should be exposed to ISVs are considered internal implementation packages. All implementation packages should be flagged as internal, with the tag occurring just after the major package name. ISVs will be told that all packages marked internal are out of bounds. (A simple text search for ".internal." detects suspicious reference in source files; likewise, "/internal/" is suspicious in .class files). Test Suite Packages All packages containing test suites should be flagged as tests, with the tag occurring just after the major package name. Fully automated tests are the norm; so, for example, org.eclipse.core.tests.resources would contain automated tests for API in org.eclipse.core.resources. Interactive tests (ones requiring a hands-on tester) should be flagged with interactive as the last package name segment; so, for example, org.eclipse.core.tests.resources.interactive would contain the corresponding interactive tests. Examples Packages All packages containing examples that ship to ISVs should be flagged as examples, with the tag occurring just after the major package name. For example, org.eclipse.swt.examples would contain examples for how to use the SWT API. Additional rules
• Package names should contain only lowercase ASCII alphanumerics, and avoid underscore _ or dollar sign $ characters. Classes and Interfaces Sun's naming guidelines states Class names should be nouns, in mixed case with the first letter of each internal word capitalized. Try to keep your class names simple and descriptive. Use whole words - avoid acronyms and abbreviations (unless the abbreviation is much more widely used than the long form, such as URL or HTML). Examples: • class Raster; • class ImageSprite; Interface names should be capitalized like class names. For interface names, we follow the "I"-for-interface convention: all interface names are prefixed with an "I". For example, "IWorkspace" or "IIndex". This convention aids code readability by making interface names more readily recognizable. Additional rules: The names of exception classes (subclasses of Exception) should follow the common practice of ending in "Exception". Methods Sun's naming guidelines states Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized. Examples: • run(); • runFast(); • getBackground(); Additional rules:
The named of methods should follow common practice for naming getters (getX()), setters (setX()), and predicates (isX(), hasX()). Variables Sun's naming guidelines states Except for variables, all instance, class, and class constants are in mixed case with a lowercase first letter. Internal words start with capital letters. Variable names should not start with underscore _ or dollar sign $ characters, even though both are allowed. Variable names should be short yet meaningful. The choice of a variable name should be mnemonic - that is, designed to indicate to the casual observer the intent of its use. One-character variable names should be avoided except for temporary "throwaway" variables. Common names for temporary variables are i, j, k, m, and n for integers; c, d, and e for characters. Examples: • int i; • char c; • float myWidth; Constants Sun's naming guidelines states The names of variables declared class constants and of ANSI constants should be all uppercase with words separated by underscores ("_"). Examples: • static final int MIN_WIDTH = 4; • static final int MAX_WIDTH = 999; • static final int GET_THE_CPU = 1; Plug-ins and Extension Points All plug-ins (and plug-in fragments), including the ones that are part of the Eclipse Platform, like the Resources and Workbench plug-ins, must have unique identifiers following the same style of naming convention as Java packages. For example, the workbench plug-in is named org.eclipse.ui. The names of a plug-in and the names of the Java packages declared within the code library of that plug-in commonly align. For example, the org.eclipse.ui plug-in declares
much of its code in packages named org.eclipse.ui.* . While alignment is the recommended practice, it is not an absolute requirement. For instance, the org.eclipse.ui plug-in also declares code in packages named org.eclipse.jface.*. The org.eclipse.ant.core plug-in declares code in packages named org.eclipse.ant.core and org.apache.tools.ant.*. The plug-in namespace is managed hierarchically; do not create plug-in without prior approval from the owner of the enclosing namespace. Extension points that expect multiple extensions should have plural names. For example, "builders" rather than "builder". System Files and Settings By convention, files or folders that start with a period ('.') are considered "system files" and should not be edited by users or, directly, by other components that do not "own" them. Of special note is the ".settings" folder in a workspace project. This folder holds various forms of preference or metadata specific to that workspace project. Files in this directory do not have to start with a period (they are assumed "system files" as they are in a "system folder") but they must follow the same naming conventions outlined elsewhere in this guide. That is, they must identify themselves with their Eclipse Project's namespace (e.g. org.eclipse.jdt, org.eclipse.jst, etc). and they should be as specific as possible to denote the package they come from, or the function they are serving. For example, org.eclipse.jdt.core.prefs org.eclipse.jst.common.project.facet.core.prefs org.eclipse.wst.common.project.facet.core.xml Two obvious exceptions to this convention are the .classpath and .project files, but ... that's just because they were the first, before the large community of Eclipse was grasped. Following these namespace guidelines will help avoid conflicts where two plugins or projects could accidently pick the same name for a metadata file.
Eclipse User Interface Guidelines (Version 2.1 - 3.x Working Draft) Nick Edgar, Kevin Haaland, Jin Li and Kimberley Peter Last Updated: February 2004 Note: Please use the discussion page to add comments instead of embedding them in this document. Note: We have created a section for hosting the drafts of ongoing Eclipse v3.x UI guidelines (Best Practices) updates. Go to Eclipse UI Best Practices v3.x updates (Last updated in June, 2006) Notice Your feedback can influence the ideas and guidelines described here. If you have suggestions, please provide us with your feedback on the UI mailing list or on the discussion page. Introduction In this document the Eclipse user interface guidelines are defined. Eclipse is a universal tool platform - an open, extensible IDE for anything, but nothing in particular. The real value comes from tool plug-ins that "teach" Eclipse how to work with things - Java™ files, Web content, graphics, video - almost anything you can imagine. Eclipse allows you to independently develop tools that integrate with other people's tools so seamlessly, you won't know where one tool ends and another starts. The very notion of a tool, as we know it, disappears completely. The platform is very flexible and extensible, but this flexibility has a serious drawback. In particular, there is no way within the program to ensure user interface consistency between the registered components within the platform. This document attempts to reconcile this problem, by defining standard user interface guidelines for the creation of new components. If these guidelines are adopted within your own tools, it will lead to greater consistency with the platform and other tools, and an easier learning curve for your customers. These guidelines are intended for use by designers and implementors of an Eclipse user interface extension.
The Workbench To start out, let's take a look at the Eclipse workbench user interface, and the various components within it. The workbench is a collection of windows. Each window contains a menu bar, a toolbar, a shortcut bar and one or more perspectives. A perspective is a visual container for a set of views and content editors. The views exist wholly within the perspective and are not shared, but any opened content editors are shared across perspectives. If two or more perspectives have the same view opened, they share the same instance of the view although its layout may differ in the perspectives. For perspectives in different Workbench windows, neither editors nor views are shared. A perspective is like a page within a book. It exists within a window along with any number
of other perspectives and, like a page within a book, only one perspective is visible at any time. The Workbench's main menu bar usually contains the File, Edit, Navigate, Project, Window, Help top-level menus. Other top-level menus that are in between the Edit and Project menu are typically context specific, based on the current active perspective, front most editor (whether active or not), and active view.. In the File menu you will find a New submenu, which contains menu items for Project, Folder, and File creation. The File menu also contains menu items for Import and Export, which are used to import files into the Workbench, and export them out again. In the Edit menu, you will find familiar commands like Cut, Copy, Paste, and Delete. These commands are known as global commands, and target the active part. In other words, if the Delete command is invoked with the Navigator active, the actual implementation is performed by the Navigator. In the Project menu, you will find project related commands such as Open project, Close project and Rebuild project are available. In the Run menu, you will find commands related to running and debugging application code, and launching external tools such Ant scripts. In the Window menu, you will find the Open Perspective submenu to open different perspectives to suit to needs of your development tasks. You will find perspective layout management menu items. You will also find the Show View submenu to add views to the current Workbench window. In addition, you will find the Preferences menu item, which is used to modify the functional preferences of the Workbench. As a plug-in developer, you can contribute new views, editors, wizards, menu, and tool items to the platform. These contributions are defined using XML, and once registered, integrate seamlessly with the components which already exist in the platform. Projects, Folders and Files Eclipse can be used to create many different kinds of content - Java files, Web content, graphics, video - almost anything you can imagine. These objects are stored as regular files within the Eclipse workspace. The workspace consists of one or more top level projects. Each project contains a collection of folders and files. These objects are known as resources. Getting Started For most developers, an introduction to the platform can be overwhelming, and you may ask "where do I get started?". Here are a few basic guidelines which will help you. This document is intended for UI designers and developers. With this audience in mind, we can talk about the two main layers of any application: the model layer and the user interface layer. In the model layer of Eclipse, known as the Workspace, is a collection of resources (projects, folders and files). The user interface, or the Workbench, defines the presentation for those resources.
As a UI developer, you will also have a model and a presentation. If we assume that your goal is to make the model visible, through some presentation, most developers will start out by adding a new view or editor to the workbench. In Eclipse, an editor is used to contain the primary content, such as a document or data object, which users interact with. In every case, this content is the primary focus of attention and a reflection of the primary task. To illustrate this concept, let's look at some common examples. To do Java programming, the primary task is to create, edit, and debug Java code. The primary focus is the Java code, so an editor is used to interact with that code. The navigator, outline, and properties view exist to support the primary task, but rarely hold your attention for an extended period of time while you are writing Java code. To read email, the primary task is to create, send, read, and reply to email. The primary focus is a particular email message, so an editor is used to view or reply to an email message. A view may be used to select an email message to read, and open an editor. To communicate using instant messaging, the primary task is the conversation. The primary focus is a particular conversation, so an editor is used to carry on that conversation. A view may be used to list people with whom you can initiate a conversation. To browse the Web, the primary task is reading. The primary focus is a particular Web page, so an editor is used to browse the Web page. In each case, the primary task determines the primary focus of attention. As the primary focus of attention, it deserves a primary position in the UI (as an editor), and can contribute commands to the workbench's main menu bar and toolbar. A view may be used to save your favorite links, and reopen them. At any time, you may decide to edit the page you are looking at. This causes a new editor to open. Views are used to support the primary task. You use them to navigate a hierarchy of information, open an editor, or view properties for the active part. Each view may have its own local toolbar and local menu bar. Once you have added a view or editor, an interesting question arises. Where did this model come from? In Eclipse, most data is created using a creation wizard. You may want to add a creation wizard too. And once an object exists, you may need a way to edit the properties for that object using a properties page, or the properties dialog. All of these ideas will be discussed, in detail, in the following sections. General UI Guidelines
This document de efines UI guuidelines that are unique and specific to the Eclip platform t c pse m. It is a supplement to the other standard U guidelines such as Mic UI s crosoft® Us ser Experience, Macintosh Huma Interface Guidelines, and Java Lo and Feel Guidelines. an ook l You s should conti inue to consu those gui ult idelines for b basic UI design and implementation recom mmendationss. It is e expected tha you already have a bas understan at y sic nding of the Eclipse UI aarchitecture and A APIs, and the basic UI de e esign principples: user in control, dire ectness, cons sistency, forgivveness, feed dback, aestheetics, and sim mplicity. If y do not cu you urrently have the e prereequisite knowwledge, please read the rrelevant docu umentation ffirst. Gu uideline 1.1 Follo and apply good user i ow y interface des sign principl user in control, direc les: ctness, consi istency, forg giveness, feed dback, aesthhetics, and si implicity. The Spirit of Eclipse E At its heart, Eclip is a platf s pse form for tool plug-ins. Th l hese plug-in may be de ns eveloped by a single team or by a partnersh of teams, or the user m assemb a set of pl e y hip may ble lug-ins from m diver sources. In either case, the usability of an ind rse I dividual tool, and Eclipse as a whole, , e will b positively influenced by user interface consist be y tency. If you in doubt about the a u're t appropriate lo and feel for a tool, look to the pl ook l latform first t, then t Java dev the velopment to ooling and th Plug-in De he evelopment Environmen (PDE) in nt Eclip for guida pse ance. In many cases, the workflow yo imagine m already exist in y ou may y Eclip If so, ado the platf pse. opt form's workf flow and use interface c er conventions. This will lead t greater co to onsistency w the platfo and othe plug-ins, and an easie learning with orm er er curve for your cu e ustomers. In som scenarios, it may be tempting to ignore the w me workflow of Eclipse and implement a "custom" user int terface. This interface w almost ce s will ertainly stand out like a s d sore thumb i in an int tegrated envvironment, wwhere other to adopt th platform c ools he conventions. You lose the be enefit of pas experience and force y st e, your custom to learn new ideas. mers Consult the Best Practices section for exa amples and m more inform mation. Also, visit the Ec , clipse platfor newsgrou to share information with the com rm ups mmunity. Gu uideline 1.2 Follo the platfo lead for user interfac conventio ow orm ce ons.
If you decide to reuse the con u r nventions of Eclipse, be careful not t misapprop f to priate Eclips se speci UI conve ific entions. For instance, the active part in a workbe e ench window is indicated w d by a sshaded title. The use of s shaded titles within an e s editor (see be elow) may be one way too indicate where th focus is, w he within that pa but it will also blur t concept o part art, the of activaation in the window. w Gu uideline 1.3 Be ca areful not to mix UI metaphors. It m blur the o may original conc cept, and you own ur application. Eclip is an open source pro pse n oject. If you feel your ide are gener eas rally useful, join the Eclip communi write a p pse ity, proposal, and work with the Eclipse community to make d Eclip a better platform for p pse p product deve elopment an increase c nd customer sati isfaction. Visit www.eclips se.org and jo the Eclipse UI mailin list platfo oin ng orm-ui-dev. uideline 1.4 Gu If you have an int u teresting ide work with the Eclipse community to make Ec ea, h e y clipse a better platform fo all. r or Capi italization
Consistent capitaalization of te within a plug-in lead to a more polished fee and ext ds el, greater perception of quality. Within a di n ialog or wind dow, headlin capitalizat ne tion should pplied to all titles, menus tooltip, tab and push buttons. For example, "Run to Line be ap t s, bs, r e" can b used as a menu item la be m abel. Sente apitalization should be ap ence style ca pplied to all check boxes radio butto and s, ons, group labels. For example, "C p r Choose an opption for the Java file" c be used a a group e can as label. . Gu uideline 1.5 Use H Headline sty capitaliza yle ation for men tooltip a all titles, including th nus, and , hose used fo or windows, dialogs tabs, colum headings and push bu s, mn s uttons. Capit talize the fir and last rst word and all no ds, ouns, pronou adjective verbs and adverbs. D not includ ending uns, es, d Do de punct tuation. Gu uideline 1.6 Use S Sentence sty capitaliza yle ation for all c control label in a dialog or window, including ls g , those for check boxes, radio b e b buttons, grou labels, an simple tex fields. Cap up nd xt pitalize the first l letter of the first word, a any proper names such as the wo Java. f and ord Lang guage Eclip is availab on a varie of differe platform in a variet of locales. In pse ble ety ent ms, ty reflec ction of the different languages and n d numeric form in each a localizati strategy mats h, ion shoul be adopted for the tex and images within each plug-in. Th involves the ld xt h his separration of all resources fro the sourc code of a plug-in itsel so that tho resource r om ce lf, ose es can b translated to a new loc be cale. Consult the Best Practices section for exa amples and m more inform mation. Gu uideline 1.7 Creat localized version of th resources within your plug-in. te v he r Erro Handlin or ng If an error occurs in Eclipse, the appropri response will be dep s iate e pendent on th context o he of the er rror. Pleas refer to Wizards sectio for guidel se W on lines on how to handle u input err in a w user rors wizar rd.
Pleas refer to Ed se ditors section for guideli n ines on how to handle er rrors occur in an editor, . n When an error oc n ccurs which requires eith an explic user input or immedia attention her cit t ate from users, a mod dialog sh dal hould be use to commu ed unicate the er to the us This rror ser. forces the user to notice, and deal with th problem. o he Gu uideline 1.8 When an error oc n ccurs which requires eith an explic user input or immedia attention her cit t ate from users, comm municate the occurrence with a moda dialog. e al If a p programming error occur in the prod g rs duct, an erro dialog sho or ould be used to comm municate the occurrence to the user. The error sh e hould also be logged usin the e ng work kbench error logging faci ility. This gives the user an opportun to restar the nity rt platfoorm, uninsta the corresp all ponding feat ture, and con ntact their sy ystem adminnistrator. The pplug-in shou provide th following information in the deta area of the error uld he g n ail e dialog: • Provider name n • Plug-in na (user fri ame iendly name e) • Plug-in ID D • Version Gu uideline 1.9 If a p programming error occur in the prod g rs duct, commu unicate the o occurrence w a dialog, with and lo it. og Vis sual Design Go to 3.x updates o s All visual user in nterface elem ments created for Eclipse follow a common style called the d e Eclip visual sty or Eclips style. In th pse yle se hese guidelin you will find basic d nes design inform mation, as well as specif w fications for implementin Eclipse s ng style icons an wizard nd graph in tools based on the Eclipse fra hics e amework. Follo owing these guidelines w help ensu consisten of visual user interfa elements g will ure ncy l ace s and th implem heir mentation acro the Eclip tools and plug-ins. C oss pse d Consistency o these of eleme includes visual sem ents mantic, style, and implem mentation con nsiderations. These topic . cs overed in the following sections. are co e
Consistency In the developme of the Eclipse style ic e ent cons, a visua language w formed t describe a al was to variet of concep in the use interface. T ty pts er These conce are now represented by a large epts d select tion of tiny visual signs that many h v have come to know throu using Ec o ugh clipse tools. In ord to ensure a consisten visual experience, und der e nt derstanding o concepts a of across the tools, and minimi confusio for the use we encou , ize on er, urage you to re-use Eclip style pse graphhical elemen whenever possible. nts r Icon Reuse n A gre many ico have alre eat ons eady been created in the Eclipse visu style so th is a ual here good chance man of the icon or graphical elements you may ne already e ny ns s eed exist. A samp of the cor concepts i shown in t following table. Each of these ele ple re is the g h ements carrie with it a specific mean es s ning, so care should be t e taken when uusing them t ensure tha to at consiistent meanin is mainta ng ained. Gu uideline 2.1
Re-us the core visual concep to mainta consisten representa se v pts ain nt ation and me eaning across s Eclip plug-ins. pse Icon Palettes n Vario palettes used in creat ous u ting Eclipse style icons. There are 3 different pa alettes used t to create the 3 differ icon sta e rent ates, as follow ws: • 256 Color Palette for the active o selected — also referr to as "co r r or red olor"— state of all icon types n • 8 Color Grayscale Palette for th enabled state of perspe G he ective, view, toolbar, toolbar wizard, and lo toolbar i w ocal icons • 2 Color Grayscale Palette for th disabled st of toolbar, toolbar w G he tate wizard, and local toolb icons bar 256 Color Palette Eclip style icon should be designed us pse ns sing a specia 256 color p al palette that c consists of 2 20 stand dard colors an 236 custo colors, as shown belo nd om ow. NOT Although the color p TE: h palette shown is based on the standar windows .aco color n n rd palett that come with Adob Photoshop these two palettes are NOT the sam and te es be p, me ONL the shown color palet should be used when creating Ecl LY n tte e lipse style ic cons. Gu uideline 2.2 Use t Eclipse 256 color pal the 2 lette for crea ating the acti or selecte state of al icon types ive ed ll s.
8 Co Grays olor scale Palet tte To cr reate graysca enabled versions of y ale, your full col icons, yo will need to use lor ou anoth palette th consists o the 8 colors shown be her hat of elow: Gu uideline 2.3 Use t Eclipse 8 color palett for creatin the enable state of perspective, v the te ng ed view, toolbar r, toolbar wizard, an local tool nd lbar icons. 2 Co Grays olor scale Palet tte To crreate graysca disabled versions of your full co and enab icons, y will need ale, d f olor bled you d to use a subset of the 8 color palette, that consists of t 2 colors shown below e f t the w: uideline 2.4 Gu Use t Eclipse 2 color palett for creatin the disabl state of toolbar, toolb wizard, the te ng led bar and lo toolbar icons. ocal Icon Types n The E Eclipse style icons have been catego e orized into seeparate types so that each can be s h optim mized for its specific loca ation within the user inte erface. Below is a breakd w down of these types and where they ar located. e w re
A Product The Product icon represents the branding of the product, and is always located on the far left of the window title bar before the perspective, document, and product name. B Perspective and Fastview Perspective and fastview icons are found down the left side of the workbench. These icons allow the user to quickly switch between different opened perspectives, or to invoke different views that have been created as fastviews. C Toolbar Toolbar icons are found on the main toolbar across the top of the workbench. These icons invoke an command, either globally or within the editor. D Toolbar Wizard Toolbar wizard icons are found on the main toolbar across the top of the workbench. They are easily recognized by their wand and sparkle. Selecting one of these icons will launch a wizard. E View View icons are found on the left side of the titlebar of each view within the workbench. These icons indicate each view’s function. F Local (View) Toolbar Local toolbar icons are found to the right of the view icon on the titlebar of each view within the workbench. These icons invoke an command on objects in that view only.
Local toolbar ico are also f ons found in all m menus, inclu uding main, p down, a context pull and menu us. GM Model Object t Mode Object ico are found in tree view list view and on Ed el ons d ws, ws, ditor Tabs w within the the e work kbench (such as files, fold h ders, project and so on) ts ). H Ob bject Overla ay Objec overlay ic ct cons are also found in tre or list view They are appended t the variou o ee ws. e to us corne of model object icons as signifier of some so of change ers s rs ort e. Gu uideline 2.5 Use t appropria icon type in the locat the ate e tion it is desi igned for wi ithin the user interface. r Icon Size & Pl n lacement With few excepti ions, Eclipse style icons are designed within an a of 16 x 16 pixels. e d area Withi that area, a 15 x 15 pi space is reserved for the image i in ixel r itself, leavin both a ng vertic and horiz cal zontal line of empty pixe to allow f proper pl f els for lacement of the image withi the interfa Note the location of the empty p in ace. e f pixels in the samples belo The ow. icons are cut with the specific placement shown to en s h c nsure alignm in the us interface ment ser e. The d diagrams bel show the proper sizi of the se low ing eparate types of icons, an their s nd prope placement within the a er t allotted scre space. een View Icoons Maximum 16 pixels w x 16 pi m wide ixels high, al lways centered. Empty pixels must be on the left, and bottom e m.
Perspecti Icons ive Fastview Icons w Maximum 16 pixels w x 16 pi m wide ixels high, al lways centered. Empty pixels must be on the righ and bottom e ht, m. Toolbar Icons Toolbar Wizard Icons Local Tooolbar Icons s Maximum 16 pixels w x 16 pi m wide ixels high, al lways centered. Empty pixels should be on the lef and top. ft, Model OObject Icons Maximum 16 pixels w x 15 pi m wide ixels high, al lways centered. Model Ob bject icons m be no g must greater than 1 pixels 15 high. Object OOverlay Icon ns Object Ov verlays are o of the ex one xceptions to the 16 x 16 pixel size e. Maximum 7 pixels w x 8 pixels high, alwa centered m wide ays d. Icon shou have a w uld white outside keyline arou it to und separate i from the ic it is bein appended to. it con ng d See the next section o Icon Posit on tioning for u using the keyline on different ty ypes of Obje Overlay icons. ect Gu uideline 2.6 Follo the specif size speci ow fic ifications for each type o icon. r of Gu uideline 2.7