Re: gEDA-user: gschem handles are tied to schematic size, not screen size
On Tue, Jun 9, 2009 at 8:50 PM, Peter Cliftonpc...@cam.ac.uk wrote: On Tue, 2009-06-09 at 21:39 -0400, DJ Delorie wrote: Perhaps some combination of world size, pixel size, and relative-to-the-line size ranges with rules about which ones have priority? Then you get mostly consistent handles, with limits on how big/small they can get relative to usability - I.e. if the width of the handle had an upper limit of 50% the length of the line so that half the line is always exposed between the two handles, and a lower limit of 3x the thickness of the line so that it was never obscured, you could otherwise say keep the handles some fixed number of pixels, constrained by those limits, and it would always be usable. That might do it.. I remember why it doesn't work with fixed pixel sizes now.. the red cue dot on the end of the line eats the grip when you zoom in to do detailed work. The line width isn't actually issue unless you're drawing some fat lines. I see that this might be an annoyance with my patch. I solved it by editing my $GEDA/share/gEDA/gschem-colormap-darkbg: - (net-endpoint #ff) + (net-endpoint #ffa0) A bit hacky, but works OK in practice. I think it's better to not mess with the cue size, because it affords a visual reference to how zoomed-in you are. Obligatory screenshot: http://vivara.net/images/gschem_cue_grip.png Regards, Mark markra...@gmail -- Mark Rages, Engineer Midwest Telecine LLC markra...@midwesttelecine.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem handles are tied to schematic size, not screen size
On Thu, Jun 11, 2009 at 1:00 AM, Mark Ragesmarkra...@gmail.com wrote:
I see that this might be an annoyance with my patch. I solved it by
editing my $GEDA/share/gEDA/gschem-colormap-darkbg:
- (net-endpoint #ff)
+ (net-endpoint #ffa0)
A bit hacky, but works OK in practice. I think it's better to not
mess with the cue size, because it affords a visual reference to how
zoomed-in you are.
Obligatory screenshot: http://vivara.net/images/gschem_cue_grip.png
This patch also fixes it in a less-hacky way (no alpha required). It
simply draws grips back over the cue dots so they don't become
obscured.
Regards,
Mark
markra...@gmail
--
Mark Rages, Engineer
Midwest Telecine LLC
markra...@midwesttelecine.com
diff --git a/gschem/include/gschem_defines.h b/gschem/include/gschem_defines.h
index cd34528..a849436 100644
--- a/gschem/include/gschem_defines.h
+++ b/gschem/include/gschem_defines.h
@@ -31,6 +31,7 @@
#define GRIP_SIZE3 80
#define SMALL_ZOOMFACTOR1 150
#define SMALL_ZOOMFACTOR2 30
+#define MAXIMUM_GRIP_PIXELS 30
/* for bus_ripper_type */
#define COMP_BUS_RIPPER 0
diff --git a/gschem/src/o_cue.c b/gschem/src/o_cue.c
index f5daa76..e465539 100644
--- a/gschem/src/o_cue.c
+++ b/gschem/src/o_cue.c
@@ -56,6 +56,10 @@ void o_cue_redraw_all (GSCHEM_TOPLEVEL *w_current, GList *list, gboolean draw_se
w_current-toplevel-DONT_REDRAW = 0 || redraw_state;
}
o_cue_draw_single(w_current, o_current);
+
+ if (o_current-selected w_current-draw_grips) {
+ o_line_draw_grips (w_current, o_current);
+ }
break;
case(OBJ_COMPLEX):
diff --git a/gschem/src/o_grips.c b/gschem/src/o_grips.c
index d6db1bb..49f0e42 100644
--- a/gschem/src/o_grips.c
+++ b/gschem/src/o_grips.c
@@ -1544,7 +1544,7 @@ void o_grips_end_bus(GSCHEM_TOPLEVEL *w_current, OBJECT *o_current, int whichone
* and height of a grip in screen units.
*
* BGRIP_SIZE1/B and BGRIP_SIZE2/B and BGRIP_SIZE3/B are macros defined
- * in libgeda #defines.h. They are the half width/height of a grip in
+ * in gschem_defines.h. They are the half width/height of a grip in
* world unit for a determined range of zoom factors.
*
* \param [in] w_current The GSCHEM_TOPLEVEL object.
@@ -1566,8 +1566,8 @@ int o_grips_size(GSCHEM_TOPLEVEL *w_current)
/* small zoom factor : big size converted to screen unit */
size = SCREENabs (w_current, GRIP_SIZE3);
}
-
- return size;
+
+ return min(size, MAXIMUM_GRIP_PIXELS/2);
}
/*! \brief Draw grip centered at Bx/B, By/B
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem handles are tied to schematic size, not screen size
On Tue, Jun 9, 2009 at 8:35 PM, Peter Cliftonpc...@cam.ac.uk wrote: On Tue, 2009-06-09 at 20:16 -0500, Mark Rages wrote: If a line is selected, a square-shaped handle appears on each end. However, when I zoom in these handles become bigger. This defeats the point of zooming in, because it remains extremely difficult select the small lines among all the overlapping handles. I think there was some reason it wasn't done as a fixed screen size, although I seem to remember trying to change it to fixed size screen coords myself. It is somewhat defeated when you zoom way in and the grip is swallowed up by a huge line - but then I guess that isn't exactly normal use. Have a play with it yourself to see if you can find a behaviour which suits you. OK, here's my patch, which just sets a hard limit on the screen size of the grips. Before: http://vivara.net/images/huge_grips.png After: http://vivara.net/images/smaller_grips.png This small change is a big usability improvement for me. Regards, Mark markra...@gmail -- Mark Rages, Engineer Midwest Telecine LLC markra...@midwesttelecine.com diff --git a/gschem/include/gschem_defines.h b/gschem/include/gschem_defines.h index cd34528..a849436 100644 --- a/gschem/include/gschem_defines.h +++ b/gschem/include/gschem_defines.h @@ -31,6 +31,7 @@ #define GRIP_SIZE3 80 #define SMALL_ZOOMFACTOR1 150 #define SMALL_ZOOMFACTOR2 30 +#define MAXIMUM_GRIP_PIXELS 30 /* for bus_ripper_type */ #define COMP_BUS_RIPPER 0 diff --git a/gschem/src/o_grips.c b/gschem/src/o_grips.c index d6db1bb..49f0e42 100644 --- a/gschem/src/o_grips.c +++ b/gschem/src/o_grips.c @@ -1544,7 +1544,7 @@ void o_grips_end_bus(GSCHEM_TOPLEVEL *w_current, OBJECT *o_current, int whichone * and height of a grip in screen units. * * BGRIP_SIZE1/B and BGRIP_SIZE2/B and BGRIP_SIZE3/B are macros defined - * in libgeda #defines.h. They are the half width/height of a grip in + * in gschem_defines.h. They are the half width/height of a grip in * world unit for a determined range of zoom factors. * * \param [in] w_current The GSCHEM_TOPLEVEL object. @@ -1566,8 +1566,8 @@ int o_grips_size(GSCHEM_TOPLEVEL *w_current) /* small zoom factor : big size converted to screen unit */ size = SCREENabs (w_current, GRIP_SIZE3); } - - return size; + + return min(size, MAXIMUM_GRIP_PIXELS/2); } /*! \brief Draw grip centered at Bx/B, By/B ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem handles are tied to schematic size, not screen size
On Wed, 10 Jun 2009 02:58:38 -0500, Mark Rages wrote: Before: http://vivara.net/images/huge_grips.png After: http://vivara.net/images/smaller_grips.png This small change is a big usability improvement for me. I'll second that. The whole concept of scaling handles is a pain. They should always stay at the same (configurable) screen size. ---(kaimartin)--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gschem handles are tied to schematic size, not screen size
I am working on some intricate gschem symbols. If a line is selected, a square-shaped handle appears on each end. However, when I zoom in these handles become bigger. This defeats the point of zooming in, because it remains extremely difficult select the small lines among all the overlapping handles. Can this behavior be changed, so the boxes are scaled relative to my screen? Regards, Mark markra...@gmail -- Mark Rages, Engineer Midwest Telecine LLC markra...@midwesttelecine.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem handles are tied to schematic size, not screen size
On Tue, 2009-06-09 at 20:16 -0500, Mark Rages wrote: If a line is selected, a square-shaped handle appears on each end. However, when I zoom in these handles become bigger. This defeats the point of zooming in, because it remains extremely difficult select the small lines among all the overlapping handles. I think there was some reason it wasn't done as a fixed screen size, although I seem to remember trying to change it to fixed size screen coords myself. It is somewhat defeated when you zoom way in and the grip is swallowed up by a huge line - but then I guess that isn't exactly normal use. Have a play with it yourself to see if you can find a behaviour which suits you. gschem/src/o_grips.c: ~line 1553, is a function: int o_grips_size(GSCHEM_TOPLEVEL *w_current) Which returns _half_ the desired grip size in pixels. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem handles are tied to schematic size, not screen size
Perhaps some combination of world size, pixel size, and relative-to-the-line size ranges with rules about which ones have priority? Then you get mostly consistent handles, with limits on how big/small they can get relative to usability - I.e. if the width of the handle had an upper limit of 50% the length of the line so that half the line is always exposed between the two handles, and a lower limit of 3x the thickness of the line so that it was never obscured, you could otherwise say keep the handles some fixed number of pixels, constrained by those limits, and it would always be usable. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem handles are tied to schematic size, not screen size
On Tue, 2009-06-09 at 21:39 -0400, DJ Delorie wrote: Perhaps some combination of world size, pixel size, and relative-to-the-line size ranges with rules about which ones have priority? Then you get mostly consistent handles, with limits on how big/small they can get relative to usability - I.e. if the width of the handle had an upper limit of 50% the length of the line so that half the line is always exposed between the two handles, and a lower limit of 3x the thickness of the line so that it was never obscured, you could otherwise say keep the handles some fixed number of pixels, constrained by those limits, and it would always be usable. That might do it.. I remember why it doesn't work with fixed pixel sizes now.. the red cue dot on the end of the line eats the grip when you zoom in to do detailed work. The line width isn't actually issue unless you're drawing some fat lines. In addition, the fixed size swamps the line when you zoom out to do high-level moves. FWIW, the current code already has 3 different handle sizes - selected depending on zoom level. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem handles are tied to schematic size, not screen size
Mark Rages wrote: I am working on some intricate gschem symbols. If a line is selected, a square-shaped handle appears on each end. However, when I zoom in these handles become bigger. This defeats the point of zooming in, because it remains extremely difficult select the small lines among all the overlapping handles. Can this behavior be changed, so the boxes are scaled relative to my screen? Or, rather, that the box sizes are visually the same regardless of the zoom level? E.g. the same pixel dimensions? b.g. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
