One metre interactive grid (long lat) superimposed on a map
by Philip Rhoades
People,
I have done a bit of Googling but am a little overwhelmed about where to
start but I thought Inkscape people might have a better idea. I want to
add an interactive 1 sqm grid to the attached plan. I have the original
as a SVG file but it is too large to attach - I imported it from a PDF
file for use in Inkscape. I want the grid to be square with longitude
and latitude (maybe the maybe should be rotated) such that people could
click a rectangle of squares to indicate a proposed new building lot on
the site.
Is SVG the right tool to build such an interactive map for a web page?
Thanks,
Phil.
--
Philip Rhoades
PO Box 896
Cowra NSW 2794
Australia
E-mail: phil@...2067...
5 years, 3 months
Survey: Default beabiour on clones with path operations
by Jabier Arraiza
Hi all:
I just commit a branch [1] that convert shapes and optinaly clones to
paths previously any of this path operations:
Booleans, Stroke to paths, Object to paths, Combine and Break Apart.
The cuestion is simple:
¿Whats is your prefered option about symbols? This is done in
preference section and can be change by the user, but we are speaking
about the default behabiour.
A: Convert to path clones and apply the operation
B: Retain clones in this operatios ignoring the operation
Thank for take time to reply.
[1] https://gitlab.com/inkscape/inkscape/merge_requests/159
5 years, 3 months
Spin slider widget, redux.
by Tavmjong Bah
Hi all,
I've taken into account all the feedback and have developed a little
test program that shows of a number of solutions to replacing the Gimp
Spin Scale widget.
A gzipped tar file of the source code is attached so that you can try
out the solutions (should be trivial to compile on Linux if you have
the Gtk3 libraries). Not all of the solutions fully work as I didn't
take the time to make them... but you should be able to get a feel for
them. If you run in debug mode (see README) you can interactively add
CSS. I've include an example CSS file you can paste into the debug
window (ignore the colors, they were just for experimenting).
I've also attached PNGs of the widgets with and without the extra CSS.
The five solutions, from top to bottom, are:
* Custom Gtk::Range widget couple with Gtk::Spinbutton:
This is my current favorite. It works quite well, methinks. Use the
'Alt' key to get into fine adjustment mode. It was rather simple to
implement. Could be refined further (add styling properties, rounded
corners, etc.).
* Gtk::Scrollbar coupled with Gtk::Spinbutton:
Works rather well, but doesn't show as well the current value. Using
a narrow "slider" prevents it from covering up the text (text not
implemented yet). I didn't know it before, but if one clicks on the
slider and doesn't move for a second or two it enters into a fine-
adjustment mode.
* Gkt::ProgressBar coupled with Gtk::Spinbutton:
CSS can get this looking pretty good but some extra work has to be
done as the ProgressBar doesn't have an "adjustment", the class that
actually handles tracking a value. The Gtk::Spinbutton actually
contains a ProgressBar but while one can style it via CSS one can't
directly access it and it overlaps the numerical entry part of the
SpinButton (this is how the Gimp widget works).
* Subclassed Gtk::Spinbutton:
This is essentially a modified version of the Gimp widget but it has
some major flaws as one cannot access the underlying widgets
(ProgressBar, Buttons). In this example, the built in ProgressBar is
disabled and new code that simulates a narrower ProgressBar has been
added. I could not fine a good way to calculate how much narrower the
new bar needs to be to not overlap the numerical entry part. Also, when
dragging the bar it is easy to highlight the numerical text. The code
to do all this is pretty messy.
* Gtk::Scale coupled with Gtk::Spinbutton:
CSS can make this look reasonable. Reducing the size of the circle
will prevent it from covering text (text not implemented yet).
Gtk::Scale also has a fine-adjustment mode accessed the same was as for
a scrollbar.
Tav
5 years, 3 months
Display and User units, Scaling, Measuring Paths, Importing PDF
by Philip Rhoades
People,
If I produce a new drawing on an A4 page with Display and User units in
mm with a scaling factor of 1.0, I can draw a rectangle of XxY and when
I use the Visualise->Measure Path Extension with a Scale Factor of 100
and Length Unit in m - I get exactly the right dimensions for the
rectangle for its perimeter length and area - all good!
However, I have imported a surveyor's map from a PDF file into SVG and I
need to be able to draw rectangles on it as above in mm (like my test)
that will correspond to m in the real world but the drawing is on an A1
page and the Display and User Units are in px and I have tried
everything I can think of and Googled a lot but I can't do what I was
able to do with my little test case.
So:
How can I convert the drawing to be on an A4 page with mm units so the
mm correspond to m and the Measure Path Extension will give me the
correct result in m and sqm?
The original PDF says the scale was 1:300.
Thanks,
Phil.
--
Philip Rhoades
PO Box 896
Cowra NSW 2794
Australia
E-mail: phil@...2067...
5 years, 3 months
Spin slider widget: Opinions needed!
by Tavmjong Bah
Hi,
I've been looking into replacing the Gimp Spin Slider widget (e.g
Blur/Opacity in the Fill and Stroke dialog). The widget is licensed
under GPLv3 and is the only reason Inkscape as a whole is licensed
under GPLv3 rather GPLv2.. The board sometime ago agree that being a
GPLv2 program was desirable (I don't remember the exact reasoning).
A normal Gtk Spin Slider (aka Gtk::SpinButton) has an option to show
the "progress" of slider, that is the percentage (defined in some
arbitrary way) between a minimum and maximum value. This in Gtk 2 is
shown as a solid blue bar with width proportional to the value that
covers the widget from top to bottom. In Gtk 3 the solid blue bar is
replaced by a thin blue bar at the bottom of the widget.
As far as I can tell, the Gimp version of the slider makes three
changes:
1. It allows for a label inside the widget. This is a nice space saving
feature. The widget handles changing the label text from black to white
as the progress bar moves across the label.
2. It allows for a non-uniform scale by adding a "gamma" factor.
3. It adds the ability to drag the progress bar to change the value. If
one drags from the top (down arrow cursor) the change follows the
cursor directly. If one drags along the bottom half (double headed
cursor) the change is finer and relative to the current value.
I've always found that dragging the progress bar to be a bit awkward.
One problem is that one can not start the drag at the far right of the
widget as that area is reserved for typing a value directly in. Also,
the different functionality of starting the drag in the top of the
widget vs. the bottom of the widget is confusing.
Since I am rewriting this widget, I can adjust it to what people want:
* Do you want the progress bar?
* If so, should it be the full height of the widget (quite a bit more
complicated)?
* Do you want to be able to drag the bar? With one/two methods?
* Any other changes?
Thanks,
Tav
5 years, 3 months
Re: [Inkscape-user] [Inkscape-devel] Spin slider widget: Opinions needed!
by Tavmjong Bah
On Mon, 2017-12-04 at 14:43 +0100, Eduard Braun wrote:
> Hi Tav,
>
> thanks for looking into this!
>
> One question to get on the same page:
>
> This is about sliders like "Blur" and "Opacity" (which are re-
> used
> in some other places, too), right? However the actual color
> sliders in the Fill and Stroke dialog are not affected?
Yes...
> Some thoughts from my side:
>
>
> The "top part" dragging is very useful, we should have that.
>
> The "bottom part" dragging never felt quite right for me and
> was
> actually very confusing when I first started using Inkscape,
> so
> personally I'd be fine with dropping that.
OK. That should be easy to do.
> Having text and the spinner inside the widget is nice as it
> saves a lot of space and creates a clean UI control that is
> immediately recognizable as such (in contrast to multiple
> controls loosely packed into a box with each other).
>
> If it's implementable with reasonable effort it's probably
> good
> to keep it, especially for locations where there is not much
> room for an additional label and spinner (e.g. in the toolbar
> of
> the various tools that use the widget).
It's not too hard (already done in my toy implementation).
> The previous bullet point is only true if it's done right -
> thanks to gtk3's wasteful use of screen space I'd consider
> most
> spinners in the toolbar broken right now (the label is
> usually
> hidden behind an ellipsis; due to the two huge buttons which
> are
> now placed side-by-side the usable width decreases even more,
> so
> we either need a more economic solution or need to rethink
> the
> use of spin sliders in the toolbar fundamentally.
One can narrow the +/- buttons via CSS ( ,up, .down { padding:0; } ).
I'll probably check this in (actually I'll probably set it to 2px,
default is 8px).
>
> One performance consideration that might be worth to
> have in mind when doing the rewrite:
>
> For some reason the custom spinner widget has
> a much worse redraw performance than other spinner
> implementations (e.g. the ones in the color selector):
>
> If I change opacity of an object the widget
> only updates a few times per second and is redrawn with a
> delay (canvas reflects the current value properly though).
> In
> contrast if I change the fill opacity of the same object
> this
> spinner widget redraws without noticeable delay.
>
> (strike that part - it only seems to affect the gtk2 build
> and I
> assume you won't backport this to 0.92.x)
No, I won't be touching 0.92.x with this.
>
> TLDR: I kind of like the spin sliders like they are now for
> "Blur"/"Opacity" (and could do without the bottom part
> sliding),
> however they waste too much space to be useful in toolbars
> right
> now.
>
>
> Best Regards,
>
> Eduard
>
>
>
>
> Am 04.12.2017 um 13:42 schrieb Tavmjong
> Bah:
>
>
>
> > Hi,
> >
> > I've been looking into replacing the Gimp Spin Slider widget (e.g
> > Blur/Opacity in the Fill and Stroke dialog). The widget is licensed
> > under GPLv3 and is the only reason Inkscape as a whole is licensed
> > under GPLv3 rather GPLv2.. The board sometime ago agree that being
> > a
> > GPLv2 program was desirable (I don't remember the exact reasoning).
> >
> > A normal Gtk Spin Slider (aka Gtk::SpinButton) has an option to
> > show
> > the "progress" of slider, that is the percentage (defined in some
> > arbitrary way) between a minimum and maximum value. This in Gtk 2
> > is
> > shown as a solid blue bar with width proportional to the value that
> > covers the widget from top to bottom. In Gtk 3 the solid blue bar
> > is
> > replaced by a thin blue bar at the bottom of the widget.
> >
> > As far as I can tell, the Gimp version of the slider makes three
> > changes:
> >
> > 1. It allows for a label inside the widget. This is a nice space
> > saving
> > feature. The widget handles changing the label text from black to
> > white
> > as the progress bar moves across the label.
> >
> > 2. It allows for a non-uniform scale by adding a "gamma" factor.
> >
> > 3. It adds the ability to drag the progress bar to change the
> > value. If
> > one drags from the top (down arrow cursor) the change follows the
> > cursor directly. If one drags along the bottom half (double headed
> > cursor) the change is finer and relative to the current value.
> >
> > I've always found that dragging the progress bar to be a bit
> > awkward.
> > One problem is that one can not start the drag at the far right of
> > the
> > widget as that area is reserved for typing a value directly in.
> > Also,
> > the different functionality of starting the drag in the top of the
> > widget vs. the bottom of the widget is confusing.
> >
> > Since I am rewriting this widget, I can adjust it to what people
> > want:
> >
> > * Do you want the progress bar?
> >
> > * If so, should it be the full height of the widget (quite a bit
> > more
> > complicated)?
> >
> > * Do you want to be able to drag the bar? With one/two methods?
> >
> > * Any other changes?
> >
> > Thanks,
> >
> > Tav
> >
> >
> >
> >
> >
> >
> >
> >
> > -----------------------------------------------------------------
> > -------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > Inkscape-devel mailing list
> > Inkscape-devel(a)lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/inkscape-devel
> >
> >
>
>
>
>
>
5 years, 3 months
