Re: gEDA-user: Modifications to the main-menu of PCB

[Andrew Poelstra <asp11@xxxxxx>]

On Sat, Oct 02, 2010 at 11:56:56PM +0200, Felix Ruoff wrote:
>  Hello,
> 
> there was/is a discussion about modifying the main-menu of pcb at
> the thread "PCB: Change default file-filter in open-dialog". I think
> it will be more clearly arranged if we continue this discussion at
> an extra thread which I like to start with this mail :-).
> 
> I am currently spending some time with thinking about the
> menu-structure. Therefor my first question: Is anybody else working
> at this point?
>

I spent a short while working on keyboard shortcuts. I got through
the low-hanging fruit (open/save/close/quit) and discovered what you
did: there are a *lot* of little functions in pcb that have keybindings,
and mapping them all is hard work.

Initially, I had wanted there to be a keybinding for every single
operation. But since we have a command mode, perhaps this would be
a Bad Thing? How many times have you screwed up an application by
holding Ctrl and hitting the wrong key?
 
> 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/). Anywhere on the
> geda-webside I found the hint, that the geda (and pcb???)-GUI should
> be adopted to the rules described there. This does some problems
> with the keyboard-shortcuts. E.g. Ctrl+P is actually used for 'Auto
> place selected elements' and should be for 'Print' in the
> guidelines.

Agreed. If somebody put out a patch to clean up the gpcb-menu.res file
and make the shortcuts standard and sane, I would welcome it. But then
the same effort needs to be done for gschem.

> I will prefere using the shortcuts suggested in the document given above.
> 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?
> 

No. You can define the same shortcut twice, but IIRC only one of them
will work. Nothing will complain, but the program will feel broken.

> The hid-guidelines suggesting Ctrl++ and Ctrl+- as shortcuts for
> zooming in and out. Using the plus and minus-sign for keyboard
> shortcuts is not possible in the actual implementation. The appended
> patch fixes this.
> 
+1

> 
> In the old thread there was some discussion about the menu-entries.
> Thank you all for your suggestions! I tried to merge them to a new
> discussion-basis here. First, it's just about the "File"-menu.
> 
> File
>   New                   Ctrl+N
>   Open Layout...        Ctrl+O
>   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?
>     Netlist File...
>     Vendor Resource...
>   -----
>   Save Layout           Ctrl+S
>   Save Layout As...     Shift+Ctrl+S
>   Save Connection Data of
>     a Single Element
>     All Elements
>     Unused Pins

So far so good.

>   Save Buffer to Footprint               // Don't know if this

Personally, I don't like this at all. I think that footprints should
be an export option, as well as the default save behavior in "footprint
mode". Also, we should have a "footprint mode".

> should be added here. Perhaps this should stay at the 'Buffer'-menu.
>   -----
>   Update from Schematic...
>   Revert
>     To Saved
>     To Backup                            // Don't know the action to
> fill in here. Is this implemented in the core already?

I think this is source control's job. One of the points made in the
file-format discussion was that we want something more diff-friendly.
Git integration would be cool, but that certainly doesn't belong in
the core.

>   -----
>   Calibrate Printer...  (or perhaps 'Page Setup' when there will be
> a new page-setup-dialog)
>   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)

A first step to this would be to create (or find) a decent unified
API for storing user settings and data under the ~/.pcb directory.

>   -----
>   // Here was the 'Preferences'-entry. I think we can move it to
> 'Edit' (as also suggested in the ghi-guidelines) to make this menu
> shorter
>   Close layout           Ctrl-W          // if and when multiple
> layouts are supported ;-)
>   Close all layouts                      // if and when multiple
> layouts are supported ;-)
>   Quit                   Ctrl+Q
>
> 
> These are my thoughts about the file-menu. Perhaps, you have some
> more comments or other hints?
>

Our menu system is pretty goofy right now. In cleaning it up, we
have to consider a few things:

  1. Default keybindings (of course) and menu structure (of course)
  2. Customizable keybindings
  3. Customizable menus
  4. Dockable menus, toolbars, etc
  5. Command-mode improvements.
  6. Removal of unused menu items

It's such a pain to use the pcb menu right now for anything serious,
I don't think anybody really does. Fixing up the command mode should
be an equal priority, if not bigger.

As for the command mode:
  1. Tab-completion (huge)
  2. Callback (a little clunky now)
  3. Escape/lost focus should get out of command-mode
  4. Output display
    4a. For internal commands a single line could be shown in the status bar
    4b. For lots of output, a log panel built into pcb would be nice
    4c. However, this needs to be 100% out of the way when not in use
  5. External application support (similar in vi how you can do :!make or
     :!pdflatex %).


Andrew
 


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user