Is this a known issue? (and the dumbest bug ever)
by Josh Andler
I searched the bug tracker (perhaps using language that was too specific)
but I couldn't find a report...
Is a path using dashes with rounded caps supposed to ignore the rounded
caps when you convert Stroke to Path? It visually does it right with butt
or square caps, but rounded caps get converted as butts from how it
appears. I'm seeing this in both stable and trunk and it seems... like an
odd oversight. Anyone else have thoughts?
Cheers,
Josh
3 years, 7 months
Mailman3 outage
by Bryce Harrington
The mailman3 list server was offline the past week, due to troubles it
had delivering email to administrative user accounts. This generated
excessive error logging to disk.
I'm not 100% sure this is root caused but after clearing the queue it
seems to be running happily again. I'll try and keep a closer eye on
it.
Bryce
P.S. there's still a problem with some people unable to subscribe to the
mailing lists; I doubt this change will fix chat, so this problem is
still on the todo list.
3 years, 7 months
Re: Beta-blockers ?
by Patrick Storz
Hi Marc,
thanks for planning this thoroughly! Answers below.
Am 12.08.2019 um 21:13 schrieb Marc Jeanmougin:
> == Extensions (Martin, Patrick, others) ==
>
> What is the state of extensions (#156) ? In particular, their
> translatability (#333) ? Is the current submodule commit in a "good
> state" ? What to do with the old uniconvertor extensions, do we update
> them to uniconvertor 2.0rc5 ?
While Martin and others did (and are still doing) a great job on the
bundled Python extensions I'm currently working on the extension
implementation in Inkscape itself.
I just finished one big part (.inx format updates and the internal logic
in Inkscape to parse preferences/parameters form it while also creating
nice GUIs) which is ready for review at
https://gitlab.com/inkscape/inkscape/merge_requests/808
As Martin already mentioned translations are basically handled as before
(still use inkscapes .pot/.po files), only the way we mark strings for
translation in the.inx changed. Once the MR is merged it will be a
trivial job to update the .inx files with some search&replace, although
the code should be fully backwards-compatible to earlier .inx files.
Regarding splitting the translations of extensions into the extension
repo (and also allowing third-party extensions to ship their own
translations):
The current MR implements the syntax, but the actual functionality is
not included yet. However I realized while working on it, that I already
have done most of the required refactoring, minimizing the effort that
remains for finishing the feature.
If we feel like this is a welcome feature for 1.0 already, we can
probably implement it in time instead of delaying it until 1.1 as I
initially planned. I'm starting to think that this would actually be
nice, as we can offer a finished feature in 1.0 instead of just syntax
for a feature that is not implemented yet.
> == Gtk General interface stuff (all) ==
>
> Do we still have interface problems like toolbars not showing up or
> menus needing two clicks, or anything of the sort, on any platform ? Is
> #195 still reproducible ?
I'm not aware of anything specific right now that prevents usage.
In general there's still a fundamental "glitchiness" to gtk3 on Windows,
but I'm afraid that's just how gtk3 works on Windows these days. We'll
certainly get some questions about it, but I wouldn't know what to do to
significantly improve this until the release.
> == Packaging (RdH, Patrick, others) ==
>
> Approximately how much work is still needed for macOS stable dmg
> production or windows packaging ?
>
> What happens with the ubuntu bionic "dependency wait" ? (
> https://launchpadlibrarian.net/437056488/buildlog.txt.gz )
Updating our existing Windows packaging for 1.0 should be easy (once I
can motivate myself to do it).
I always planned to look into cpack and investigate if it can produce
proper installers, so we might eventually get rid of our own packaging
and reduce the overhead of maintaining it, but that might need some more
work.
> == Performance (all) ==
>
> Do we still have these massive performance problems as soon as the
> Objects dialog (or XML ?) has been opened ?
I'm not aware anybody pushed a fix? Didn't retest, though.
Apart from that performance stil lseems worse than 0.92.x (at least on
Windows), but also here I wouldn't really know what to do. It's usable,
but it's not good.
One particular performance issue (I know there were multiple reports,
but not sure we have an actual issue for it and GitLab throws 500 errors
at me):
Selecting a new font takes a very long time (a few seconds at least,
some take 10-20 seconds). Not sure if this is exclusive to Windows? It
does not happen in 0.92.x, though (with the same version of
fontconfig/harfbuzz/pango/...), so it's either something we're doing, or
something gtk3 is doing differently from gtk2. I think performance
wasn't always bad in master, though. I think it started either with the
variable fonts support or after the SPStyle refactor.
>
> == Text (Tav, Jabier, others) ==
>
> How usable is the text tool ? Do we implement the "hamburger" toolbar ?
> Do we still have issues with variable font sliders ? How understandable
> are our text tools, and are users able to "just write text" without
> surprises ? (with line heights for instance ?)
Tbh, I can't use the text toolbar myself anymore... Either I'm to stupid
or we really *should* do something about usability.
It never behaves as expected and always sets properties in ways that
were not intended.
One line-height related issue that also needs attention is
https://gitlab.com/inkscape/inkscape/issues/244
> == SVG2 (Tav, all) ==
>
> I'm not sure we have discussed enough the transition between SVG1.1 and
> SVG2. If we start producing svg2 documents that are not svg1.1-valid,
> should we use version="2" in <svg> ? how will it be understood by other
> renderers ? When and how do we intend to switch the 1.2 flawed text into
> the newly flawed text, how will we handle old documents, and how do we
> ensure they will render exactly the same ? Do we provide a way to save
> in "valid SVG1.1 document without SVG2 stuff" ?
I'd say we should always produce SVG1.1 fallbacks, even if we use SVG2
features?
Maybe we can then add an option to disable the compatiblity shims and
produce a "pure" SVG2 document.
I know some switches are available, but Tav can probably comment better
on what is implemented and what isn't.
> == Documentation (Maren) ==
>
> I saw https://gitlab.com/inkscape/inkscape-docs/documentation/issues/2 ,
> do we have more stuff to update ? By the way, how do we sync the
> inkscape/inkscape repo with the inkscape/inkscape-docs ?
As Maren mentioned already there's a lot to update content-wise.
I've handled most of the technical side and meant to make a call for
help at some point, but didn't get the chance to do it yet.
Once content is updated I typically copy the CI-generated files manually
and push the update to the inkscape repo. Basically this can wait till
shortly before 1.0, but we can certainly schedule a preliminary update
for the beta(s).
Cheers,
Patrick
3 years, 7 months
Beta-blockers ?
by Marc Jeanmougin
Hi all,
The toolbar bug seems fixed for most systems and only seems to appear on
wayland (at least I can't trigger it on xorg), and is now reported
upstream at https://gitlab.gnome.org/GNOME/gtk/issues/2000
The translation system seems better (#311), so … do anyone see any issue
that would need to be fixed before releasing a beta ?
--
Mc
3 years, 7 months
new forum is open!
by brynn
Hi Friends,
As far as I can tell, the new forum is officially open! I've blocked
new registrations on Inkscape Community, with a banner on the index page
linking to the new forum.
brynn
3 years, 8 months
