Re: gEDA-user: new footprint guidelines
FYI gerbv will put the xy file generated by pcb onto your gerbers. Steve On Sat, Oct 2, 2010 at 10:42 AM, Steven Michalske smichal...@gmail.com wrote: As you guys continue to debate this... Look at how pcb makes the xyrs data files. You'll findout that it generates it from the pcb file not the library. It takes the center of the part from the pins and pads. Then it puts pin 1 somewhere consistent. See the source for details. On Oct 2, 2010, at 5:55 AM, Rick Collins gnuarm.2...@arius.com wrote: At 05:34 PM 10/1/2010, you wrote: Rick Collins wrote: If for whatever reason the designer used 2 different footprints for the same part occuring several times on a board, if the footprints are position/rotation inconsisten... I have no idea why anyone would do that. Real world example: PhD student Foo designs some super noiseless detector circuit. The measurements turn out a success. Researcher Bar, a long time friend who works on some unrelated project, asks Foo for help to get him started on noiseless detector. PhD Foo gladly provides the schematic and layout. For his project Bar needs to add some minor features to the hardware. Of course, she uses a different local library than Foo ... Sure the designer can totally screw up a design. I wouldn't call this totally screwed. If you work on a design and use a different, incompatible library from the original without checking for consistency, yes, the designer totally screwed up. I really have no idea how things work in the gEDA/PCB world. With FreePCB the library has a default orientation for parts and there is a centroid vector to allow the pin 1 orientation to be set compatibly with the Gerber files. If you use someone else's design you need to verify that their library parts were done correctly or you need to use the same footprints which are a part of the layout and so are available. There is no reason to screw up something as simple as this. Oh, I almost forgot, NEVER ask a PhD anything to design PCBs. What the heck are you thinking??? Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: new footprint guidelines
How does that work? I'd like to try that. I guess it will only work for an XYRS file generated by PCB. What is that format? Maybe I can convert my XYRS file into that and check it. Rick At 03:56 AM 10/2/2010, you wrote: FYI gerbv will put the xy file generated by pcb onto your gerbers. Steve On Sat, Oct 2, 2010 at 10:42 AM, Steven Michalske smichal...@gmail.com wrote: As you guys continue to debate this... Look at how pcb makes the xyrs data files. You'll findout that it generates it from the pcb file not the library. It takes the center of the part from the pins and pads. Then it puts pin 1 somewhere consistent. See the source for details. On Oct 2, 2010, at 5:55 AM, Rick Collins gnuarm.2...@arius.com wrote: At 05:34 PM 10/1/2010, you wrote: Rick Collins wrote: If for whatever reason the designer used 2 different footprints for the same part occuring several times on a board, if the footprints are position/rotation inconsisten... I have no idea why anyone would do that. Real world example: PhD student Foo designs some super noiseless detector circuit. The measurements turn out a success. Researcher Bar, a long time friend who works on some unrelated project, asks Foo for help to get him started on noiseless detector. PhD Foo gladly provides the schematic and layout. For his project Bar needs to add some minor features to the hardware. Of course, she uses a different local library than Foo ... Sure the designer can totally screw up a design. I wouldn't call this totally screwed. If you work on a design and use a different, incompatible library from the original without checking for consistency, yes, the designer totally screwed up. I really have no idea how things work in the gEDA/PCB world. With FreePCB the library has a default orientation for parts and there is a centroid vector to allow the pin 1 orientation to be set compatibly with the Gerber files. If you use someone else's design you need to verify that their library parts were done correctly or you need to use the same footprints which are a part of the layout and so are available. There is no reason to screw up something as simple as this. Oh, I almost forgot, NEVER ask a PhD anything to design PCBs. What the heck are you thinking??? Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB: Change default file-filter in open-dialog
Hello,
here is (a first version) of my patch to store the last used file-filter
of the file-open-dialog. It recovers the last used filter-setting on
start-up of the file-open-dialog.
It uses GKeyFiles to store this information. I am not sure if this is a
good choice, because there already is something implemented to store
settings. But - I did not completely understand it. For this reason I
introduce this (new) g(tk)-type of setting-handling.
If the main-developer like this GKeyFiles, perhaps the actual
setting-handling can be migrated to use this functions. Perhaps - as
written, I have not understand the code completely - this will reduce
some code size (especially for the parser) and makes it easier for new
developer to understand the code. Perhaps, they had already used this
functions in other projects. If we will migrate to this GKeyFiles we
have to pay attention to storing double-values. This is only available
since GTK 2.12 :-(.
If the main-developer don't like this GKeyFiles, perhaps you can give me
a hint to a documentation of the actual system or a point where I can
easily start to learn it?
It would be very welcome to me, if some of you 'out there' can test my
patch and give some feedback!
Kind regards,
Felix
diff --git a/src/hid/gtk/gui-config.c b/src/hid/gtk/gui-config.c
index 36277eb..ab71072 100644
--- a/src/hid/gtk/gui-config.c
+++ b/src/hid/gtk/gui-config.c
@@ -176,6 +176,83 @@ static ConfigAttribute config_attributes[] = {
{layer-name-8, CONFIG_Unused, NULL},
};
+/*
+ * Get path for key-file
+ */
+const gchar*
+key_file_path()
+{
+ gchar *homedir;
+
+ homedir = (gchar *) g_get_home_dir ();
+ if (!homedir)
+{
+ g_message (key_file_path: Can't get home directory!);
+ return NULL;
+}
+
+ if (!config_dir)
+{
+ config_dir =
+g_build_path (G_DIR_SEPARATOR_S, homedir, PCB_CONFIG_DIR, NULL);
+ if (!g_file_test (config_dir, G_FILE_TEST_IS_DIR)
+ mkdir (config_dir, 0755) 0)
+{
+ g_message(key_file_path: Can't make \%s\ directory!,
+ config_dir);
+ g_free (config_dir);
+ config_dir = NULL;
+ return NULL;
+}
+}
+
+ return g_build_path (G_DIR_SEPARATOR_S, config_dir, gpcb_gui.conf, NULL);
+}
+
+/*
+ * Initialize GKeyFile-Stucture.
+ */
+void
+key_file_open() {
+ GKeyFileFlags flags;
+ GError *error = NULL;
+ const gchar *filepath;
+
+ /* Create a new GKeyFile object */
+ key_file = g_key_file_new ();
+ flags = G_KEY_FILE_KEEP_COMMENTS | G_KEY_FILE_KEEP_TRANSLATIONS;
+ g_key_file_set_list_separator (key_file, ';');
+
+ filepath = key_file_path();
+ if ((filepath == NULL
+ || g_key_file_load_from_file (key_file, filepath, flags, error) == FALSE))
+{
+ // If file not found, create a new file when saving.
+ // Therefore add comments at the beginning of the file here.
+ const gchar *comment;
+ comment = This file contains (gtk-gui-related) settings for pcb.\nYou can reset each setting to the default by removing the propreate key\nor delete the whole file to reset all values.;
+ g_key_file_set_comment(key_file, NULL, NULL, comment, NULL);
+}
+}
+
+/*
+ * Save keys to file.
+ */
+void
+key_file_save()
+{
+ GString *output;
+ const gchar* file = key_file_path();
+
+ if(file != NULL)
+{
+ output = g_string_new(g_key_file_to_data(key_file, NULL, NULL));
+ g_file_set_contents(file, output-str, output-len, NULL);
+ g_string_free(output, TRUE);
+}
+ g_key_file_free(key_file);
+}
+
static FILE *
config_file_open (gchar * mode)
@@ -697,6 +774,7 @@ ghid_config_files_read (gint * argc, gchar *** argv)
ghidgui = _ghidgui;
+ key_file_open();
ghid_config_init ();
load_rc_files ();
config_file_read ();
@@ -731,6 +809,8 @@ ghid_config_files_write (void)
FILE *f;
ConfigAttribute *ca;
+ key_file_save();
+
if (!ghidgui-config_modified || (f = config_file_open (w)) == NULL)
return;
diff --git a/src/hid/gtk/gui-dialog.c b/src/hid/gtk/gui-dialog.c
index ec91233..9c3d64e 100644
--- a/src/hid/gtk/gui-dialog.c
+++ b/src/hid/gtk/gui-dialog.c
@@ -270,6 +270,7 @@ ghid_dialog_file_select_open (gchar * title, gchar ** path, gchar * shortcuts)
gchar *result = NULL, *folder, *seed;
GHidPort *out = ghid_port;
GtkFileFilter *no_filter;
+ gint last_filter_index = 0;
dialog = gtk_file_chooser_dialog_new (title,
GTK_WINDOW (out-top_window),
@@ -298,6 +299,9 @@ ghid_dialog_file_select_open (gchar * title, gchar ** path, gchar * shortcuts)
gtk_file_filter_add_pattern (fp_filter, *.fp);
gtk_file_filter_add_pattern (fp_filter, *.FP);
gtk_file_chooser_add_filter (GTK_FILE_CHOOSER (dialog), fp_filter);
+if(g_key_file_get_integer(key_file, OpenDialog, FilterIndexLoadFootprint, NULL) == 1) {
+ gtk_file_chooser_set_filter(GTK_FILE_CHOOSER (dialog), fp_filter);
+}
}
/* in case we have a dialog for loading a layout file */
@@
gEDA-user: Modifications to the main-menu of PCB
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?
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.
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?
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.
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
Save Buffer to Footprint // Don't know if this 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?
-
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)
-
// 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?
Kind regards,
Felix
From 6863d938a06a5a1e425d61f2bdae5a3ebe257725 Mon Sep 17 00:00:00 2001
From: Felix Ruoff fe...@posaunenmission.de
Date: Sat, 2 Oct 2010 22:58:31 +0200
Subject: [PATCH] Add plus and minus to possible keyboard-shortcuts
Adds the possibility to use plus- and minus-keys for keyboard-shortcuts.
---
src/hid/gtk/gui-top-window.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/hid/gtk/gui-top-window.c b/src/hid/gtk/gui-top-window.c
index 9c30a93..e02bd03 100644
--- a/src/hid/gtk/gui-top-window.c
+++ b/src/hid/gtk/gui-top-window.c
@@ -3079,7 +3079,9 @@ static KeyTable key_table[] =
{'[', bracketleft},
{']', bracketright},
{'.', period},
-{'|', bar}
+{'|', bar},
+{'+', plus},
+{'-', minus}
};
static int n_key_table = sizeof (key_table) / sizeof (key_table[0]);
--
1.7.1
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Zero length pins
John Doty wrote: You and I have very different ideas of what constitutes good documentation. Your comment referred to me adding a note to the wiki. Since this list of tips does not aim to be the documentation of gschem, I fail to see your point. Is there any engineering culture that uses a system different from the latin-arabic system commonly used for this like this? You claimed radical flexibility as an indispensable ingredient. Now you argue, that nobody needs it ... But that's inconsistent with your view above. If I want my company logo on a schematic, I must import pixels: it's based on an astronomical image. It still does not fit the workflow. You pay for the less than optimum choice by the management. Even, if you are perfectly fine with fuzzy pixelized graphics it does not support your claim of flexibility. A flexible approach would allow the inclusion of vectorized graphics as vectorized objects. Hardly any logo is pixel based (for a reason). Similarly, the stick drawings you complain about are a consequence of using a vector format. not true, unless you call graphics like these stick figures: http://inkscape.org/screenshots/gallery/inkscape-0.45-cupoftea.png For example, printing to PDF via cups-pdf barfs on PNGs. But export of graphics to PS works pretty well in gEDA. Specialized tools need not and should not support every graphics format. Supporting a graphics feature with some standard output engines but not with others is trapping users. Other applications like gimp or eog have no trouble printing png images to cups-pdf. The way xfig incorporates LaTeX may be worth a closer look. That's real *inflexibility*. You've got a somewhat private definition of inflexibilty. With xfig you can choose to include latex formatted text or you can go with plain text in one of the default postscript fonts. With gschem you are confined to a single font. Formula typesetting is not available at all. Which of the two is more flexible? Users should not be required to use LaTeX, make, or any other specific tool, Neither do xfig users. but should be able to easily get gEDA to cooperate with these tools, Which is currently only marginally available. Export of a portable graphics format is a very weak form of cooperation. Import is only possible in a crippled pixelized way. ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Zero length pins
On Sun, 2010-10-03 at 00:08 +0200, kai-martin knaak wrote: but should be able to easily get gEDA to cooperate with these tools, Which is currently only marginally available. Export of a portable graphics format is a very weak form of cooperation. Import is only possible in a crippled pixelized way. ---)kaimartin(--- What is your intention? Should gschem support fancy svg graphics like inkscape? I guess that would make all very complicated. The basic gschem file format is very simple, lines, circles, arcs, rectangles... Current version supports pictures and simple paths, which is is more than necessary in my opinion. For me, tools should be not overloaded and fat, like OpenOffice and Mozilla. Keep the tools slim. gschem can never be a powerful svg editor -- loading in svg graphics may be possible, but I guess even simple manipulation like rotating oval arcs can be complicated. SVG export is easy with cairo, so we can import into inkscape. Indeed, a schematics mode for inkscape may be fine -- teaching inkscape to understand symbols, pins, nets, attributes. May be possible, but do we really need that? And a PCB mode, teaching it to watch for clearance, and do gerber export. Maybe I missed your real intention, I was not able to follow the whole discussion, sorry. Best regards Stefan Salewski ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Modifications to the main-menu of PCB
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
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
Re: gEDA-user: Modifications to the main-menu of PCB
Andrew Poelstra wrote: 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? IMHO, the more imortant goal is to have all actions available in the menu. There are still some actions that can only be reached via the command line interface. And then there are these command parameters that can't be set in the GUI... then the same effort needs to be done for gschem. Sure. And we should see to make the interfaces as compatible as possible. Save Buffer to Footprint // Don't know if this This item should stay save buffer to file. In addition to its use during footprint creation, it provides a way to save part of the layout for future use. 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. Still, there should be a way to save the buffer to file. Also, we should have a footprint mode. Yes, please. 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. True. But a simple revert to the last saved version is conceptually simple. It does not need any external software requirement, which is a good. Think windows versions, somebody preferring some other source control application, newbies not versed in source control at all... Note, currently revert has an important (mis-) use as a workaround for the absence of a better way to trigger polygon recalculation. Of course, this this a GUI-wart, that should be tackled, anyway. 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. currently, it is mangled with other settings in .pcb/preferences 1. Default keybindings (of course) and menu structure (of course) 2. Customizable keybindings Let Gnome do it. You can already customize keys on the fly the gnome way: Just enter the menu and type the desired key combo. It will instantly be the accel to the menu item. If it collides with some other menu accel, the other menu will be overruled. However, pcb currently does not save these settings. So they are lost at the end of the session. 3. Customizable menus There is a down side: A fixed menu provides an easy, universal way to communicate usage-howtos. (Choose Only_names from the settings menu) If every power user designs their own, private menu, this common ground would be lost. I have been there, seen that, with mechanical CAD. 4. Dockable menus, toolbars, etc Note, dockable is not friendly to multi monitor work places. 5. Command-mode improvements. 6. Removal of unused menu items I'd veto against this. There are very few menu items I haven't used, yet. By contrast, I'd advocate to make sure, all actions are available via the menu one way, or another. 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 %). How about a little embedded bash, enriched with pcb's action commands? This would give us all the above, real scripting and all the power the shell can deliver. Plus, documentation already spread on every unixoid box ;-) ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB: Change default file-filter in open-dialog
I don't like having gtk store settings in two different places, but I don't particularly care which one is used. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
