Is it possible to specify the filetype or filename when using the verb FileSaveAs from a DOS prompt?
by alvinpenner
This is two questions, actually, somewhat loosely related:
1. I would like to run a DOS command such as:
inkscape --verb=dosomething --verb=FileSaveAs \windows\temp\testtext.svg
Currently this command will present me with a SaveAs dialog with the current
file name and the filetype svg. I would like to specify, in the command
line, either the file type for the Save As operation, or perhaps the
filename with the filetype as well, so that the operation could perform
silently. Not sure what the syntax would be for this.
2. Alternately, if this is not possible, is it possible to execute verbs
from inside a Python script? So, for example, if I were in the Python
extension dxf_outlines.py for saving a dxf file, can I execute the verb
"--verb=ObjectToPath" and get output from it?
tia,
Alvin
--
View this message in context: http://inkscape.13.x6.nabble.com/Is-it-possible-to-specify-the-filetype-o...
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
6 years, 6 months
Post-Mortum: Line height bug
by Martin Owens
Developers,
As someone how changed the line-height code prior to release, I feel
somewhat responsible for the issue in 0.92. I really didn't have enough
time to focus on bugs before the release, but should have spent more
time on things I'd changed. I'm really sorry Inkscape.
This thread isn't for figuring out how we're going to solve the issue
though. I'll let the 0.91.1 discussion cover that.
What I'd like to pick apart is our bug management and how a release
blocker like this line-height issue didn't put an all stop on our
release schedule while we figured it out.
There's a couple of possibilities:
1. The bug wasn't discovered in time
2. The bug wasn't reported in time
3. The reported bug wasn't triaged in time
4. The bug wasn't prioritised as important
5. There wasn't a way to communicate a major issue to the release
manager.
6. We just didn't have the resources to do the release properly and
let things slide.
What information can Mc and su_v add about the issue? What can we fix
to make the process better?
I feel bad asking for your help to really figure this out, but I think
this might help us as a project overall if we know what happened and
how to defend against it.
Thanks everyone.
Best Regards, Martin Owens
6 years, 7 months
UX help
by Máirín Duffy
Hi everybody,
I've been using Inkscape and sodipodi before it for maybe 12 years now;
it's my primary design tool. I'm a UX designer for Red Hat and
specialize in mocking up page/screen designs for new features and
modifications, drafting text for user interfaces, as well as user
testing and feedback.
I noticed some of the comments about the 0.92 release text height
issueand the critique of the dialog that pops up in 0.92 about old
Inkscape files.
I would just like to offer my services any time you might need advice or
help in figuring out how to design such dialogs or handle various
conditions like this. I'm mizmo on freenode or you can email me. Please
consider me a resource you can tap anytime for this; I don't code but
I'm always happy to helpwhether it's some quick advice or something more
involved like mockups.
Cheers,
~m
6 years, 7 months
Inkscape 0.92.1pre0 source tarball
by Bryce Harrington
This is a pre-release for the upcoming stable bugfix release 0.92.1.
Download it at:
https://inkscape.org/en/download/development-versions
The release is:
0.92.1pre0 Source Tarball Bzip
https://inkscape.org/en/gallery/item/10613/inkscape-0.92.1pre0.tar.bz2
Hard Freeze is now in effect. Do not land any code changes on the
0.92.x branch without release manager approval. In particular, I would
prefer to see only critically important fixes, or carefully reviewed
refinements of fixes recently landed, and leave the rest to 0.92.2, but
I'll consider all proposals on a case by case basis, just give me a
ping.
== Translations ==
Next Monday will mark String Freeze. Between now and then, string
changes in code are permitted, but due to Hard Freeze there will
probably be few. Thus I encourage translators to start updating
translations at this time, with a plan to finalize next week.
== Packaging ==
Packagers for Linux and Windows should use this source tarball for
creating test packages, and upload to the website.
== Future Releases ==
The 0.92.1pre1 pre-release will be in one week's time. I plan to try to
stick pretty strictly to the previously announced release schedule, but
of course release delays may be necessary depending on testing.
A subsequent 0.92.2 release will be planned for 1-2 months after
0.92.1's release, so some sort of April timeframe seems likely.
Thanks,
Bryce
6 years, 7 months
[RFC] gitlab migration plan
by Bryce Harrington
Thank you everyone for considering the options and rasing good points
and concerns, including:
* Gaining contributors is a motivation here
* Performance might be problematic with gitlab
* FOSS options fit Inkscape values, and we should prefer to support
FOSS projects, but not if it inhibits us too badly
* Other choices do exist besides just github vs. gitlab
A lot of people are voicing preference for gitlab, perhaps a majority,
but we're certainly not at a full consensus. I sense that we need some
actual experience under our belts, and we should plan to reassess our
decision as we get into it.
Performance is, at least, something we can test. If gitlab has severe
performance issues, then that should be obvious and likely measurable if
we just try it.
Github certainly would give us more visibility, however there's no
guarantee this would translate into more contributors. Will Entriken
made a good point that being on github would enable more drive-by
contributions based on general experience in various small/medium
projects, however Mc makes a strong counter-argument that what we are
really after are dedicated contributors, and with Inkscape already
having a fairly widespread profile those folks will find us just fine
regardless of the popularity of the hosting platform. Perhaps a
separate outreach effort to recruit contributors after the git migration
has been done would be more likely to generate good results?
So given the above, I'd like to propose a migration to githab but with
several checkpoints, according to the following plan:
1. Migrate inkscape_web.
+ Keep a particular eye on performance.
+ Evaluate code review UX
+ Evaluate CI
+ Experiment with other features
2, Once 0.92.1 is released, we'll have a first checkpoint
Checkpoint for inkscape_web.
+ Make recommendations for utilization of code review, CI, and other
gitlab functionality.
+ Was performance a hinderance? Is the
user experience acceptable? In general do the inkscape_web
participants still feel as supportive of gitlab?
+ What concerns or issues remain, that should be watched during our
initial migration?
+ We'll ask everyone involved in inkscape_web for a thumb's up or
down. If there are thumb's down, we'll halt and re-evaluate.
3. Migrate inkscape to gitlab.
+ All bzr committers are eligible for gitlab commit access,
but will need to place a request for access
+ At least one dry run should be done, to ensure that revision
history, branches, tags, etc. are successfully converted.
+ Issues encountered with gitlab will be recorded, either in a
dedicated bug tracker or just a simple 'complaints' web page.
+ Transition of wiki pages can start as desired
(see separate plan proposal).
+ Bugs stay on LP for now
4. Outreach effort to bring in contributors
+ Leverage our release marketing procedures and contacts
+ Coordinate with GSoC, releases, hackfests
+ Ensure we have reviewers/mentors on hand
5. Following the 0.93.0 release is a second checkpoint.
+ Review the recorded issues encountered. Collect further
feedback.
+ How has use of gitlab affected contribution levels to the Inkscape
codebase? If contribution levels have not grown then we need to
reassess.
+ All active users of the service are asked to give thumbs up/down
on their experience using gitlab. If most everyone gives thumb's
up, we will proceed and stick with gitlab at least until 1.0.0.
Otherwise, we need to re-evaluate our plans.
+ Plan follow-on work to investigate/address top issues.
6. Following the 1.0.0 release, we have another reassessment of all
project technologies and services. cmake, git, gitlab, C++11, gtk3,
and so on. We should then plan transitions from those to whatever
is next, over the course of several 1.x releases.
If you've read this far - thanks! Feedback is most appreciated.
Bryce
6 years, 7 months
Any progress on CMYK?
by John Culleton
My copy of the 4th edition of the Bah book says it is
"under way." The absence is a pity because with the
built-in perfect book layout facility
Inkscape would be most useful in creating book covers.
The ability to distort type faces
makes for some interesting possibilities
I recognize the size of the task of course.
--
John Culleton
Wexfordpress
Book design and indexing.
6 years, 7 months
Seeking Review: Inkscape Development for Users
by Martin Owens
Hi Everyone,
Golden Ribbon (GR) has made this slick info graphic to explain and
prompt more users to help with Inkscape development.
http://grtuts.com/inkscape-development-builds/
He's asked me for advice on the details and I figure I'd throw it open
to everyone.
You can comment directly in the blog post if you like. Or here, since I
know GR is subscribed here too.
Also I think we might like to think about brining the planet back to
life with some new blood. I wouldn't mind having non-coders on the
planet, professionals perhaps. Or more than one if a planet is put into
the website for example (they're fairly easy to write)
Thoughts?
Best Regards, Martin Owens
6 years, 7 months
[RFC] Wiki replacement plan
by Bryce Harrington
I'd like to offer a proposal for a path forward here, merging ideas
and concerns everyone's put in, particularly Maren's feedback on my
initial proposal in the previous wiki thread. Apologies ahead of time
for the length, as usual brevity escapes me.
Wiki Replacement Plan
----------------------
#0 - No change to the current wiki until Inkscape's codebase is
migrated to git. So, probably no change until March or so.
Thus, people considering using the wiki for things right now,
should proceed with doing those things.
#1 - Application documentation and reference source files are moved
to Inkscape's share directory in VCS. Extension references,
output format details, tutorials, usage advice, and so on. This
will be shipped with the application, and probably worth
rendering in some web-viewable format as well. Nearly all of
this will be worth translating.
#2 - Strictly user-facing pages in the wiki are moved to the main
website. High level project info, roadmaps, user-oriented FAQs,
community resources, and so on. If a page requires advanced
styling or layout functionality in our current mediawiki, that
would be a strong indication it should be moved to our Django.
This will obviously take time and effort but can be tackled bit
by bit. Most of this is worth translating.
Finalized release notes will become part of the releases app;
this will support html and translations.
#3 - Static coder-facing documentation should be moved to Inkscape's
doc/ directory. This includes anything that documents
implemented designs, protocols, and other assorted
functionality. It also includes coder tutorials and guidelines.
Generally materials that can be considered "finished" and worth
keeping for reference value. This doesn't include unimplemented
ideas/proposals, nor anything that is obsolete or that we're
keeping simply for historical purposes. Little of this will be
worth translating.
#4 - Dynamic development pages are moved to the git*b wiki. This
includes design mockups, development plans, todo lists,
architectural brainstorming, infrastructure refactoring proposals
and the like. A lot of the stuff currently registered as
blueprints, that are adequately well fleshed out and that may be
worth including in our official roadmap, should also move here.
None of this should be translated.
The release notes under development for the trunk codebase are
drafted here in this wiki. Perhaps eventually we'll move editing
to the releases app.
This also includes organizational documentation for the Inkscape
board, pages relating to fundraising, hackfest planning, and so
on.
#5 - Obsolete pages are left in the current wiki, but
"mothballed" for historical reference.
#6 - A "Community Wiki" will be established with open access for
members of the wider Inkscape community, to use as a freeform
collaborative editing space. There would not be rules about what
can and can't go in here, but this is where folks would go to do
collaborative brainstorming, flesh out raw ideas, and share
random wishes and bits of information not ready or suitable for
inclusion in any of the above. It should be easy to register for
and easy to edit, but also robust against spam. All other pages
not covered by 2-5 above, will end up here.
As a general rule of thumb, if a page in the Community Wiki is
important enough to be worth translating, or if we find ourselves
linking to the page frequently, then that is a sign the page
ought to be promoted and moved elsewhere.
This could be an updated MediaWiki like we currently have,
however I'd like to see thought given to alternative solutions,
such as a Django wiki plugin that allows tighter integration with
the website, or even using an externally maintained wiki service.
It could also be a special Git*b project with really lax rules
for committing. Whatever we pick, the important things are that
it's widely available to all, easy to use, and very light on
rules or imposed structure.
#7 - Feature requests and wishlist changes, eventually will move into
a future project management system on the website (I envision
something that couples bug tracker style commenting with wiki
like editing within a Blueprints-type tracking system). This is
probably a few years out though so we'll need to keep using #4
devel wiki in the meantime.
Let me know what you think, and please poke holes. If there are no red
flags raised, we can proceed with this plan subsequent to our move to
git.
Thanks,
Bryce
6 years, 7 months
problems having only macports to install Inkscape on Mac
by brynn
Hi Friends,
We have this message which has gone unsolved, in the User mailing list.
https://sourceforge.net/p/inkscape/mailman/message/35630257/
I've seen this same problem posted 3 or 4 other times. They follow the
instructions for installing using Macports. Everything seems to have worked
without producing errors or other problems. But afterwards they can't find
Inkscape.
In one of them, I'm trying to help a newbie who posted on Inkscape Community.
She has sought support from Macport support, and apparently they are either
unable or unwilling to simplify the solution for a newbie.
I'd like to know the solution for this, since it seems so common. Then I (or
we) can help Mac users who have this problem.
In my opinion, it reflects poorly on the project not to have a solution which
newbies can use.
Hopefully Kirk Slowe will be successful packaging a DMG version for 0.92 or
0.92.1.
But meanwhile, can anyone tell me the solution for this?
Thank you very much,
brynn
6 years, 7 months
Inkscape 0.92 via homebew on macOS
by Tim Sheridan
If you use homebrew on macOS, then you can get Inkscape 0.92 by running:
brew install caskformula/caskformula/inkscape
(For non homebrew people, here's a glossary: formula => package built from source, tap => repository, cask => package redistributing an upstream binary)
This formula originates from the inkscape formula in the homebrew-gui tap. However, recently the homebrew-gui tap has been deprecated. In the case of Inkscape, the cask is considered the successor package. But since the inkscape cask is limited to official releases (or third party releases nominated by the Inkscape project), the cask will stay at 0.91.
So for the time being, I'll be maintaining the inkscape formula in this tap. Any contributions/improvements are welcome: https://github.com/caskformula/homebrew-caskformula
Cheers,
Tim
6 years, 7 months
