Re: gEDA-user: Please test new grids for GTK PCB
On Thu, 10 Mar 2011 09:16:08 +0100, Krzysztof Kościuszkiewicz wrote: 2011/3/10 jpka jo...@kvidex.ru: Great! Thank you :) The last question is, when i find correct callback signature, passed arguments absolutely cannot be modified in any way, including adding random arguments, right? You can pass whatever you want (if it is known at callback registration time) as gpointer user_data. For example create a structure to hold pointers to everything you need in callback, then pass pointer to that structure as user_data. Of course the structure must not be allocated on stack. So after some more retries and hair tearing, i understand that i unfortunately can't write anything for GTK in C from scratch, because i can't find any human-compatible logic in all information i read, in part of writing callback procedures. :/ Well, negative result is also result. I will continue my work of course, in all places when possible, but most interesting (and most awaiting and welcomed) part, GUI writing, is weak and incomplete in my implementation, sorry. Thanks;) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Please test new grids for GTK PCB
2011/3/10 jpka jo...@kvidex.ru: Great! Thank you :) The last question is, when i find correct callback signature, passed arguments absolutely cannot be modified in any way, including adding random arguments, right? You can pass whatever you want (if it is known at callback registration time) as gpointer user_data. For example create a structure to hold pointers to everything you need in callback, then pass pointer to that structure as user_data. Of course the structure must not be allocated on stack. -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Please test new grids for GTK PCB
On Fri, 04 Mar 2011 02:17:35 +0100, Krzysztof Kościuszkiewicz wrote: Please check the attached patch - now everything in the model is updated correctly. Works well, thank you! I will post it soon on Launchpad https://bugs.launchpad.net/pcb/+bug/724154 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Please test new grids for GTK PCB
Hi! On Thu, 03 Mar 2011 15:39:22 +0100, Krzysztof Kościuszkiewicz wrote: I was asking why in the model you keep strings and not ints/floats? I don't know if i can directly place user-editable numeric values into treeview, instead of strings, it's possible? This is due to absence of examples: all treeview's C code samples found (with user-editing) are text/string. But also it's due to probably in future, user input can be in form '50 mil' or '2e3 mkm', i don't know useful it or no, but currently it can be easy added. custom implementation of GtkTreeModel ... It can work only in my dreams, because currently i even don't know how to write gtk callback procedure header...:( Example: I need to write Set by Mark Distance button press procedure (as you see, currently tied to dummy write (and it work well :D ) ) I copypaste your new cb_edited_mm_or_mil proc, because *it has access to treeview items* and contains all i need; only small modifications need. I don't touch the header because i don't know how to rewrite it correctly: /(GtkCellRendererText *cell, gchar *path, gchar *text, GtkTreeView *treeview)/ but it tied not here / g_signal_connect(renderer, edited, (GCallback) cb_edited_mm_or_mil, treeview);/ but i place it here : / ghid_button_connected (hbox_btn_grids, NULL, FALSE, FALSE, FALSE, 4, cb_grid_setbymarkdistance, NULL, _(Set by Mark Distance), ../ and it of course not work: program crashes silently, no any debug info, no way to read anything or things how to rewrite the header, no suitable examples... compiles without warnings. Each signal handler has its required signature. This can be found in the GTK docs. Is there any success-story about it or example using docs IRL ? Thanks! :) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Please test new grids for GTK PCB
On Wed, Mar 09, 2011 at 11:39:36AM +, jpka wrote: Each signal handler has its required signature. This can be found in the GTK docs. Is there any success-story about it or example using docs IRL ? The success story would look like: 1) Look up the function ghid_button_connected() 2) the function creates a GtkButton b and calls: if (cb_func) gtk_signal_connect (GTK_OBJECT (b), clicked, GTK_SIGNAL_FUNC (cb_func), data); 3) Hence you look up signal clicked in GtkButton http://library.gnome.org/devel/gtk/unstable/GtkButton.html#GtkButton-clicked 4) There you find correct callback signature: void user_function (GtkButton *button, gpointer user_data); -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Please test new grids for GTK PCB
On Wed, 09 Mar 2011 21:52:15 +0100, Krzysztof Kościuszkiewicz wrote: The success story would look like: ... Great! Thank you :) The last question is, when i find correct callback signature, passed arguments absolutely cannot be modified in any way, including adding random arguments, right? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Please test new grids for GTK PCB
2011/3/3 jpka jo...@kvidex.ru: There's no need to write a callback; default one will refresh the GtkTreeView widget to include your changes to the model. Please have a look at the attached patch. Thanks for help! Both codes work well in case of initial drawing radiobuttons instead of string, and result looks good. But in case of user input, when i apply this patch, i fall into several problems. 1. If i use patch 'as is', editing of grid values not work: my 'cb_edited_mm_or_mil' assumes PCB-CurrentGrid already changed to current before call: it uses PCB-Grid[PCB-CurrentGrid] = . , but when i use patch, editing value in table not switch PCB- CurrentGrid: it was tied to treeview row selection before and was done before editing (it was when i place cursor on needed row), but now it's not true: when i select row but not touch toggle button, PCB-CurrentGrid not updates. And anyway i prefer use radiobuttons here only for display but not for callback. BUT... Okay, I missed that part :) I would decouple changing the grid from editing the grid settings. The editing callbacks can query the path in the model and update PCB-Grid directly. The ultimate (but also most time consuming) would be to provide a custom implementation of GtkTreeModel that would map operations on the PCB-Grid and vice-versa. 2. If i try to restore my previous state when PCB-CurrentGrid updates not here g_signal_connect(renderer, toggled, (GCallback) cb_toggled_active, treeview); but here g_signal_connect(select, changed, G_CALLBACK(on_changed), select); (i.e. even work using cursor keys in treeview to select row) then i again and again fall into same hair-tearing problem as before this patch: ... Sorry for this long text. Each signal handler has its required signature. This can be found in the GTK docs. Same for the function passed to gtk_tree_view_foreach() etc. BTW2 - why do you store grid mm and mil spacings as strings?? Sorry i don't precisely understand you. The only place for strings in my code is in display/editing routines. Spacing is double PCB-Grid[PCB-CurrentGrid]; int PCB-GridStep[PCB-CurrentGrid]; regardless of mil or mm mode. I was asking why in the model you keep strings and not ints/floats? -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Please test new grids for GTK PCB
Please check the attached patch - now everything in the model is updated
correctly.
--
Krzysztof Kościuszkiewicz
Simplicity is the ultimate sophistication -- Leonardo da Vinci
From 9e58163f910c9e24ecd6400b2dc81e158c86152b Mon Sep 17 00:00:00 2001
From: Krzysztof Kosciuszkiewicz k.kosciuszkiew...@gmail.com
Date: Fri, 4 Mar 2011 02:14:53 +0100
Subject: [PATCH 2/2] hid/gtk: further improvements to new grid config
---
src/const.h |4 +-
src/hid/gtk/gtkhid-gdk.c |2 +
src/hid/gtk/gui-config.c | 116 -
3 files changed, 76 insertions(+), 46 deletions(-)
diff --git a/src/const.h b/src/const.h
index 7b952f8..8062569 100644
--- a/src/const.h
+++ b/src/const.h
@@ -71,8 +71,8 @@
#define COOR_TO_MM 0.000254000
#define MM_TO_COOR 3937.007874
-#define COOR_TO_MIL 1. / 100 //added 02.02.2011 for uniformity
-#define MIL_TO_COOR 100. / 1
+#define COOR_TO_MIL 0.01 //added 02.02.2011 for uniformity
+#define MIL_TO_COOR 100.0
enum// Currently not used except mil and mm, but i will
{ // become happy if at least microns can be added.
MIL = 0, // Major code changes in some places need for this, though.
diff --git a/src/hid/gtk/gtkhid-gdk.c b/src/hid/gtk/gtkhid-gdk.c
index 55951e4..c78d1e8 100644
--- a/src/hid/gtk/gtkhid-gdk.c
+++ b/src/hid/gtk/gtkhid-gdk.c
@@ -132,6 +132,8 @@ ghid_draw_grid (void)
if (d==0) { // static grid without any check to min distance, zooming, etc,
// made by request
+if (g == 0)
+ return;
gridmode = 1;
pcbgrid = g;
} else {
diff --git a/src/hid/gtk/gui-config.c b/src/hid/gtk/gui-config.c
index e864da1..1cb82ae 100644
--- a/src/hid/gtk/gui-config.c
+++ b/src/hid/gtk/gui-config.c
@@ -1352,45 +1352,74 @@ enum
NUM_COLS
} ;
-void cb_edited_mm_or_mil(GtkCellRendererText *cell, gchar *path, gchar *text,
- GtkTreeView *treeview) {
- double d;
- GtkListStore *store;
- GtkTreeIter iter;
- int units;
- store = GTK_LIST_STORE (gtk_tree_view_get_model (treeview));
- gtk_tree_model_get_iter_from_string (GTK_TREE_MODEL (store), iter, path);
- units = (GPOINTER_TO_INT (g_object_get_data (G_OBJECT (cell), column)) == 0) ? MM : MIL;
-printf(%d\n,units);
- d = c_strtod(text);
- if (d0) {d=0;}
- PCB-Grid[PCB-CurrentGrid] = (units) ? (d * MM_TO_COOR) : (d * MIL_TO_COOR);
- if (Settings.DrawGrid) UpdateAll ();
- ghid_set_status_line_label();
- gtk_list_store_set (store, iter, COL_GRID_MM, (units) ? (c_dtostr(d)) : (c_dtostr(d*MIL_TO_MM)), -1);
- gtk_list_store_set (store, iter, COL_GRID_MIL, (units) ? (c_dtostr(d*MM_TO_MIL)) : (c_dtostr(d)), -1);
-}
-
-
-void cb_edited_step(GtkCellRendererText *cell, gchar *path, gchar *text, GtkTreeView *treeview) {
- int i;
- GtkListStore *store;
- GtkTreeIter iter;
- store = GTK_LIST_STORE (gtk_tree_view_get_model (treeview));
- gtk_tree_model_get_iter_from_string (GTK_TREE_MODEL (store), iter, path);
- i=(int)c_strtod(text);
- if (i0) {i=0;}
-if (i==1) {i=2;}
- if (i100) {i=100;}
- PCB-GridStep[PCB-CurrentGrid] = i;
- if (Settings.DrawGrid) UpdateAll ();
-// ghid_set_status_line_label();
- gtk_list_store_set (store, iter, COL_GRIDSTEP, i, -1);
+void cb_edited_mm_or_mil (GtkCellRendererText *cell,
+ gchar *path,
+ gchar *text,
+ GtkTreeView *treeview)
+{
+ GtkTreeModel *model = gtk_tree_view_get_model (treeview);
+ GtkTreePath *treePath = gtk_tree_path_new_from_string (path);
+ int gridNum = CLAMP (gtk_tree_path_get_indices (treePath)[0],
+ 0,
+ MAX_USER_GRIDS-1);
+ gboolean unitsMm;
+ GtkTreeIter iter;
+ double d;
+
+ unitsMm = GPOINTER_TO_INT (g_object_get_data (G_OBJECT (cell), column)) == COL_GRID_MM;
+ d = MAX (0, c_strtod(text));
+ PCB-Grid[gridNum] = (unitsMm) ? (d * MM_TO_COOR) : (d * MIL_TO_COOR);
+
+ if (gridNum == PCB-CurrentGrid) {
+if (Settings.DrawGrid)
+ UpdateAll ();
+ghid_set_status_line_label();
+ }
+
+ gtk_tree_model_get_iter (model, iter, treePath);
+ /* two separate calls because c_dtostr() uses static buffer */
+ gtk_list_store_set (GTK_LIST_STORE (model), iter,
+ COL_GRID_MM, unitsMm ? c_dtostr(d) : c_dtostr(d*MIL_TO_MM),
+ -1);
+ gtk_list_store_set (GTK_LIST_STORE (model), iter,
+ COL_GRID_MIL, unitsMm ? c_dtostr(d*MM_TO_MIL) : c_dtostr(d),
+ -1);
+ gtk_tree_model_row_changed (model, treePath, iter);
+ gtk_tree_path_free (treePath);
+}
+
+
+void cb_edited_step (GtkCellRendererText *cell,
+ gchar *path,
+ gchar *text,
+ GtkTreeView *treeview)
+{
+ GtkTreeModel *model = gtk_tree_view_get_model (treeview);
+ GtkTreePath *treePath = gtk_tree_path_new_from_string (path);
+ int gridNum = CLAMP (gtk_tree_path_get_indices (treePath)[0],
+ 0,
+
Re: gEDA-user: Please test new grids for GTK PCB
Am 28.02.2011 11:48, schrieb jpka: * the Yes is not updated also when grid changes via keypress while preferences dialog is active * maybe Yes as string column can be replaced with gboolean and a GtkCellRendererToggle? Or a custom renderer if really needed. Or a selection could be updated on change of grid. *Please help me with it.* GTK docs is not helpful for me (it's for guru?), so only complete code examples i can use, but there is total lack of useful examples on internet.:( Hello jpka! I don't know how to fix the probem with updating the 'Yes'. But as a starting point I have changed the string 'Yes' to these radio-buttons. It is done by the following changes in src/gui-config.c: create_grid_treeview(): in the for-loop: ... COL_GRIDSTEP, PCB-GridStep[i], COL_GRIDCURRENT, (i == PCB-CurrentGrid) ? TRUE:FALSE, -1); ... Replace the last text-renderer (line 1478) by this code: renderer = gtk_cell_renderer_toggle_new(); gtk_cell_renderer_toggle_set_radio(renderer, true); gtk_cell_renderer_toggle_set_activatable(renderer, true); gtk_tree_view_insert_column_with_attributes (GTK_TREE_VIEW (treeview), -1, Current?, renderer, active, COL_GRIDCURRENT, NULL); Hope, this code is helpful for you. Kind regards! Felix ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Please test new grids for GTK PCB
On Mon, Feb 28, 2011 at 10:48:50AM +, jpka wrote:
Krzysztof Kościuszkiewicz wrote:
* to have GtkTreeView updated you need to emit
row-changed signal, like:
gtk_tree_model_row_changed (GTK_TREE_MODEL (model), path, iter);
I find it, but unfortunately i can't write callback function correct
(don't know or even can't imagine which arguments i must pass, i need
complete
example)
There's no need to write a callback; default one will refresh the
GtkTreeView widget to include your changes to the model.
Please have a look at the attached patch.
BTW - selecting a grid that does have 0 spacing segfaults pcb.
BTW2 - why do you store grid mm and mil spacings as strings??
--
Krzysztof Kościuszkiewicz
Simplicity is the ultimate sophistication -- Leonardo da Vinci
From 73574b2f6d6736257bf22c9683ba2b9a45196a03 Mon Sep 17 00:00:00 2001
From: Krzysztof Kosciuszkiewicz k.kosciuszkiew...@gmail.com
Date: Thu, 3 Mar 2011 01:12:06 +0100
Subject: [PATCH] hid/gtk: improvements to grid preferences window
---
src/hid/gtk/gui-config.c | 76 ++---
1 files changed, 37 insertions(+), 39 deletions(-)
diff --git a/src/hid/gtk/gui-config.c b/src/hid/gtk/gui-config.c
index 9eacfc0..e864da1 100644
--- a/src/hid/gtk/gui-config.c
+++ b/src/hid/gtk/gui-config.c
@@ -1394,42 +1394,42 @@ void dummy (void) {
}
-void on_changed(GtkWidget *widget)
-//void on_changed(GtkWidget *widget, gpointer treeview)
-{
- GtkTreeIter iter;
- GtkTreeModel *model;
- GtkTreePath *path;
- gint *indexes;
- //GtkListStore *store;
- int i;
-
- if (gtk_tree_selection_get_selected(
- GTK_TREE_SELECTION(widget), model, iter)) {
-path = gtk_tree_model_get_path(model, iter);
-indexes = gtk_tree_path_get_indices(path);
-i = indexes[0];
-if (i0) i = 0;
-if (i(MAX_USER_GRIDS-1)) i = MAX_USER_GRIDS-1;
-//g_print(Row number %i selected.\n, i); /* FIXME remove after debug */
- PCB-CurrentGrid = i;
-
- if (Settings.DrawGrid) UpdateAll ();
- ghid_set_status_line_label();
-
-/* FIXME */ g_print(Please fixme: \n
- here's word 'Yes' must be placed at 'Current?' column and (i) line, \n
- but i can't find a way to do it after a day fighting with gtk and hair tearing...\n);
-
-// store = GTK_LIST_STORE (gtk_tree_view_get_model (GTK_TREE_VIEW (treeview)));
-// gtk_tree_model_get_iter_from_string (GTK_TREE_MODEL (store), iter, path);
-// gtk_list_store_set (store, iter, COL_GRIDCURRENT, Yes, -1);
-
+static gboolean refresh_gridcurrent (GtkTreeModel *model,
+ GtkTreePath *path,
+ GtkTreeIter *iter,
+ gpointer data)
+{
+ GtkTreePath *selectedPath = (GtkTreePath*) data;
+ gtk_list_store_set (GTK_LIST_STORE (model),
+ iter,
+ COL_GRIDCURRENT,
+ gtk_tree_path_compare (path, selectedPath) == 0 ? TRUE : FALSE,
+ -1);
+ gtk_tree_model_row_changed (model, path, iter);
+ return FALSE;// continue iterating
+}
+
+
+static void cb_toggled_active (GtkCellRendererToggle *cell,
+ gchar *path_string,
+ GtkTreeView *view)
+{
+ GtkTreePath *path = gtk_tree_path_new_from_string (path_string);
+ gint *indices = gtk_tree_path_get_indices (path);
+ int i = CLAMP (indices[0], 0, MAX_USER_GRIDS-1);
+ if (PCB-CurrentGrid != i) {
+PCB-CurrentGrid = i;
+if (Settings.DrawGrid)
+ UpdateAll ();
+ghid_set_status_line_label();
+gtk_tree_model_foreach (gtk_tree_view_get_model (view),
+refresh_gridcurrent,
+path);
}
+ gtk_tree_path_free (path);
}
-
static GtkWidget *create_grid_treeview (void) {
GtkCellRenderer *renderer;
GtkTreeView *treeview;
@@ -1439,7 +1439,7 @@ static GtkWidget *create_grid_treeview (void) {
int i;
char /*y[256],*/y2[256]; /* FIXME remove this ugly stuff */
- store = gtk_list_store_new (NUM_COLS, G_TYPE_STRING, G_TYPE_STRING, G_TYPE_UINT, G_TYPE_STRING);
+ store = gtk_list_store_new (NUM_COLS, G_TYPE_STRING, G_TYPE_STRING, G_TYPE_UINT, G_TYPE_BOOLEAN);
for (i=0; iMAX_USER_GRIDS; i++) {
// strcpy(y, c_dtostr((PCB-Grid[i])*COOR_TO_MM));
strcpy(y2, c_dtostr((PCB-Grid[i]*COOR_TO_MIL)));
@@ -1449,12 +1449,18 @@ static GtkWidget *create_grid_treeview (void) {
// COL_GRID_MIL, c_dtostr((PCB-Grid[i])*COOR_TO_MIL), - not work! :(
COL_GRID_MIL, y2, // work but ugly...
COL_GRIDSTEP, PCB-GridStep[i],
- COL_GRIDCURRENT, (i == PCB-CurrentGrid) ? Yes:,
+ COL_GRIDCURRENT, (i == PCB-CurrentGrid) ? TRUE : FALSE,
-1);
}
treeview = GTK_TREE_VIEW (gtk_tree_view_new_with_model (GTK_TREE_MODEL(store)));
g_object_unref (store);
+ renderer = gtk_cell_renderer_toggle_new ();
Re: gEDA-user: Please test new grids for GTK PCB
https://bugs.launchpad.net/pcb/+bug/724154
Hi!
Thanks for your feedback.
I prepare and post newgrids.pcb-git-199z.v2.patch on Launchpad,
i make some bugfixes:
Felix Ruoff wrote:
Some comments (most of them for usability): - You often mention in the
tooltips the shortcut '^M'. At my system this should be 'Ctrl+M'. I
didn't know, that '^' is a short-cut for the Control key.
Fixed.
- At the menu-item 'Realign Grid by Mark' the b../b does not work.
The 'b' and '/b' is printed as text.
Formatting removed, but *i need help* to get work it as it must.
You introduces accelerators
for 'Zoom In 20%' and '.. OUT .. '. The keyname for plus and minus on
the numpad are 'KP_Add' and 'KP_Substract' (see:
http://git.gnome.org/browse/gtk+/plain/gdk/gdkkeysyms.h). I would
suggest to use the 'normal' plus and minus-signs because: a) I don't
have a keypad on my laptop, b) In the menu there is no distinguish
between the signs on the keypad and the normal buttons (at the right of
the menu-item is printed: 'Ctrl++' and 'Ctrl+-'). The Keynames for + and
- are 'plus' and 'minus'. (If the patch of LP:699493 will be applied,
you also can use '+' and '-' in the gpcb-menu.res file.)
I think best way is to support all three (Z/shift-Z, KP+/-, +/-).
*I need help* with it, because currently i only able to write some bad
code:
gpcb-menu.res
---
# guru, please correct below to get more than one key for one menu item:
# unfortunately, this not work:
# {Zoom In 20% Zoom(-1.2) m=Z a={+ Keyplus} a=
{KeyPadPlus KeyKP_Add}a={Z Keyz} }
# {Zoom Out 20% Zoom(+1.2) m=O a={- Keyminus} a=
{KeyPadMinus KeyKP_Subtract} a={Shift-Z ShiftKeyz}}
# so i use extremely ugly workaround:,
{Zoom In 20% Zoom(-1.2) m=Z a={+
Keyplus} }
{ Zoom(-1.2) m=Za={KeyPadPlus
KeyKP_Add} }
{ Zoom(-1.2)
m=Z a={Z
Keyz} }
{Zoom Out 20% Zoom(+1.2) m=O a={-
Keyminus}
{ Zoom(+1.2) m=Oa={KeyPadMinus
KeyKP_Subtract} }
{ Zoom(+1.2)
m=O a=
{Shift-Z ShiftKeyz}}
---
This looks terrible in menu.
Where i can read more about this format of menu encoding ?
You are
modifying the file 'src/hid/common/hidlist.h' with your patch. For this
reason, the patch did not apply to my newly checked out repository. This
file is not avaiable if you have just cloned git. I think, it will be
created by autogen.sh or configure, I don't know.
Fixed (removed from patch).
Is there a
possibility to draw the dots of the grid, that are aligned with the dots
of the next grid in the colors of the next grid or a bit larger?
You mean next level of same grid when you zooming, or change to next/prev
grid
from user grid list without zooming?
- The new default grid colors are difficult to see on my displays. I
would suggest to use other colours by default.
I can't suggest any default color at all, i use some random default
values only
for test of my idea. I think final defaults must be set later by
authors/maintainers.
Anyway, you can easy change all grid colors via menu.
Colin D Bennett wrote:
Actually I would prefer not to have the grid color vary as I zoom -- I
already have the main colors I can differentiate used for other things
in the color scheme -- but then I guess I would prefer the grid size not
to vary either. Maybe if the color stayed the same
You can easy set identical grid colors via menu.
but the dots were
drawn larger when you zoom out, that would be a better way to indicate
that your snap-grid is not the same as your visible-grid.
I currently don't have enough GTK skills to form anything except depault
dots
(pixels) but if anybody help me i'll be happy. As you see, even currently
draw grid procedure after my modification is looks very weak and must be
rewritten by guru.
(If you don't understand my objection to using a bunch of colors for
grid points, consider that there are only so many useful colors to use;
in my current color scheme I use red, blue, yellow, green, and white for
primary copper layer, secondary copper layer, selected items, pads, and
silk respectively.)
I sure increasing colors q'ty not good for most people, it was only
test :)
(but for me, it is o.k.) Again, all colors is user-redefinable.
Krzysztof Kościuszkiewicz wrote:
* mark disappears (is not redrawn?) when active grid is changed in the
preferences window
I can't reproduce that my mark (pink diamond) disappears.
But mark which already exist before me, that's red X cross Mark (Ctrl
+M),
sometimes disappears, this is normal (written in code by authors of this
sign), but, yes, it's confusing when it disappears suddenly.
* to have
Re: gEDA-user: Please test new grids for GTK PCB
Steven Michalske wrote: Did not apply cleanly against git head at 359a02cfe25e32aec7d2985c8f368fbfdcd954fa Sorry i can't get it, but i check patch for errors on latest git tree available on time of post. (p.s. i'm too novice in git, can you give me exactly commands to set git head to your hash code and reproduce error?) If it applies to top of tree then great, FYI git checkout 359a02cfe25e32aec7d2985c8f368fbfdcd954fa This command will create a Detached head at that checksum. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Please test new grids for GTK PCB
On Thu, 24 Feb 2011 07:17:33 + (UTC) jpka jo...@kvidex.ru wrote: Hi! I prepare patch for new grid management, if you're interested please test it: https://bugs.launchpad.net/pcb/+bug/724154 The new grid support is fantastic. I love it. I did some editing of the UI text that you might find helpful; patch is attached it to the bug. I will definitely be looking forward to this showing up in mainline pcb. Thanks! Regards, Colin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Please test new grids for GTK PCB
Am 24.02.2011 08:17, schrieb jpka: I prepare patch for new grid management, if you're interested please test it: https://bugs.launchpad.net/pcb/+bug/724154 Thanks Hi, I have had a short test of your powerfull patch. I am not sure, if I shoud post my comments to the bug or the mailing list - I chose the list. Some comments (most of them for usability): - You often mention in the tooltips the shortcut '^M'. At my system this should be 'Ctrl+M'. I didn't know, that '^' is a short-cut for the Control key. - At the menu-item 'Realign Grid by Mark' the b../b does not work. The 'b' and '/b' is printed as text. - You introduces accelerators for 'Zoom In 20%' and '.. OUT .. '. The keyname for plus and minus on the numpad are 'KP_Add' and 'KP_Substract' (see: http://git.gnome.org/browse/gtk+/plain/gdk/gdkkeysyms.h). I would suggest to use the 'normal' plus and minus-signs because: a) I don't have a keypad on my laptop, b) In the menu there is no distinguish between the signs on the keypad and the normal buttons (at the right of the menu-item is printed: 'Ctrl++' and 'Ctrl+-'). The Keynames for + and - are 'plus' and 'minus'. (If the patch of LP:699493 will be applied, you also can use '+' and '-' in the gpcb-menu.res file.) - You are modifying the file 'src/hid/common/hidlist.h' with your patch. For this reason, the patch did not apply to my newly checked out repository. This file is not avaiable if you have just cloned git. I think, it will be created by autogen.sh or configure, I don't know. - Is there a possibility to draw the dots of the grid, that are aligned with the dots of the next grid in the colors of the next grid or a bit larger? - The new default grid colors are difficult to see on my displays. I would suggest to use other colours by default. I have not had a complete code review. But since now, everything works like expected. Thank you for your work! Kind regards, Felix ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Please test new grids for GTK PCB
On Thu, 24 Feb 2011 22:14:42 +0100 Felix Ruoff fe...@posaunenmission.de wrote: Am 24.02.2011 08:17, schrieb jpka: I prepare patch for new grid management, if you're interested please test it: https://bugs.launchpad.net/pcb/+bug/724154 Thanks Hi, I have had a short test of your powerfull patch. I am not sure, if I shoud post my comments to the bug or the mailing list - I chose the list. Some comments (most of them for usability): - You often mention in the tooltips the shortcut '^M'. At my system this should be 'Ctrl+M'. I didn't know, that '^' is a short-cut for the Control key. I attached a patch to the bug with my UI text edits, including consistent use of Ctrl+M, G, etc. to refer to keys in the same was as the GTK menu item shortcuts. - You are modifying the file 'src/hid/common/hidlist.h' with your patch. For this reason, the patch did not apply to my newly checked out repository. This file is not avaiable if you have just cloned git. I think, it will be created by autogen.sh or configure, I don't know. I had this same problem (clean git tree also) and just deleted the .rej etc. files and it was fine. - Is there a possibility to draw the dots of the grid, that are aligned with the dots of the next grid in the colors of the next grid or a bit larger? - The new default grid colors are difficult to see on my displays. I would suggest to use other colours by default. Actually I would prefer not to have the grid color vary as I zoom -- I already have the main colors I can differentiate used for other things in the color scheme -- but then I guess I would prefer the grid size not to vary either. Maybe if the color stayed the same but the dots were drawn larger when you zoom out, that would be a better way to indicate that your snap-grid is not the same as your visible-grid. (If you don't understand my objection to using a bunch of colors for grid points, consider that there are only so many useful colors to use; in my current color scheme I use red, blue, yellow, green, and white for primary copper layer, secondary copper layer, selected items, pads, and silk respectively.) Regards, Colin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Please test new grids for GTK PCB
Colin D Bennett wrote: (If you don't understand my objection to using a bunch of colors for grid points, consider that there are only so many useful colors to use; in my current color scheme I use red, blue, yellow, green, and white for primary copper layer, secondary copper layer, selected items, pads, and silk respectively.) +1 color differentiation should be reserved to more important aspects. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
