Add completion provider for CSS functions

[vanillajonathan]

PR Checklist

Please check if your PR fulfills the following requirements:

• I have read, and I am following the Contributor guide
• I have read, and I understand the Code of Conduct

PR Type

What kind of change does this PR introduce?

• Bug fix
• Feature
• Chore (refactoring, formatting, local variables, other cleanup)
• Documentation content changes

What is the current behavior?

Issue Number: N/A

What is the new behavior?

Does this PR introduce a breaking change?

• Yes
• No

Other information

[sourcery-ai]

Sourcery Code Quality Report

✅  Merging this PR will increase code quality in the affected files by 0.13%.

Quality metrics	Before	After	Change
Complexity	2.74 ⭐	2.74 ⭐	0.00
Method Length	55.45 ⭐	55.90 ⭐	0.45 👎
Working memory	4.64 ⭐	4.57 ⭐	-0.07 👍
Quality	80.07% ⭐	80.20% ⭐	0.13% 👍

Other metrics	Before	After	Change
Lines	297	298	1

Changed files	Quality Before	Quality After	Quality Change
gaphor/ui/elementeditor.py	80.07% ⭐	80.20% ⭐	0.13% 👍

Here are some functions in these files that still need a tune-up:

File	Function	Complexity	Length	Working Memory	Quality	Recommendation
gaphor/ui/elementeditor.py	EditorStack.show_no_item_selected	4 ⭐	131 😞		67.00% 🙂	Try splitting into smaller methods
gaphor/ui/elementeditor.py	PreferencesStack.open	2 ⭐	124 😞	6 ⭐	72.97% 🙂	Try splitting into smaller methods

Legend and Explanation

The emojis denote the absolute quality of the code:

• ⭐ excellent
• 🙂 good
• 😞 poor
• ⛔ very poor

The 👍 and 👎 indicate whether the quality has improved or gotten worse with this pull request.

---

Please see our documentation here for details on how these metrics are calculated.

We are actively working on this report - lots more documentation and extra metrics to come!

Help us improve this quality report!

[amolenaar]

Really cool to have function completion as well. Thanks a lot, @vanillajonathan,

I think the difference with the current css property completion provider are very small. I think we can DRY this code and have all completion code in the same module.

[amolenaar]

I think we should limit this to the functions that Gaphor supports: hsl, hsla, rgb, and rgba.

[vanillajonathan]

Well, I would guess anything that WebKit support would work?
I think the other functions would probably be possible to use too, even though I think they're unlikely to be much used, as many are for advanced uses and seldom used.

[amolenaar]

Well, I would guess anything that WebKit support would work?

We're not using webkit for rendering. Instead we use Cairo and a the items render themselves on the canvas, with some styling.

[vanillajonathan]

Oh, I am aware which CSS properties and functions can be used in Cairo.

[amolenaar]

In Gaphor we tend to use file names of concatenated words, no undescore (e.g. treecomponent.py).

[vanillajonathan]

So then this would be cssfunctioncompletionprovider.py, yuck!
Quite hard to read.

[amolenaar]

Both CompletionProvider classes can be added to csscompletion.py.

We have quite some cases where more than one class is added to a module. It allows us to group similar concepts cleanly. We're not writing Java, after all 😃 .

[vanillajonathan]

True!

[amolenaar]

The code for this class is almost a copy of CssPropertyCompletionProvider. I think it's pretty simple to create a simple parameterizable version of a completion provider. Then both completion provider can be in the same file (gaphor/ui/csscompletion.py).

[vanillajonathan]

Yes, it is, right now, but but GtkSourceView is built to support multiple active completion providers, and we can modify these so they differ from each other.
Example it could append () after the function name when inserted. It could append a : after the attribute name when inserted.

They also have different do_get_title and do_get_priority. The title isn't used by GtkSourceView today, but in future versions it might be. The priority can be used for ordering, example so we can have attributes ordered before functions.

Later, we can add completion providers for colors (they will have a different priority too), and for units for which we might to present when a number is entered, so it is good to keep completions for different things in different completion providers.

[amolenaar]

I like the idea of appending () and :.

The priority can be used for ordering, example so we can have attributes ordered before functions.

Thinks like title and priority can be past as constructor parameters to a generic base class, where we handle the common boilerplate.

Later, we can add completion providers for colors (they will have a different priority too), and for units for which we might to present when a number is entered, so it is good to keep completions for different things in different completion providers.

I see your point. Indeed completers could defer. However, I would not focus to much on later 😉 .

[vanillajonathan]

I like the idea of appending () and :.

The appending of characters upon insertion would be done in the do_activate method.

Different providers could have different implementations for the is_trigger method, e.g. to show units (such as px) when the user types a digit.