| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
JavaFX 1.x is long obsolete (since 2012-12-20) and the code for it has
not been maintained. There have been no end user comments/reports since
2012 and a few bugs that would be important remain unfixed.
Given that this is not an import format, the impact of removing this
should be extremely low.
Refs: https://www.oracle.com/technetwork/java/javafx/overview/faq-1446554.html#8
Refs: http://web.archive.org/web/20170316051832/http://blogs.oracle.com/javafx/entry/javafx_1_2_and_javafx
Refs: https://stackoverflow.com/q/18865774/2074608
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
It seems unlikely we ever want to load "arbitrary" data from share/,
usually there will be a more suitable "Type" to look for.
Also it avoids ambiguity, as there is no user-specific "DATA_DIR"
|
| | |
|
| |
|
| |
Found via `codespell -q 3 -I ../inkscape-whitelist.txt -S *.svg,*.po,./src/3rdparty`
|
| |
|
|
| |
Any change from previous behavior is a bug.
|
| |
|
|
|
|
|
| |
Please use the (functionally identical) INKSCAPE_PROFILE_DIR instead.
See also
https://gitlab.com/inkscape/inkscape/issues/114
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It now always prefers
- files in the users profile over files in the share/inkscape folder
- localized files over unlocalized files (per folder)
In conclusion: USER (localized) > USER > SYSTEM (localized) > SYSTEM
This always allows users to override files shipped with Inkscape by
putting a respective file in their profile directory.
First part of a fix for
https://gitlab.com/inkscape/inkscape/issues/103
Avoids regressing
https://bugs.launchpad.net/inkscape/+bug/503712
|
| |
|
|
| |
Makes searching through code for them easier.
|
| |
|
|
|
| |
Now all that's needed to prefer a localized version of the file
(if available) is a Boolean.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
| |
Found via `codespell`
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| | |
be exported to its own file.
Using a semi-colon allows the future possibility of allowing the user to use a comma separated entry to
select more than one object to export at the same time.
|
| | |
| |
| |
| |
| |
| |
| | |
Use Gio::File for accessing files.
Use Gio options to handle command line arguments.
Use Gio::Actions for some command line arguments.
Move file export code to src/io/file-export-cmd.h/.cpp. Make into class.
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
- add license headers to everything
- convert a few files from public domain or LGPL2.1+ to GPL2+
- some archaeology to clarify which files are from which library
|
| | |
|
| |
|
|
|
| |
It was only used in one place. Use "g_base64_encode" instead, like the
rest of the codebase.
|
| |
|
|
|
|
|
|
|
|
| |
Replace UriInputStream -> FileInputStream
Replace UriOutputStream -> FileOutputStream
Remove UriReader
Remove UriWriter
UriReader, UriWriter, and the acutal URI-based API of UriInputStream and
UriOutputStream was all unused/dead code.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
The former is guaranteed to be set for any compiler targeting win32,
the latter is implementation dependent (but works for gcc)
See also
http://nadeausoftware.com/articles/2012/01/c_c_tip_how_use_compiler_predefined_macros_detect_operating_system
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
None of these functions seems to expect an actual gunichar (which is
a 32-bit type and can hold any UTF-32 or UCS-4 character code, also
known as a Unicode code point).
Instead we want UTF-8 encoded character data (i.e. gchar, which is
equivalent to char) that can be output byte-wise to form a valid
UTF-8 encoded string.
|
| |
|
|
|
|
|
|
|
|
|
| |
As we output UTF8 encoded strings to normal streams we can (and
should) put one byte at a time. Iterating over an ustring will give
us "unichar"s with up to four bytes, though, which is bound to fail
when written to a stream.
Using Glib::ustring::raw() gives us a std::string with the raw
(but still UTF8 encoded) character array that can be iterated
byte-wise and output to the stream as-is.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This tremendously speeds up saving long strings which previously
had to do "n!" lookups (where n is the number of chars) as
Glib::ustring::operator[] has to iterate over all preceding
unichars in each iteration to find the requested unichar.
A file with a CDATA section of ~1 MB saves in a few milliseconds now,
previously it didn't finish even after some minutes.
Fixed bugs:
- https://bugs.launchpad.net/inkscape/+bug/1793877
|
| |
|
|
| |
(cherry picked from commit 11504fc9060729939703c380bcaa71cfc36ea351)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is useful when using inkscape from the terminal and piping the
output to further programs.
Example usage:
cat vector.svg | inkscape --export-png - --file - | convert - out.jpg
Fixes bug: 171016
(forward-ported from commit fdb3b41a37f5c37bbb8e49d59e7e6195d5363fcb)
|
| | |
|