We were improperly adding the printing device margins to the area
where we print, leading to wider margins on physical outputs than
on PDF or preview outputs (which have no hard margins), as well as
wasting space and not respecting user's settings.
Closes#3580269.
This prevents a regex pattern from fooling the parser if it contains
some recognized constructs, like comment or string literal starts.
Closes#2992393 and #3398636.
Build command spawning failed sometimes when there were several
pages of errors. In these cases the process would block for 30s and
then abort. (Some hangs were also experienced).
This fix does cause a console window to be shown for the duration of
the spawned process. This seems acceptable compared with the old
broken behaviour, and can be useful to abort the build command by
closing the console window.
Note: If 'env' is passed, the old broken spawning is used.
If a title contained multi-byte UTF-8 characters, it wasn't properly
recognized due to the title being longer (in bytes) than the underline.
So, fix the title length computation to properly count the characters,
not the bytes.
Note that this fix only handles ASCII, one-byte charsets and UTF-8, it
won't help with other multi-bytes encodings. However, the whole parser
expects ASCII-compatible encoding anyway, and in most situations it
will be fed the Geany's UTF-8 buffer.
Closes#3578050.
We used to convert the tags from the file encoding to UTF-8, but since
we parse directly from our UTF-8 buffer, all tags are UTF-8, which lead
to an improper conversion.
Some users want the theme icon, some dislike the icon provided by
their theme and want the traditional Geany icon.
This makes that choice a various pref. Used a standalone global
to avoid impacting the plugin interface and CommandLineOptions
and GeanyStatus didn't make sense.
If the cursor was inside one of the comment's delimiters, the code used
to look for another delimiter, leading to removing previous comment's
start. Moreover, the code assumed the delimiter will always be found,
leading to improper deletions if a delimiter could not be found (either
because of the above problem or because the comment wasn't terminated).
Also, the code used document_find_text() which, if the searched text
cannot be found on the requested direction, either wraps or asks the
user whether to wrap. Wrapping is wrong if there is more than one
single comment in the file, and the dialog is confusing for the use
since she didn't ask for it.
So, rework the code for it to correctly find the delimiters, and not
to wrap search or ask the user. It is also simpler by reusing some
already existing code.
The implementation drops the non-selection code paths and simply makes
sure both caret and anchor are placed at the same position if there
was no selection. This avoids having two completely different code
paths for things that are very similar -- and alternative code paths
were buggy.
Closes#3576431.
GtkFontButton uses GtkFontChooserDialog on GTK 3.2 so the UI is more
consistent if we use it explicitly too, and GtkFontSelectionDialog
is somewhat broken on 3.4.
Although theoretically GtkLabel from GTK3 should be able to replace
GeanyWrapLabel altogether, a bug [1] with it makes it use way too much
space in our about dialog (and possibly other places), making it not
really usable.
So, port the GeanyWrapLabel hack to GTK3, with the appropriate
additional hacks for it to work. At least it looks good and don't
seem to have resizing issues now.
[1] https://bugzilla.gnome.org/show_bug.cgi?id=657621
This fixes the SCINTILLA_CLASS() and IS_SCINTILLA() macros on GTK3.
No harm on GTK2, those macros are available since 2.0.
This also makes those macros more consistent with the SCINTILLA()
macro that already uses the proper GObject calls.
Backported from Scintilla HG: 9cd7cf1d9af73d50b0423ed34a6693bbf7f57ac8
GTK uses a signed page_nr parameter to callback draw_page despite
describing it as 0 based, cast it to unsigned for comparisons to
array len which is also unsigned.
The GTK3 version of GtkLabel provides what GeanyWrapLabel is for given
the appropriate settings are set, so no need to our own widget -- that
would require being updated to support GTK3 anyway.
Map the various horizontal and vertical deprecated constructors
to their GtkOrientation-based equivalents on GTK3 to prevent most
deprecation warnings.
Use the GtkComboBoxText API and the GtkComboBoxEntry replacement API
and map those to the old equivalents if not available.
This changes the type exposed by ui_combo_box_add_to_history() from
GtkComboBoxEntry to either GtkComboBox (under GTK2) or GtkComboBoxText
(under GTK3). This should not be too much of an issue since
GtkComboBoxEntry and GtkComboBoxtext are subclasses of GtkComboBox,
but this will still emit warnings when when the calling code passes
a GtkComboBoxEntry pointer to ui_combo_box_add_to_history().
However, this requires the calling code to use the same mapping as we
do (GtkComboBoxText = GtkComboBox on GTK2, even on 2.24), or things
will blow and it'll be hard to understand why. This wouldn't be an
issue if the calling code includes our gtkcompat.h header everywhere
it deals with combo boxes, which will be the case if it includes the
Geany headers everywhere but probably won't otherwise. Oh dear.
A possible kind of workaround may be for ui_combo_box_add_to_history()
to do type-checking on its argument and use the actually correct API
for that type.
GtkDialog separators sere deprecated on GTK 2.22 and remove on 3.0,
so define them to dummy values on GTK3.
We don't get rid of them altogether because GTK 2.16 we depend on
probably has separators enabled by default and we want to remove them.
