[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: Modifications to the main-menu of PCB
Felix Ruoff wrote:
> if we continue this discussion at an
> extra thread which I like to start with this mail :-).
Well, in my newsreader, this email is part of the thread that started
as "PCB: Change default file-filter in open-dialog". But I am ok with
it. ;-)
> I am currently spending some time with thinking about the
> menu-structure. Therefor my first question: Is anybody else
> working at this point?
Not really working on it. But I too think, the menus of the GUI show
their age. There quite an number of menu related entries in my local
list of pcb bugs'n warts...
>
> One of the reasons for me to modify the menu is, to adapt it to the
> human-interface-guidelines (hid-guidelines) of GNOME
> (http://library.gnome.org/devel/hig-book/).
+1
The less the interface deviates from the standards in the hig-book, the
lower the entry-barrier to newbies. And yes, geda/pcb needs to be nice
to new users. Else, the project will loose too many eyes and minds to
kicad.
The other, even more important GUI goal is consistency with gschem. It
is a real PITA if a common key stroke do different things in the two
applications. Worst example at the moment is the [n] key. This is "edit
name" in pcb and "draw connection" in gschem.
Yes, to fix this kind of inconsistency, only one application can keep
its traditional key binding. The fix will break long standing habits of
power users. Maybe an alternative traditional/compatible toggle would
make everyone happy... Shouldn't be too hard to implement. It just
requires an action to load a gmenu.res on demand.
> In some cases it might be nice to support some new and the old
> shortcuts the same time.
> Does anyone of you know if it is possible in the actual
> implementation to define two shortcuts for the same action?
A working example in the current default gmenu.res is the undo action.
It can be triggered with [u] and alternatively by [ctrl-z].
> The hid-guidelines suggesting Ctrl++ and Ctrl+- as shortcuts for
> zooming in and out.
The hig also suggests the mouse wheel should up-down pan by default and
require ctrl modifier for zoom. However, this is a pain in graphics
applications. Inkscape is clearly a project to look at in terms of GUI-
standards. It features a preference toggle to choose the mouse
behavior.
> Using the plus and minus-sign for keyboard
> shortcuts is not
> possible in the actual implementation. The appended patch fixes this.
Nice. Remember, in this project you have to do some nagging to get a
patch applied.
> First, it's just about the "File"-menu.
The real buggers are in edit/select/settings. But let's start easy :-)
>
> File
> New Ctrl+N
Should be "New... Ctrl+N". A dialog should open to set some start-up
values like layout name,
> Open Layout... Ctrl+O
Make this "Open... Ctrl+O". See below.
> Load
> Element Data to Paste Buffer... // perhaps, this two entries
> can be merged at a later stage.
> Layout Data to Paste Buffer... // needs some coding (am
> working at this). Perhaps, moving this two to the 'Buffer'-menu?
IMHO, the two paste buffer load actions should be merged. The
application should be able to see by itself which kind of data it gets
and act accordingly. Please don't move a file action to the buffer
menu. Instead, the save_buffer_to_file action should be moved to the
file menu.
> Netlist File...
> Vendor Resource...
Again, these types of files should be recognized by the application.
Then load layout, load netlist and load vendor resource can be merged
to a general open command.
> -----
> Save Layout Ctrl+S
> Save Layout As... Shift+Ctrl+S
> Save Connection Data of
> a Single Element
> All Elements
> Unused Pins
I never used these. What are they good for?
> Save Buffer to Footprint // Don't know if this
> should be added here.
Sure, it should be here. A save anywhere else than in the file menu is
an oddball.
> -----
> Update from Schematic...
> Revert
> To Saved
> To Backup // Don't know the action to
> fill in here. Is this implemented in the core already?
Why is revert to backup needed at all? I only think about think about
backups, if something really screwed up. In this case, I don't want
anything automatic to happen, as this might screw it even more. Since
revert is nothing but load layout, I'd choose this action manually.
Revert to backup should not be frequent in the first place. In fact, I
can hardly remember the last time I needed a pcb backup :-)
> -----
> Calibrate Printer... (or perhaps 'Page Setup' when there will
> be a new page-setup-dialog)
Should be included into the "print..." dialog. --> An item less on the
menu.
> Print Layout... Ctrl+P
> Export Layout...
> -----
> <List of recent files> // I did some work on this. It
> works but it is not well integrated jet. Will send a patch when ready
> (or I gave up)
> -----
> // Here was the 'Preferences'-entry.
By the way: The preference dialog contains some major room for GUI
improvement. Currently it mixes settings for the document with settings
for the application. In addition, the dialog should not be modal.
Changes should become effective immediately.
> I think we can move it to 'Edit'
> (as also suggested in the ghi-guidelines) to make this menu shorter
But the edit menu is even longer and will never be short. After all,
doing a layout is all about editing. Just checked with inkscape and it
also features the preferences in the file menu. So we are in good
company ;-)
---<)kaimartin(>---
--
Kai-Martin Knaak
Öffentlicher PGP-Schlüssel:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user