The build now successfully build the PDB files into the source folder
itself. Unfortunately it seems I can't get meson dependencies to work
properly, once more! I added a "sources" argument to the relevant
library() or static_library() but it still uses old versions to build
these. E.g. if I add an error on purpose to a pdb file, the next build
still passes, yet the second-next fails (as it should have before).
Note that I even tested a declare_dependency() with just the "sources"
arguments, because it says "sources to add to targets (or generated
header files that should be built before sources including them are
built)" (so I assume it means that it should be trigger a rebuild,
otherwise it's useless) but it's just not working. I'll investigate
more.
Still going with this for now, because at least generating the PDB
source was a big miss until now. But we should
After some investigation, I am a bit unsure of why this happens exactly,
but I have a case that the device's axis number listed is not right and
this only becomes apparent after the stylus gets close then further from
the tablet-display. This fixes it, though I think we should look more
closely and reorganize a bit this whole part of our code, which seems
unecessarily complicated and duplicating some data already in GTK/GDK,
like the list of axis, etc. (though maybe it was necessary back when
this was first implemented before more logics got moved to GDK?)
Fixing broken coding style and factorize the code to avoid redundant
calls, in a separate commit as the contributor hasn't responded for
nearly 2 years. Also no need to get the character count as -1 offset is
equivalent to point after last character (or alternatively we could have
used gtk_text_buffer_get_end_iter()).
I had raised some more questions on a possible better implementation (or
maybe not), but since the discussion never happened, let's just push
as-is. It still improves things and the whole text editor should be
revamped some day anyway.
The MR commit (i.e. previous commit) fixes the specific case when
changing font size with no text selected (changing the size of the whole
text).
Since commit 4cf38d784f, when loading an indexed image, we would first
initialize a palette with 0 colors, then set it to the right colors.
Babl outputs the following message when initializing to 0 colors:
> ../../src/babl/babl/babl-internal.h:214 babl_log()
> attempt to create a palette with 0 colors. using default palette instead.
Let's only set the palette to Babl when it has colors.
We take a step back from the original MR which was proposing the "single
dot" cursor as a new "Pointer mode" option. I was really unsure this was
the best solution, especially reading again the whole original report.
It means that now nearly all of the original patch has been rewritten
another way, but let's leave the contributor commit as a start point to
get to where we are, and as acknowledgement of the contribution.
The reporter was annoyed by the crosshair when none were requested and
probably mostly for painting tools only (at least examples were about
brush or pencil, etc.) while showing outline. It looks to me like the
real issue was maybe when we were showing the big crosshair when using
the 4-arc fallback outline, for instance when using a dynamics changing
size. If so, this main issue is already fixed by my commit 64dc26064b.
No need of a new option for this, especially if the option can be as
confusing as a barely visible dot-cursor (I can already imagine the bug
reports of people tweaking random preferences and unhappy because the
pointer became invisible, while they don't know how they did it).
Instead I would say that when people specifically uncheck both "Show
brush outline" and "Show pointer" options, showing a huge crosshair
feels quite counter-productive. This is where I think that our small
unobtrusive cursor (probably a better name than "Single dot" by the way,
as it's not a single dot anymore) might be of use, the ultimate case
when someone really want a cursor as inconspicuous as possible, while
still having a visible feedback of the pointer position (even with
display-tablets, parallax issues make such a visual feedback important
to target where one paints).
So let's try this first and see how it goes.
- Rename "Mouse Pointers" frame to just "Pointers". It's not just about
mice but all input devices.
- Move the "Pointers" options from "Image Windows" to "Input Devices"
tab in Preferences. It looks to me it's more about how you configure
the device pointers than anything really image window-related.
- Move the paint tool options in their own frame "Paint Tools" to really
differentiate the generic pointer options from the ones specific to
paint tools. This frame is added side by side to the "Pointers" frame
to hopefully underline they are related.
I'm still annoyed by the fact that if you uncheck both the "Show brush
outline" and the "Show pointers for paint tools", it will actually show
a big crosshair in such case. I can understand the logic (not to end up
in a case with absolutely no indication of your pointer position). But
then shouldn't we rather forbid unchecking them both at once? It would
be clearer IMO. On the other hand, are they people who like this big
crosshair and use this?
Other thing I was annoyed about was whether you would not want to have
the "Single dot" only on paint tools. But as Aryeom told me, maybe let's
just try it like this and see if people ask for a double option (pointer
on paint tools vs. pointer on other tools) as it is already very
complicated settings as it is. I mean, at some point, I even thought
about a per-device pointer. I also studied the possibility of detecting
whether you are on a display-tablet (when you are more likely to want an
unobtrusive pointer) or not (then you may be very annoyed each time you
can't even spot easily your pointer on screen). But GTK doesn't give
this later information, and as Carlos reminded me, even a display-tablet
can be mapped to another display, so even if we could detect a
display-tablet, it would not mean it is reliable information for making
a decision on whether we want a light pointer.
… in previous commit.
Also fix some coding style bugs.
Finally change s/"Single Dot"/"Single dot"/ to have the same label
syntax (only capitalize the first letter of the label) as other labels.
Cf. #7034 and !466.
If someone explicitly asked not to get a pointer, yet to have the
outline, we should not force a crosshair on them while the fallback
outline is a perfectly visible mark (4 arcs around the pointer's
position, well delimiting the brush size).
… whether the program is really ready to accept various commands.
In particular, on macOS, one could drop an image to the app icon in the
dock while starting up (visible splash). Then if the profile convert
dialog appears *behind* the splash, it would block loading until an
action is taken (unfortunately as it's hidden, people may miss it and
would think GIMP froze), as reported by cyril and reproduced by lukaso.
I can't test myself, but I'm hoping this will fix the issue (similar to
commit a86ed68870 where we had a similar issue with dbus file opening
on Linux).
Since the "Dynamics Off" is set when the brushcore is started, when we
were running gimp_brush_core_eval_transform_dynamics(), we were using a
previous dynamics output.
Also it's better to shortcut the computation anyway when we know the
dynamics is not for use.
… cursor position label.
This should now resolve any weird jumping around of the cursor label,
hence the GUI. Of course, it could actually still happen when going
really off-canvas (though the max computation takes into account
reasonable off-canvas moving, which is totally possible, especially now
that we can view off-canvas so people can just work there and the GUI
should definitely not do weird stuff there as well).
This issue was not confirmed to happen on Linux and Windows, but was
making ugly label resizes on macOS by just moving the cursor on canvas
normally. See video in:
https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/572#note_1389445
Ironically enough though, it started to happen even on Linux/X11, at
least, after commit 1baeffc913, which was the commit meant to fix this
on macOS!
This max size computation algorithm should work well enough for any
normal on-canvas usage, and even some off-canvas (yet close enough)
usage.
Note: this code only takes into account the pixel position case, for a
first implementation, which is why it's not pushed immediately in this
form.
Since we are pre-processing anyway the AppStream metadata file (because
appstream-glib doesn't pass unknown XML attributes, cf. a previous
commit), it does feel silly now to continue loading the file at runtime
too. Let's just pre-process more data into the constructed C files, i.e.
get the introduction paragraphs and the change items too.
The only other remaining advantage of appstream-glib was that it was
handling the localization but since we also have these localized strings
in our gettext files, we can as well translate with gettext as any other
strings and it works just fine.
It will also get rid of any packaging issue, forgetting to package the
metadata file (as we had on the Windows installer, and still have on the
macOS package). Now it will just always work because data is internal.
The changes include:
* A popover will be displayed on tool buttons and relevant property
widgets.
* Now the welcome dialog gives focus up to its parent window because
really the whole focus styling issue in GTK is a bit maddening. The
colors are all faded, the popover widgets are barely visible, and so
on.
* Timing is tweaked a bit to give more time reading the popover tips.
It's still the same visually but it will be useful for 2 reasons: first,
it makes nicer code to show/hide only this one box instead of 3 frames;
second it will be used for the release note demo feature so that we can
blink the full line art settings box.
… blinking it.
This will be necessary to demo new features available only in some
situations. E.g. a new option in line art detection mode of bucket fill
would require said mode to be enabled.
First I strip now every pieces of text. What it allows it to span the
script elements for instance on several lines, indent them and all that.
The second thing is that since all the dockable start with "gimp-", we
may as well allow use shorter names (both are allowed). Same for tool
(which we special-case), all the tool buttons ID start with "tools-"
since we reused the action names. So let's just allow the shorter
versions.
Finally I create a new gimp_blink_toolbox() which is a specialized
gimp_blink_dockable() for the toolbox in particular. I also move there
the whole code about selecting the right tool.
Make a different bullet points for items with demos and items without,
and add an info text explaining you can click on items with the right
bullet point to get a demo.
Hopefully it will fix the following CI errors:
> make[4]: *** No rule to make target '../../tools/generate-welcome-dialog-data.py', needed by 'welcome-dialog-data.h'. Stop.
I thought using relative paths was fine too here, but I might have been
wrong (even though it worked locally).
Even when using a GtkListBox, it's just prettier and clearer when having
a text list with dots IMO, especially since some text might wrap on
several lines. Let's just go with that.
The idea is to add some "demo" attribute to a list item inside the
<release> tag, since we already decided that (for now at least) we'd
keep a strict "intro + list" logics, as we did until now.
This demo attribute uses an internal format to specify successive
widgets to blink (like a demo path towards a feature). For now, what it
allows is:
* raise the toolbox, select a tool and blink the tool button.
* raise a dockable, blink any widgets in there.
Now it is still limited and needs to evolve. In particular:
* What happens if the blinked tool button was explicitly removed from
Preferences? Should we re-add it for the demo? And once done, should
we remove it again? Then should we select back the tool previously
selected?
* What happens if the dockable widget is not visible? Should we allow
changing the settings to be able to demo correctly the new/changed
settings? Should it be temporary? If temporary, it can be annoying as
you'd still have to look attentively the demo to find back the path to
the new settings. If not temporary, some people may dislike we touch
their settings.
* What if docks are hidden? Should we unhide them, then hide them back
after demo time?
Also regarding the implementation: originally I wanted to just grab the
demo attribute directly from the AppStream metadata file, but I realized
that appstream-glib cleans out unknown attribute from the XML. I could
then simply parse the file with a generic XML parser, but I found
simpler to pre-parse it into a header built within GIMP. I still use
appstream-glib at runtime as it takes care of localization for us
(though in the same time, we also have the localization in the main po
files, so maybe we could just embed the release note strings as well).
See appstream-glib report: https://github.com/hughsie/appstream-glib/issues/431
I add it in libgimpwidgets because we need to also use it on propwidgets
created from there, but it's actually only for core GUI usage, so it's
actually in a private part of the library.
Though it's actually doing quite a basic thing, it is nicer and more
foolproof than a manual g_object_set*() everywhere. Moreover it will be
nicer to grep.
… a given order, not at the same time.
This will be used for the release item notifications to show people
where new or changed features are, but in an ordered blink scenario. For
instance: select a tool first, then blink some tool icon, open the tool
options and finally blink the specific new/changed option. I am hoping
it would help awareness of changes (just words on a web news may make
some features a bit foreign when not used to look in details in advanced
options).
… in specific case when there is already a toolbox.
Even if there is already a toolbox in single window mode (hence it needs
neither to be created nor raised, as there is a single window), we still
want to return the dockable widget which can be used for other things.
What it means is that we will be a bit strict over our <release>
formatting which will have to always be a <p> introduction followed by a
list of items. This is what gimp_appstream_to_pango_markups() expects.
Since so far, this is how all our <release> tags were formatted anyway,
this is not too much of a problem.
Note that I keep the less strict gimp_appstream_to_pango_markup() and
use it for extension's appstream description as we will have no control
over these.
The main reason for this new rule and new display of our release notes
is that I am going to add the ability to click independent release items
so that people can get "blinking" indications of what changed when
relevant.
It should help with scrolling the dockable to make the widget visible,
as I don't see a generic and simple scrolling API for GTK scrollable
containers.
In my own testing, it did work if the dockable was already opened. But
if it was just created by the blink API, then giving focus immediately
doesn't properly scroll. I am not really going to investigate now, but
this should be fixed eventually.
This function will help us raise attention to various widgets in
dockables by blinking them similarly to how we blink locks or visibility
icons.
I associate this with the fact that property widgets identifier will be
the property name, so we get identifiers for free when creating widgets
through the propwidgets API.
… on the line art source.
Also now the default tooltip itself will be more appropriate rather than
reusing the "fill-transparent" property blurb (maybe I should have made
this its own property in fact).
This is the same thing as setting the max gap length to 0, except that
it would mean constantly having to play with the gap length and possibly
losing settings you carefully tweaked. Instead with this additional
settings, we hide the gap length settings when automatic closure is
disabled.
Also it makes kind of a nice parallel with the "Manual closure" settings
which can also be enabled/disabled similarly.
Since we can't select a source, the source tools would fail stroking
with an error. It was usable when stroking a path or selection as we
can have the source tool started while running these. Since only one
tool can be started at once, this is not possible when running bucket
fill tool (it would require some logics change on tools).
This change has 2 parts: add an "insensitive" column to
GimpContainerComboBox (allowing to mark some cells as insensitive), then
use this new attribute in the GimpBucketFillOptions to show all source
tools as insensitive.
There are clearly 3 types of settings:
1. How the line art is detected.
2. How do we additionally close line art.
3. How to handle fill borders.
Additionally I am rewording some options:
- "Allow closing lines in selected layer" -> "Manual closure in fill
layer"
- Adding the "Maximum gap length" into an "Automatic closure" frame to
hopefully make a parallel with the "manual" closure settings.
- "Allow completely transparent regions to be filled" -> "Detect opacity
rather than grayscale" (only within the context of the line art bucket
fill) because the main idea of this option is really here that we
detect lines as being opaque pixels, rather than detecting lines are
being dark pixels.
Finally don't hide the manual closure frame when in a configuration
where it won't be taken into account. Only make it insensitive. Having
options disappear is not so nice. Usually you want to gray them out to
have people realize they are simply not always usable.
Jehan