WIP: Add support for vuetify theming

This PR allows overriding the default Vuetify theme configuration.
Tasks:

[x] app context config to override the default theme;

property will be colorTheme;

[x] toolbar control to switch between light/dark modes;
[x] write set of default colors (app-config);

fallback to default if no colors are provided;

[ ] update docs;

colorTheme property;
tips on how to pick theme colors;

[x] locales;

Extras:

allow Vuetify theme presets (material studies).

requires webpack version >= 4

Closes #202

Hi @JakobMiksch,
I added a few more fixes to account color schemes that use a light color as primary color. The default color for text/icons is white but in this case we want it to be a dark tone for the primary components.
Also added a section to the documentation to explain how to use the "theme" config in the app.config.json. Should I also write a brief tutorial on how to pick colors for the colors classes that Wegue has?
ps: whenever you have some free time, would you please review these two translations? The context of "start" and "stop" is start recording / stop recording.

It would be great to have a small explanation in the docs how to create color schemes. Or where generate them.

Hi @ntma.
First of all this is some awesome work and I'm happy to see you got going!
I finally found some time to look over the code briefly and do a little testing. Here are my findings so far:

I think we should streamline the theming / color related attributes in the component implementations. (@chrismayer This is also a question to the PM) Since we now have multiple colors to manage, 1 configurable color for components is no longer sufficient. My proposal would be to hardwire all the mappings between colors and the theme in the component implementations itself and remove color related component attributes entirely. This will also clean up the app template, which currently is cluttered with piping through color definitions.

This also applies to some specific attributes, e.g.'selColor' in BgLayerList, which are still present but no longer in use. Maybe you could re-check, so there are no unused leftovers.

I'm a little bit confused: Should the toolbarbuttons on the app-bar now appear in the secondary color? I currently don't see this happening. But maybe this is also not desired?!
I realized you changed some of the button shapes, e.g. BgLayerSwitcher. The idea behind using toggle groups was to work towards all buttons having the same look and feel (e.g. pressed shape).
What is the status quo about removing the 'darkLayout' module configuration property (corresponds to the 'dark' attribute in the components)? Can this now be handled generically by your new theme switcher? In this context I realized that the panel of the hamburger no longer uses the primary color. Is this something the material design specification asks us to do? The idea behind changing it to the color of the app-bar was, that no dark layout wise destinction has to be made, whether a button is located on the app-bar or hamburger menu.
Maybe you could introduce a backward compability warning that the 'baseColor' configuration property is no longer supported (see migrateAppConfig in main.js)
For merging the configured theme with the default theme you could also use util/Object.js/mergeDeep - however I'm not sure if this make sense here. Maybe it's a better approach to default 'secondary' and 'accent' colors to the 'primary' if the latter are not configured?!
I propose you could add your new settings, e.g. theme switcher to the other application contexts (app-conf-projected and app-conf-projected - but not to app-conf-minimal)

Thats it from me, sorry for the lengthy post.

Hi @fschmenger ,
I'll try to make it short :+1:

I think we should streamline the theming / color related attributes in the component implementations. (@chrismayer This is also a question to the PM) Since we now have multiple colors to manage, 1 configurable color for components is no longer sufficient. My proposal would be to hardwire all the mappings between colors and the theme in the component implementations itself and remove color related component attributes entirely. This will also clean up the app template, which currently is cluttered with piping through color definitions.

Yes we can do this. I wasn't sure at which level Wegue should control it's colors so I tried to set the control to the top level: appHeader, appFooter and the map.

2.` I'm a little bit confused: Should the toolbarbuttons on the app-bar now appear in the secondary color? I currently don't see this happening. But maybe this is also not desired?!

I am not sure if you are referring to the panel of the hamburger menu in the app-bar. If so, the answer to 4. may also answer this question.

I realized you changed some of the button shapes, e.g. LocaleSwitcher. The idea behind using toggle groups was to work towards all buttons having the same look and feel (e.g. pressed shape).

Hmm, but the LocaleSwitcher functions as a drop-down menu while the others (e.g: Recorder) activate a feature. That's the logic that I was following. I was just trying to give an extra and of course we can revert this change at any time :+1:

What is the status quo about removing the 'darkLayout' module configuration property (corresponds to the 'dark' attribute in the components)? Can this now be handled generically by your new theme switcher? In this context I realized that the panel of the hamburger no longer uses the primary color. Is this something the material design specification asks us to do? The idea behind changing it to the color of the app-bar was, that no dark layout wise destinction has to be made, whether a button is located on the app-bar or hamburger menu.

The darkLayout is now controlled generically by Vuetify. In my perspepctive, the baseColor and darkLayout acted like twins in the component configuration. If we streamline one, the other should go with it too. If this isn't desired, we can revert the change.
Regarding the hamburger menu and knowing that:

primary color should be used in the main components (header, footer, brand logo);
secondary color should be used to accent controls;
surface color should be used as the background of panels;
then the panel should have a surface color as background with a secondary color for the buttons.

There is a short insight about this topic in the Primary Colors, Secondary Colors and Surface Colors sections of this material design doc.

Maybe you could introduce a backward compability warning that the 'baseColor' configuration property is no longer supported (see migrateAppConfig in main.js)

Sure thing, I will add this.

For merging the configured theme with the default theme you could also use util/Object.js/mergeDeep - however I'm not sure if this make sense here. Maybe it's a better approach to default 'secondary' and 'accent' colors to the 'primary' if the latter are not configured?!

Interesting, I didn't know about the mergeDeep. Either way, seems diplomatic solution :+1:  My concern is that a user only sets colors for the light theme. In which case the dark theme will fallback to the default blue of Vuetify...

I propose you could add your new settings, e.g. theme switcher to the other application contexts (app-conf-projected and app-conf-projected - but not to app-conf-minimal)

Sure, I will do this.

Hi @ntma, big thanks for your ongoing work on this. Looks very very promising :+1:
I agree that if we introduce theming by vuetify everything should be handled by it. Concurrent approach by having some props set in the app-config outside of the theming config block would cause confusion.

Hi @ntma, thanks for the clarifications and links to the notable sources.
Since we have a response from the PM, I think we're good to finalize the topics mentioned in 1) and 4) and control colors at a theme level only. As a summary

Please remove the darkLayout property from app-configs. For the color wise distinction between a button being located on the app-bar or hamburger menu (I will ask the PM for cofirmation further below), you could possible do something like this in AppHeader.vue::getModuleButtons

     getModuleButtons (target) {
      const appConfig = Vue.prototype.$appConfig || {};
      const modulesConfs = appConfig.modules || {};
      let buttons = [];
      for (const key of Object.keys(modulesConfs)) {
        const moduleOpts = appConfig.modules[key];
        if (moduleOpts.target === target) {
          buttons.push({
            type: moduleOpts.win ? 'wgu-toggle-btn' : key + '-btn',
            moduleName: key,
            // Relay the parent control to the button for coloring.
            // Or alternatively compute a 'color' property here based on target==='toolbar',
            // this will avoid redundancies in the component implementations until we have an abstraction for all toolbarbuttons - see #260
            target: target,
            ...moduleOpts
          });
        }
      }
      return buttons;
    }

Otherwise remove color (this also involves similar color related attributes and default color values ) and dark props from the components.
Remove all other references/initializations to the properties described above from the app-templates.
Update documentation and unit tests accordingly.

Regarding 2) I misread the code ;). I can see you are using the primary color for all the buttons on the app-bar now, which is what I expected.
Otherwise I can see you're pretty much there!
@chrismayer The remaining questions to the PM:
Regarding 4) Are we good to change the background color of the hamburger menu back to 'surface color' ? This is probably a bit opionated, as the hamburger menu is a special dropdown which can also be seen as an extension to the app-bar (and also requires some coloring switches in the code). However I can see the point of Nuno's recommendation.
Regarding 3) You should make a clear ruling when buttons should have a toggle/pressed state. See Nuno's comment above.

Hello all,
@chrismayer Glad that the PR is meeting the expectations! :+1: I will try my best to finish it as soon as possible, since I will be a bit busy for the next days.
@fschmenger

Since we have a response from the PM, I think we're good to finalize the topics mentioned in 1) and 4) and control colors at a theme level only.

I will advance to this change then :+1:

Regarding 2) I misread the code ;). I can see you are using the primary color for all the buttons on the app-bar now, which is what I expected.

No problem! I was all over the code for this PR so some changes may not be that clear.

@fschmenger Indeed, thanks for noticing that!
I had it in my notes but eventually forgot to commit that explanation.

Hi guys,
Finally I believe that this PR is coming to it's conclusion. In the last changes:

the 'onsurface' color was removed . This class was being applied to components that were clearly not over the 'surface';
the 'accent' color was moved to be handled internally by Wegue. This is a color class used to highlight focused fields (v-text-field/v-select) in the dark mode. The reasons for this change is: the occasional use of the class; and the fact that this class will in most cases be the same color as the secondary (which is already an accent color).
removed occurrences of the deprecated baseColor and darkLayout. From now on, components handle the color/dark internally. Except for the components that can be placed in the toolbar or hamburger menu (since the toolbar uses a primary color and the hamburger a secondary).
added the remaining semantic colors (info/success/warning). Wegue isn't using any of these but I believe that sooner or later they will be needed.
added documentation on picking colors for the "light"/"dark" themes;
updated unit tests;

Any question please let me know. Critics are also welcome :+1:

Hi @ntma,
I gave it an extended code review and test today:
I can see it's coming to a conclusion and I really like most of the recent changes, e.g. I can see clear pattern now, at which level color values are assigned. The documentation is also nice and verbose.
Most of the remaining findings are minor (lots of text though ;)

I ran a little grabbing for css colorization and hardcoded colors. It would be nice to tweak these rules in the process of theming. Maybe you could have a look, since you already have expert knowledge there.

I noticed hovering on the sheet of the background-layer currently does nothing for dark mode. Maybe theres a better generalistic solution for the following, so the color values can be removed?
https://github.com/meggsimum/wegue/blob/5c4e8d8020e85ba0e6bc39f5b00361f7f4ce30ca/src/assets/css/wegue.css#L35-L39
Can we use the standard surface color for the tooltip, e.g. something along the lines of assigning v-sheet as class ? https://github.com/meggsimum/wegue/blob/5c4e8d8020e85ba0e6bc39f5b00361f7f4ce30ca/src/components/ol/Map.vue#L442-L443
Remove uncommented block in https://github.com/meggsimum/wegue/blob/5c4e8d8020e85ba0e6bc39f5b00361f7f4ce30ca/src/components/geocoder/Geocoder.vue#L213-L222
This rule wont work without !important in a production build (footer link color broken)
https://github.com/meggsimum/wegue/blob/5c4e8d8020e85ba0e6bc39f5b00361f7f4ce30ca/app-starter/components/AppFooter.vue#L35-L38
Probably the help window link should use a default color, as this is not very theme compliant. I tried removing red--text darken3 but this won't work in production build again. Maybe links are worth a review in general.
https://github.com/meggsimum/wegue/blob/5c4e8d8020e85ba0e6bc39f5b00361f7f4ce30ca/src/components/helpwin/HelpWin.vue#L19

I noticed that hover colors of the toolbarbuttons on the app-bar are now either gone or hardly visible, at least when using the default style. Anyway in disregard of the theme, toggle-buttons now have another hover color than the other buttons, which I find a bit disturbing (check out the behavior before the theme change).
Personally I would prefer to factor out the following code (including fallbacks) into ColorThemeUtil, so we keep the codesize of main.js to a minimum.
https://github.com/meggsimum/wegue/blob/5c4e8d8020e85ba0e6bc39f5b00361f7f4ce30ca/src/main.js#L51-L89
I'm not sure if I like the following code block, as this will be ackward to replicate for other components using a v-combobox (similarly for AttributeTableWin). But then it might be to the specific nature of where the controls are placed.. Maybe you could re-check if there is a more straightforward solution? If not it's probably a good idea to wrap up commonly used computed properties for theming (mainly isDark, forceDark and the hsla() values) in a mixin. See src/mixins
https://github.com/meggsimum/wegue/blob/5c4e8d8020e85ba0e6bc39f5b00361f7f4ce30ca/src/components/geocoder/Geocoder.vue#L8-L13
Regarding the color of hamburger menu panel (already mentioned this in my last review): If i got the material design spec correctly, then we're free to do there whatever we like. Not that I like one color better than the other, but this would make the code a lot simpler to maintain, as we could remove color attributes and switches from toolbarbuttons entirely. Waiting for the PM @chrismayer to have a word on this.

Modal sheets
Use contrasting colors on surfaces that appear on-screen temporarily, such as navigation drawers and bottom sheets. Usually these surfaces are white, but you can use your app’s primary or secondary color.

Finally a big up to you. Overall a great job and big step forward for Wegue!

Hi @ntma, very big thanks to you for ongoing big work! This use huge and an important step for Wegue. Since things are really busy here I "only" checked out your branch and checked the visual results in the apps. Looks really, really good! Here some remarks from my side:
TODO

dark mode switcher needs to be a ToggleButton IMHO, so it gets clearer for the user that dark mode can be switched on/off
The colors of the other apps (appCtx=projected (orange primary :netherlands: ) and appCtx=minimal (greenish primary) ) need to be restored

To be discussed

The headers of the module windows are hard to recognize in the default dark mode (since body color is quite similar), is this intentionally?
Colors of the buttons in the vertical toolbar (hamburger menu) differ from the ones in the toolbar. Intentionally? I think this is what @fschmenger mentioned in his comment.

Caution: I am neither designer nor a MD expert. If the two point above have to be like they are in MD, please ignore them.
Important

All color configurations should now be done by theming with cool defaults (as stated in my last comment in here). From my quick check this seems to be done at most points. So for all of us, if someone spots a UI color not declared by themes, please report.

Regarding the code: Since I doubt that I find a slot for an extensive code review in the next weeks and I don't want to block this: I am fine if @fschmenger and @JakobMiksch (and of course anyone else who is willing to do a review) give their OK.

Hi guys,
First of all, big thanks for the effort put into reviewing the changes of this PR :+1:
The majority of the requested changes are clear so I'll proceed on applying them.
I just have a couple of replies for @fschmenger and @chrismayer.
For @fschmenger

Probably the help window link should use a default color, as this is not very theme compliant. I tried removing red--text darken3 but this won't work in production build again. Maybe links are worth a review in general.

Grr, that link escaped the refactoring. When you suggest using a default color, are you referring to any of the color classes that this PR adds (e.g: primary/secondary)?
For @chrismayer

The headers of the module windows are hard to recognize in the default dark mode (since body color is quite similar), is this intentionally?

From the content that I researched, I believe it's intentional. There is a brief explanation about this in this material design documentation. Of course this serves only as guidelines so we are free to adjust the shades of grey to provide a clear contrast between headers and body.

Colors of the buttons in the vertical toolbar (hamburger menu) differ from the ones in the toolbar. Intentionally? I think this is what @fschmenger mentioned in his comment.

Yes it's intentional. The material design documentation suggests the use of the "secondary" color to accent controls that can be interacted with. But again, this is a suggestion, so I believe that we are free to make some exceptions.

@ntma Thanks for your feedback. Regading your questions towards me:

The headers of the module windows are hard to recognize in the default dark mode (since body color is quite similar), is this intentionally?

From the content that I researched, I believe it's intentional. There is a brief explanation about this in this material design documentation. Of course this serves only as guidelines so we are free to adjust the shades of grey to provide a clear contrast between headers and body.

OK, then it is fine for me.

Colors of the buttons in the vertical toolbar (hamburger menu) differ from the ones in the toolbar. Intentionally? I think this is what @fschmenger mentioned in his comment.

Yes it's intentional. The material design documentation suggests the use of the "secondary" color to accent controls that can be interacted with. But again, this is a suggestion, so I believe that we are free to make some exceptions.

No, that is fine for me. Was just curious how this all works together.
So no further work regarding my 2 questions IMHO.

Hi @ntma

Grr, that link escaped the refactoring. When you suggest using a default color, are you referring to any of the color classes that this PR adds (e.g: primary/secondary)?

Yes, I think link colors (as all colors in Wegue) should now be handled by theming. I'm not sure what the material design spec has to say on colorizing links. Maybe use a secondary color or just the text-color from the parent block without any specific changes? Hardcoding colors to red will apparently have very undesirable effects depending on the used theme.
Whatever solution you come up with, I recommend testing your final solution in a production build, as something goes wrong there currently with links.

Hi @fschmenger ,

Yes, I think link colors (as all colors in Wegue) should now be handled by theming. I'm not sure what the material design spec has to say on colorizing links. Maybe use a secondary color or just the text-color from the parent block without any specific changes? Hardcoding colors to red will apparently have very undesirable effects depending on the used theme.
Whatever solution you come up with, I recommend testing your final solution in a production build, as something goes wrong there currently with links.

Yes I agree with that. I will search the MD documentation for any reference on the links colors... but my guess is the same as yours. Perhaps we can use the secondary--text, which is a class that is automatically generated by Vuetify using the secondary color.
Regarding the all colors in Wegue should now be handled by theming, I am afraid there will be some that we won't be able to control unless we override some of the Vuetify CSS classes (at least with Vuetify 2.x). I was searching a way of controlling the "surface" color via Vuetify, and I bumped into this issue.

Hi @ntma,

Regarding the all colors in Wegue should now be handled by theming, I am afraid there will be some that we won't be able to control unless we override some of the Vuetify CSS classes (at least in Vuetify 2.x).

Just clearify my point. I'm not talking about exposing surface color configuration etc. to theming, as this is currently not supported - if I got you right !? What I was intending to do, is getting rid of custom css colorization code, by e.g. mapping controls like custom tooltips to standard vuetify controls, so the implicitly defined vuetify surface colors will be used for those. In an ideal world we would have no more css code to customize colors. If this is not possible for one or the other reason, you could probably mark the codeblocks pointed out by me with some TODO Review ccs colorization

@chrismayer The last commit restored the colors for app-conf-projected (dark orange) and app-conf-minimal (dark green) (result for both light and dark variants in the sections bellow).
Only the primary color was restored (the secondary color will take the same value as the primary). Let me know if we need to adjust the color tones or add secondary colors to the configuration :+1:
Projected

Minimal

@fschmenger

Just clearify my point. I'm not talking about exposing surface color configuration etc. to theming, as this is currently not supported - if I got you right !? What I was intending to do, is getting rid of custom css colorization code, by e.g. mapping controls like custom tooltips to standard vuetify controls, so the implicitly defined vuetify surface colors will be used for those. In an ideal world we would have no more css code to customize colors. If this is not possible for one or the other reason, you could probably mark the codeblocks pointed out by me with some TODO Review ccs colorization

Yes, you got me right. Sure, as a last resort I will mark the blocks :+1:

@ntma
Just looking at the restored color scheme (b01e36265ffd2cef379be8105fcdba9106e8fedd). Minimal looks good to me, for projected we had white for buttons and primary text.

@fschmenger

Just looking at the restored color scheme (b01e362). Minimal looks good to me, for projected we had white for buttons and primary text.

In this case it seems the orange is not dark enough for the text to be white. This is controlled by our brightness function when there is not onprimary/onsecondary colors defined in the colorTheme.
I see three options here:

we change the orange to a darker tone;
we set both "onprimary" and "onsecondary" to white in the app-conf-projected.json;
we adjust the checkLuminance code, although this one will be hard to justify;

@ntma
I think we should go with the simplest approach:

we set both "onprimary" and "onsecondary" to white in the app-conf-projected.json;

If there are downsides from doing that, I suggest you have a word with @chrismayer.

I just re-checked the following code-block from my previous comment (1)
https://github.com/meggsimum/wegue/blob/5c4e8d8020e85ba0e6bc39f5b00361f7f4ce30ca/src/assets/css/wegue.css#L35-L39
I didn't remember at that time of writing this but I introduced this rule to give the button on the map an OL like look and feel (behaviour similiar to the zoom buttons). Since this is a subject of further CRs - see sketch from @chrismayer in #266 - we're good to leave that as is for now.

@fschmenger
I was trying to fix the hovering on the BgLayerList and ended up with a solution that uses v-hover with a v-overlay. (code here)
It is hard to justify the 0.2 opacity with the color="grey", but it seems to apply a similar overlay that is applied with hovering vuetify buttons. Is this acceptable for Wegue?

Hi @fschmenger ,

I'm not sure if I like the following code block, as this will be ackward to replicate for other components using a v-combobox (similarly for AttributeTableWin). But then it might be to the specific nature of where the controls are placed.. Maybe you could re-check if there is a more straightforward solution? If not it's probably a good idea to wrap up commonly used computed properties for theming (mainly isDark, forceDark and the hsla() values) in a mixin. See src/mixins

Regarding the theming for the Geocoder and the AttributeTableWin I ended up using the solo, filled and dark properties of the "v-select" and "v-combobox" to create the effect of a solo field (more info about "Solo Fields" on toolbars in this material doc).
In theory, the solo property should be enough to create the desired effect for both light and dark variants... but for some reason, when we add solo in the light theme variant, the field background is forced into a pure white color.

Hence the reason why we use the filled for the light variant and solo for the dark.

The last commit also adds a mixin to expose utilities related to theming. Such as:

isDarkTheme - checks if the theme is in dark mode;
isPrimaryDark - checks if the primary color is a dark color;

Hi @ntma,
thanks for addressing all the proposals that quickly!

I was trying to fix the hovering on the BgLayerList and ended up with a solution that uses v-hover with a v-overlay. (code here)
It is hard to justify the 0.2 opacity with the color="grey", but it seems to apply a similar overlay to when hovering Vuetify buttons. Is this acceptable for Wegue?

From looking at the wegue code base i can see the reason for hovering not working together with the dark theme that well:
v-card--hover:focus, .v-card--hover:hover {
    box-shadow: 0 5px 5px -3px rgb(0 0 0 / 20%), 0 8px 10px 1px rgb(0 0 0 / 14%), 0 3px 14px 2px rgb(0 0 0 / 12%);

The dark theme color is already too dark for the box-shadow to take any effect. I think this will hit us in many situations. So I agree with you, that a specific fix at this place is just not worth it. We could either think about making the dark theme default colors just a bit lighter or just ignore the problem at all and see if a future vuetify version has a generic fix for that. Probably just roll it back for now ?!
Regarding the fix introduced for ToggleButton in b1e76848ecda65edd0a45ab9b9419ebd61bd95d3.
Doesn't it work much simpler, if you just assign the color property to the v-btn in favor of the css rule?
<v-btn icon :value="true" @click="toggleUi" :color="color">
    <v-icon :color="color" medium>{{icon}}</v-icon>
</v-btn>

Regarding the theming for the Geocoder and the AttributeTableWin, I will look into the solo property stuff and give you feedback later.

Hi @ntma, I had a look at the solo fields now in conjunction with 4c2cbf357bbf25f73331fd156558b87fc39da2ed.
I'm a bit puzzled, why this is actually required. For a test I removed the solo attribute, set the filled attribute to always true and removed the corresponding css code in wegue.css. Something along these lines, for e.g. AttributeTable.
     <v-select
        v-model="selLayer"
        color="accent"
        item-color="secondary"
        :dark="isPrimaryDark"
        filled
        outlined
        class="wgu-vector-layer-select"
        :items="displayedLayers"
		    :item-text="item => item.get('name')"
        :menu-props="{
          bottom: true,
          'offset-y': true,
        }"
        dense
        return-object
        hide-details
        :label="$t('wgu-attributetable.selectorLabel')"
        ></v-select>

I have to say I couldn't really spot the difference, but then I didn't test this across all the material studies. Maybe you could review this or give me an explanation. :)

Just used a little evening spare time to change the plain html tables of the infoclick module into a vuetify based v-simple-table

@fschmenger thanks for this. Please provide a separate PR for this. I guess @ntma has to merge in the current master from time to time :wink: so I think merging the PR in advance would be an option. The other way round would also be OK, that you place your PR after this (theming) is merged. About the order I have no strong opinion (what fits better for you @fschmenger and @ntma). But any way you choose a separate PR is preferred.

@ntma @fschmenger @JakobMiksch What is the current stage of this? Does it need more work or is it good to go? No hurry, just for information.

@chrismayer
Alright, I will post the changes to infoclick after this as a separate PR, as it depends on theming support.
Regarding the state of this PR, Nuno is almost there. I have a couple of points mentioned above to review on finalization. Also the unit tests are currently failing.

Hi @fschmenger @chrismayer, sorry for the absence but I have been very busy with my job. I'll get back to this PR as soon as possible to answer the questions directed to me.
In the meanwhile, merging any PR that depends on this update is ok for me!  I'll rebase the changes later :+1:

thanks for @ntma and @fschmenger for the ongoing work. I did not follow all the recent details anymore. Let me know if you need an additional review. Otherwise I trust the approval of the others.

Hi guys, I am back!
So, to reply some of the pending questions/reviews from @fschmenger:

The dark theme color is already too dark for the box-shadow to take any effect. I think this will hit us in many situations. So I agree with you, that a specific fix at this place is just not worth it. We could either think about making the dark theme default colors just a bit lighter or just ignore the problem at all and see if a future vuetify version has a generic fix for that. Probably just roll it back for now ?!

I think the problem will persist even if we change the dark theme tones, as the hovering shadow will conflict with the dark shades. I could ignore the issue for now but I feel that Vuetify (like many other UI frameworks) are in a lot of pressure to release their stable version for Vue3. Details like this are probably not their priority right now :disappointed: Should I still revert the changes?

Regarding the fix introduced for ToggleButton in b1e7684.
Doesn't it work much simpler, if you just assign the color property to the v-btn in favor of the css rule?

Indeed, nice catch! One more caveat for Vuetify :+1: I will change it to your suggestion!

EDIT: Since the specific UI design of the 2 controls is subject to discussion / change in the future (see #243 and #253) I would rather opt for a simplistic and fairly straightforward - rather than perfect - solution here.

Regarding the solo fields, since we are not opting for the near perfect solution (and I totally agree with this decision), should this field take the same color as the header color?

I wonder if you like it, it's a little more simplistic. If so I can either provide this as a follow up PR or suggest as a code change and we get it incorporated in this run.

I agree with the infoclick change. Having custom components converted to Vuetify components will simplify the material theming  :+1:

Hi @ntma,
thanks for the investigation and the feedback.

I think the problem will persist even if we change the dark theme tones, as the hovering shadow will conflict with the dark shades. I could ignore the issue for now but I feel that Vuetify (like many other UI frameworks) are in a lot of pressure to release their stable version for Vue3. Details like this are probably not their priority right now 😞 Should I still revert the changes?

I'd say yes. Sorry for bringing up the issue at all. But lately I had time to look into it and noticed that this is a general vuetify issue with dark themes. I think we have to live with hovering effects being lost for dark tones for now. IMO having a straightforward code should be prefered over a specific fix, that won't remove the problem at global scope.

Regarding the solo fields, since we are not opting for the near perfect solution (and I totally agree with this decision), should this field take the same color as the header color?

Did you check the snippet I proposed. I couldn't see the drawback while it looked to me like we're retaining the accent colors. Or am I missing something?

One last thing from my part, that I cannot see being finally adressed in the discussion above.

Regarding 4) Are we good to change the background color of the hamburger menu back to 'surface color' ? This is probably a bit opionated, as the hamburger menu is a special dropdown which can also be seen as an extension to the app-bar (and also requires some coloring switches in the code). However I can see the point of Nuno's recommendation.

Again i can only point out, that for my personal taste I would opt for the simplest code-wise solution, and use the primary color for the hamburger menu (especially as it seems to me as this is not explicitly discouraged by the MD spec). I propose @chrismayer should make a clear ruling on this and then we go with whatever he has to say.

Hi @fschmenger ,

I'd say yes. Sorry for bringing up the issue at all. But lately I had time to look into it and noticed that this is a general vuetify issue with dark themes. I think we have to live with hovering effects being lost for dark tones for now. IMO having a straightforward code should be prefered over a specific fix, that won't remove the problem at global scope.

It's totally fine. I understand that reaching a future proof solution isn't always easy :slightly_smiling_face: I'll revert the changes in the next commit.

Did you check the snippet I proposed. I couldn't see the drawback while it looked to me like we're retaining the accent colors. Or am I missing something?

I did. The main difference is the 3rd elevation added by the 3rd dark shade (docs about  material elevation here).  Here are two visuals (first with solo and second without), where the red numbers represent the three elevations.
With solo:

Without solo:

Elevation is essential to differentiate components (specially in the dark mode). Lighter shades will simulate positive elevation while darker shades will simulate negative.
In my point of view, solo fields should that a negative elevation (in respect to their parent components). Although they are components that should stand out, they are at the same time recipients for user input. And thus should look like an embedded field into it's parent component. Hence my effort on trying to make it look like that :grin:

Hi @ntma, thanks for the screenshots regarding the solo fields - I can spot the difference now :)
I'm a bit undecided whether this is a good feature for the following reasons:

Wegue didn't have any concept on accecting those fields over a primary surface prior to this PR (I think this has been mentioned somewhere above)
The implementation is currently limited to 2 controls, that may be subject to changes in the future.
Last but not least the solution is not very maintainable. If we we're to add future controls over a primary surface, then these would require the same code switches and most importantly the same css rules that you introduced in wegue.css.

Overall to me the feature looks too minor to justify a bunch of specific code.
I leave the final decision to the meggsimum guys - @chrismayer, @JakobMiksch what's your opinion on this?
IMO, if we decide to keep this in, then for the sake of maintainance you should probably wrap up the wegue.css rules by a class and assign it to the respective controls.

Hi @ntma,
thanks for your ongoing work and your gigantic patience with the huge amount of remarks, discussions and suggestions by the reviewers. I really appreciate that you're still on this :+1: But to not overstretch you patience :wink:  and to get this killer feature into the Wegue code base we should shorten this a bit up. Therefore I propose the following:
We should go the simplest approach for open remarks/request to get them quickly done. For the hamburger menu we should use using primary color (simplest approach? Correct me if I am wrong).
For solo fields I have no strong opinion, please also go a simple, fast and acceptable way here.
All other (hopefully minor) things, which can be improved in the future we should live with for now. These should be formulated in issues, so they are not forgotten.
So @ntma would you please do a last round of providing final adaptions, if necessary? Would be very appreciated. Afterwards give us a ping that this is finalized.
@fschmenger Would you give afterwards a last check regarding heavy bugs or blockers? If none I'd happily merge this and we proceed from there.
Again thank you all (especially @ntma and @fschmenger) for your huge work on this!

Hi @chrismayer ,
Glad that you appreciate the effort done in this PR! :grin:

So @ntma would you please do a last round of providing final adaptions, if necessary? Would be very appreciated. Afterwards give us a ping that this is finalized.

I did the last round and:

the hamburger menu is now primary;
solo fields are now filled fields. The visual difference can be seen in  this comment. In the end, having a 3rd elevation may not look that bad as long as this property is uniform across all fields over primary colors. Unfortunately this nasty override is still required for the cases where we override the "onprimary" color (ie: app-conf-projected.json).

As a last remark, this PR adds the ability of using the Vuetify color classes as CSS variables (docs here). I didn't test it but I believe these variables can be used to style the map features if required.
And with that done, I conclude this work. Thank you all for the patience on reviewing this PR. If there is still something that I missed or requires changes, please let me know :+1:

Hi @ntma, thanks for your ongoing effort.
I can see 2 finalization tasks:

In conjunction with e8b4760042348fe21c2280e12ea269c6ad97ba3b: Could you please remove the following line https://github.com/meggsimum/wegue/blob/43eb1375c9251aeca9f33cc280863c32b5e87302/app-starter/components/AppHeader.vue#L112 and the associated color props from the components/ buttons, so we are consistent with hardwiring of colors on component level.
Are the specific css rules still required since 43eb1375c9251aeca9f33cc280863c32b5e87302? Please either remove them or see my comment above for attaching them to a css class (e.g. 'wgu-select'). https://github.com/meggsimum/wegue/blob/43eb1375c9251aeca9f33cc280863c32b5e87302/src/assets/css/wegue.css#L42-L62

Otherwise this looks good to me!

Hi @fschmenger,

In conjunction with e8b4760: Could you please remove the following line and the associated color props from the components/ buttons, so we are consistent with hardwiring of colors on component level.

Makes sense. Done!

Are the specific css rules still required since 43eb137? Please either remove them or see my comment above for attaching them to a css class (e.g. 'wgu-select').

Unfortunately yes. As far as I know, there is no simple way of overriding the text/border/input color in case the field is over a primary color. The CSS overrides are now wrapped into .wgu-solo-field.
Cheers :+1:

Hi @ntma, thank you for the prompt response and fixes.

Unfortunately yes. As far as I know, there is no simple way of overriding the text/border/input color in case the field is over a primary color. The CSS overrides are now wrapped into .wgu-solo-field.

I'm a little bit confused again, as I can't see the rule taking effect now - why the name of the css class as the associated components are now no longer solo? I asked my DOM inspector to point me to the difference but never saw the theme--light assigned (the wgu-solo-fields always have theme--dark in the class list, even when I toggle the dark mode).
Maybe you can point me to the difference again?

@chrismayer I reviewed the code and ran some additional integration tests on my app with it's specific theme. I think this PR is as good as it can get, so feel free to merge.
@ntma Thanks a lot for going through all the proposals and all the time and energy you invested into this. I'm looking forward to work with you on some topic again in the future! 👍

THIS IS GREAT! :rocket:
Thanks for your fantastic and tireless work @ntma. Very much appreciated. I hope you  stay part of the Wegue community. Would be a great benefit for us all.
Also big thanks to @fschmenger for managing this and for the endless reviews. And of course thanks to @JakobMiksch for your input.
I am going to merge now. :tada:

Thanks for your fantastic and tireless work @ntma. Very much appreciated. I hope you stay part of the Wegue community. Would be a great benefit for us all.

Anytime! I'll try to contribute more whenever I find myself with some spare time :+1:


Recommend vim tutor for learning modal editing

Hi! Thanks for the PR, but I'm afraid I must refuse it because it comes at a bad time: or documentation in docs/*.org is undergoing a rewrite at the moment. workflows.org, in particular, will be moved to our Discourse in the form of learning posts and guides. For the time being I am not accepting any PRs to these files. Sorry for the trouble and thanks for the help!

No worries, I know those docs have been just scaffold for a while, thought I'd toss at least something out there :D


fileNamePattern fails on files such as thing.test.js

Started integrating this into fastify toString and recognized the regex pattern fails on composite files (such as toString.test.js). Working on a fix right now!

There is also a problem with fpStackTracePattern. I updated fastify-plugin to the last version and now it fails on m[1].match(fileNamePattern)[1] because m is null. This is the full stack trace:
TypeError: Cannot read property '1' of null
    at checkName (/Users/maksim/Projects/evologi/evo-shipping/node_modules/fastify-plugin/index.js:48:10)
    at Object.plugin [as default] (/Users/maksim/Projects/evologi/evo-shipping/node_modules/fastify-plugin/index.js:15:29)
    at Object.<anonymous> (/Users/maksim/Projects/evologi/evo-shipping/src/lib/authentication/index.ts:6:1)
    at Module._compile (internal/modules/cjs/loader.js:678:30)
    at Module.m._compile (/Users/maksim/Projects/evologi/evo-shipping/node_modules/ts-node/src/index.ts:430:23)
    at Module._extensions..js (internal/modules/cjs/loader.js:689:10)
    at Object.require.extensions.(anonymous function) [as .ts] (/Users/maksim/Projects/evologi/evo-shipping/node_modules/ts-node/src/index.ts:433:12)
    at Module.load (internal/modules/cjs/loader.js:589:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:528:12)
    at Function.Module._load (internal/modules/cjs/loader.js:520:3)
    at Module.require (internal/modules/cjs/loader.js:626:17)
    at require (internal/modules/cjs/helpers.js:20:18)
    at Object.<anonymous> (/Users/maksim/Projects/evologi/evo-shipping/src/routes/api/v1.ts:1:1)
    at Module._compile (internal/modules/cjs/loader.js:678:30)
    at Module.m._compile (/Users/maksim/Projects/evologi/evo-shipping/node_modules/ts-node/src/index.ts:430:23)
    at Module._extensions..js (internal/modules/cjs/loader.js:689:10)

As you can see i use typescript with ts-node for the dev setup. There are two different problems here:

fpStackTracePattern pattern serches just for plugin word, in my case it is needed something as const fpStackTracePattern = new RegExp('at\\s{1}Object.plugin\\s{1}.*\\n\\s*(.*)').
fileNamePattern has .js extension hardcoded and in my case it is .ts. If i adjust it as const fileNamePattern = new RegExp('(?:\\/|\\\\)(\\w*(\\.\\w*)*)\\.ts') it works like e charm.

I think that here we have to options:

Adjust regexp to include as many cases as it can, also for .ts development
If m is null just fail in silence.

If needed i can make a patch and a PR.

Ok, working on it

check it here and let me know https://github.com/fastify/fastify-plugin/pull/41

I also have to implement that approach in my hemera framework. I goes with this:
    const calleeFile = getCallerFile()
    if (calleeFile) {
      const basename = path.basename(calleeFile)
      if (basename.toLowerCase().indexOf('plugin') !== -1) {
        fn[DISPLAY_NAME_SYMBOL] = basename
          .replace(/([-_.]*)?plugin([-_]*)?/gi, '')
          .replace(/\.js|\.ts$/i, '')
      }
    }

// https://stackoverflow.com/a/29581862/1893773
function getCallerFile() {
  var originalFunc = Error.prepareStackTrace

  var callerfile
  try {
    var err = new Error()
    var currentfile

    Error.prepareStackTrace = function(_, stack) {
      return stack
    }

    currentfile = err.stack.shift().getFileName()

    while (err.stack.length) {
      callerfile = err.stack.shift().getFileName()

      if (currentfile !== callerfile) break
    }
  } catch (e) {}

  Error.prepareStackTrace = originalFunc

  return callerfile
}

I think this specifically has been solved. If you can improve the code @StarpTech, feel free to send a PR!


updated readme file and new python version example code added

updated readme file and new python version example code added

1 - Readme is degraded by using windows path syntax.
2 - What’s the license for this MP3? Why is the MP3 so big?
3 - Adding this MP3 helps in no way. If you want to test whether playsound works, use the test file that’s already present which has a collection of tiny audio files which have alright licenses with them (I list them in the LICENSE file already.)


Make ignoring of readonly fields an option

As reported in https://github.com/jzaefferer/jquery-validation/pull/1261#issuecomment-59397104, always ignoring readonly fields is not a good idea (and shouldn't have landed in a patch release).
From the comment:

I upgraded to 1.13.1 and this broke my form as a user is now able to submit a form when readonly field is invalid. Is there any way we can make this an option instead? Sometimes the practice on a mobile website is to render a field readonly so that the keyboard isn't shown, the user is then given an alternative method of input, e.g., datepicker.

I think a good solution for this would be to move the [readonly] selector to the ignore option's default value, while leaving the other not selectors as-is. @bootsycollins would that work for you?

@jzaefferer, I also agree #1261 was a bad idea but disagree with adding readonly to the ignore options by default.  It is common practice to use a readonly field as the backing field for an alternative input method, such as a date picker, slider, etc.

Since readonly fields are always passed to the form processor, making them functionally different than a disabled field in the HTML spec, I think they should remain validated by default and that the best scenario is a revert of #1261.

@jamespratt I think you're right, better to revert and document when and how to add [readonly] to the ignore option. Could you put together a PR for the revert and maybe even one for better docs?


npm run build doesn't minify successfully when importing ES6 library

Description
npm run build doesn't minify successfully if I import a library written in ES6 such as punycode.js.
e.g. first
npm install punycode

Then, including import punycode from 'punycode'; to App.js will break minification.
Expected behavior
npm run build should produce minified js
Actual behavior
built js is not minified
I have narrowed down the problematic lines to those that contain let or =>. Commenting out the relevant sections with ES6 code in punycode.js will make minification work again. So I think it's probably because ES6 is not converted to ES5 first when running npm run build, and then somehow webpack cannot do the minification properly. Please correct me if I am wrong.

I have also tried replacing code in punycode.js with that transformed on https://babeljs.io/repl/ will make minification work again.

This is expected. We don't process dependencies with Babel because it would be too slow and sometimes would yield incorrect results.
As the library itself says:

The current version supports recent versions of Node.js only. For the old version that offers the same functionality with broader support, including Rhino, Ringo, Narwhal, and web browsers, see v1.4.1.

Since you want "web browsers", you need to use v1.4.1 of that library.
When we switch to Webpack 2 (might be a few months) we will support ES module syntax in libraries, although you'd still need Babel for any features unsupported by popular browsers.

That's crystal clear and awesome. It solves my problem effectively. Big thanks, Dan!


investigate AYS action executions

Could possibly be going multiple times into same processchange. Need to check

Not a priority for now. Let's focus on new AYS


linkResolver example

Hi
I need some help setting up the linkResolver.
I find the documentation a bit hard to understand and the link to prismic documentation isn't much help either.
Can someone provide an example, including how to use it in a template.

Hi @mathiasha, sure, I'll try to explain how it works.
The link resolver function is used to determine the URL for a particular Prismic document. Since Prismic allows you to construct the shape of your documents (i.e. the fields, names, etc.), Prismic has no notion of how the URL should be determined.
The link resolver function receives the document's data as an object and should return the document's URL as a string.
For example, if I have a blog post with a UID field with the value "my-first-blog-post", my link resolver function might look like this:
// A typical Prismic link resolver function:
const linkResolver = doc => {
  // If the document is a BlogPost custom type:
  if (doc.type === 'blog_post') return `/blog/${doc.uid}`

  // Otherwise:
  return `/${doc.uid}`
}

This would return a URL of /blog/my-first-blog-post for that blog post.
Note that this is a core Prismic feature and not something special to this Gatsby source plugin.
The only different this plugin makes is also providing some Gatsby data to the link resolver. This is done by wrapping the function in another function. Sounds a little strange but the implementation is straightforward.
// The same link resolver function as above, but for gatsby-source-prismic:
const linkResolver = ({ field, value, node}) => doc => {
  // If the document is a BlogPost custom type:
  if (doc.type === 'blog_post') return `/blog/${doc.uid}`

  // Otherwise:
  return `/${doc.uid}`
}

Note the ({ field, value, node}) => addition to the first line. This additional data allows you to customize the link resolver for based on the specific field that needs the URL, the value of that field, and the node containing the field. I personally don't use the field, value, or node data, but it is provided in case you need it.
Hope that helps, but let me know if you have further questions!

Thanks for that.
I still have one more question. How do I use the link?
What do I write in the template to use the link provided by the link resolver?

Actually i think i get it now. I was using providing uid (from this example https://www.gatsbyjs.org/docs/sourcing-from-prismic/) to the links rather url. It makes sense now.

This has confused me as well. Correct me if I'm wrong (@angeloashmore) but gatsby-source-prismic handles all this internally? ie. you don't have to use things like the RichText component from prismic-reactjs or the lower level prismic-dom, but the html content from the graphql layer has already been processed in this way?


Auth is not working

I tried configuring application on AWS Beanstalk.
When trying to log in get 404 error.

I found an error message when I checked the docker container.
<IP_ADDRESS> - - [18/Nov/2023:10:39:23 +0000] "POST /server/auth/login HTTP/1.1" 404 150 "http://mern-dev2.eu-west-1.elasticbeanstalk.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36" "-"

Tried configuring on locally as well using docker-compose.dev.yaml. It is the same error on local as well.


the flows run failed   ---  loomFlowOrchestrationResourceBundle-ConnectToRemoteServerFailureExceptionMsg

On the floweditor ,it's normal/ but on the task failed.

The output step failure message: loomFlowOrchestrationResourceBundle-ConnectToRemoteServerFailureExceptionMsg com.tableausoftware.server.status.reporting.TableauRuntimeException: loomFlowOrchestrationResourceBundle-ConnectToRemoteServerFailureExceptionMsg

I assume that its DataPrep and you installed connector into DataPrep like described here  https://help.tableau.com/current/prep/en-us/prep_connect.htm#custom-connectors
Do you have logs from DataPrep to see exact error?
@jockeyvv

I assume that its DataPrep and you installed connector into DataPrep like described here https://help.tableau.com/current/prep/en-us/prep_connect.htm#custom-connectors
Do you have logs from DataPrep to see exact error? @jockeyvv

I installed the clickhouse_jdbc.taco into Tableau Prep Builder and  Linux Tableau Server like described here ：https://tableau.github.io/connector-plugin-sdk/docs/run-taco#run-your-under-development-connector
Then the local Tableau Prep Builder works normal，but the flow on the Tableau Server prep floweditor previews normal ，but on the backgrounder task failed，I only found the job log like
“”
The output step failure message: loomFlowOrchestrationResourceBundle-ConnectToRemoteServerFailureExceptionMsg com.tableausoftware.server.status.reporting.TableauRuntimeException: loomFlowOrchestrationResourceBundle-ConnectToRemoteServerFailureExceptionMsg
“”

check Tableau Server logs for detailed error.
Need more detailed information about ConnectToRemoteServerFailureExceptionMsg

https://stackoverflow.com/questions/62215385/flow-does-not-run-on-tableau-server-where-can-i-see-the-actual-error
this might be helpful how to get logs


200ms+ latency on HTTP post  (Possible Nagle/TCP_CORK timeout)

Fedora 24, GCC 6.3.1, i7 4790K
Hi Alex,
I noticed that http post consistently responds (when they come in separate chunks) after 200ms, however after setting cork to false problem seems to have disappeared. I've exactly the same application code (apple to apple) running fine on much less powerful windows 7 (virtual machine) without this delay.  I'm using single thread hub on both windows and linux.
// httpSocket->cork(true)
It does seem like it is hitting default 200ms (Nagle/TCP_CORK) timeout. Is there any clean way to solve this problem without making changes to library code via some setting or flag or macro. I will worry about websocket TCP options later, but at the moment I really need to focus on onHttpRequest() and onHttpData().
Thanks a lot.

You could try and insert a httpSocket->cork(false) here before the return: https://github.com/uNetworking/uWebSockets/blob/master/src/HTTPSocket.cpp#L65
Clearly there is a bug since it corks(true) and then in that execution path is doesn't cork(false) before returning (causing those 200ms delays). See if you find any other place where the corking is bad (I know there are other paths in the code doing this, had to fix them for 0.15 since corking is more strict in 0.15)

thanks for confirming - will do more profiling and send a PR.


Retrieve - Download video recordings files from microsd card

Hi, I have several Onvif cameras that uses yoosee and v380/v380s android apps, I want to know if there is some way to download the files from the microsd using python on the LAN.
Since it is possible to do using the android app, It should be possible in some way using a python script.
Thanks.

Were you able to figure this out? I need to implement this as well as only a windows program can access the camera and the micro sd card on the camera is not recognized by any operating systems.

Yes, but the camera is too shitty in other aspects so now I use another one.
Steps:
You should email to<EMAIL_ADDRESS>/<EMAIL_ADDRESS>( developers of V380 / V380s Android Apps) .
With System, firmware and kernel versions, and asking them to sent you necessary files to enable RTSP for using the camera with your NVR.
There is more about upgrades info here: https://community.netcamstudio.com/t/fentac-v380-connection/1334 but DO NOT deal with changing the DEBUG variable, and DO NOT loose your time seeing the SDK. You just could brick your camera or loose your time if you do so. And just in case, DO NOT use upgrade files of other user, unless it has the same kernel, firmware and system versions (in that case it may work)
The patch that they will give to you can be modified, but you should balance the editing so the filesize is the exact same (you could delete some chars from line separators on the file). Later you should get the md5 of the file and replace on other file.
This is what I done to my patch file:

That will enable you to get telnet on the first attempt to upgrade, (if you restart you should put again the upgrade on the SD card in order to get telnet working again, so keep reading)...
Now on the upgrade boot is when you should connect using telnet you should use telnet to edit some scripts, and put there necessary commands to enable telnet always at boot, and enable FTP always at boot., you could ommit to enable ftp at boot enable it each time using a shell/python script when you need to copy the recordings and put it off when you finish... even better, you could have a crontab to restart the camera at 0:00 hs and run your script on your nas/server to connect at that time using telnet, enable ftp, perform the copy of the new recordings, and later disable the ftp and telnet until next reboot of the camera that is even better.
There is no way to have telnet or ftp WITH password, both are password-less, at least I didn't know, but if you have your network protected or separate network you shouldn't have any problems.
The file to be edited has as name and md5 has and .patch extension.
later, get the md5 hash of that file, rename it as that new md5 hash preserving the .patch extension and put that new md5 hash on local_update.conf file
These are the commands to use on telnet:
This script run at boot ( the >> means append to file) so this below lines will be appended to that script. you should un comment the inetd line in order to boot with ftp enabled.
cat<<'EOF' >> /mnt/mtd/nvipcstart.sh

if [ "$debug" == "0" ]
then
        telnetd -l /bin/sh &
        # inetd -fe /mnt/mtd/inetd.conf
fi
EOF

This configures and ftp daemon, this only allows ftp to be able to run, but does not run it by itself:
cat<<'EOF' >> /mnt/mtd/inetd.conf
21 stream tcp nowait root ftpd ftpd /mnt/
EOF

To verify added line:
cat /mnt/mtd/inetd.conf

This executes ftpd, it runs as daemon, background (run this command on telnet to enable it):
inetd -fe /mnt/mtd/inetd.conf

I can help to write a python script to do the telnet connect, and get the files if you need to have it, but it seems that there is almost no others users in need of this thing and I had little time this days so probably It will cost you a beer.

Yeah it would be great if you could help. This is the camera im currently using https://www.aliexpress.com/item/32918038983.html?spm=a2g0s.122695<IP_ADDRESS>53676022HeA9. there is not really any documentation on it but i was able to determine its derived from the Escam QF001 camera.

I did talk to the manufacture and my model camera does not support ftp connections for security reasons so the above wont work for me.

Do it anyway, copy here the system, firmware, kernel versions and will try to get the firmware patch for you...
In the upgrade patch they just will enable RTSP (h264 audio-video stream) handy to use it with Android generic App like Onvifer, VLC on Windows or to record stream to a NVR/XVR ...
In order to have telnet and ftp (to get the records from the microsd card YOU must edit the files to have it... (they do not give support for those features since the telnetd/ftpd of busybox that comes on the firmware does not have login (minimal security) capabilities.

https://www.aliexpress.com/item/32918038983.html?spm=a2g0s.122695<IP_ADDRESS>53676022HeA9.
That camera works with V380 / V380s app ?


kaascevich/Rapid package page not loading

Which package(s) are showing incorrect data?

https://swiftpackageindex.com/kaascevich/Rapid

Please explain what data is incorrect and what you expected to see

I've run a xcrun swift package dump-package and the dump looks fine but haven't done any more investigation yet.

It's back. I bet this is related to the versions issue we've had today. This is a very rare (unprecedented, even!) issue and should not happen again.

I just checked in on this again and it's still not showing up. Our sincere apologies, this is an ongoing problem (still being discussed in #2571).

The default branch version flickering should be addressed by #2594

This has been deployed.


CommonHTML scale-all-math has no effect

HTML-CSS and SVG scale fine but on the CommonHTML it has no effect.
I thought I had run into this and understood the reason when I was recording the a11y screencasts. Will look again later.

It's the MathJax menu item for setting the scale that is at fault, not CommonHTML itself (if you reload the page after setting the scale, you will see the new scale in effect).  The problem is that the menu item has logic for each individual output jax, and wasn't updated to include CommonHTML.

The issue1324 branch of my fork of MathJax includes a fix for this.

=> Merged.


Count the number of Independent Components in a Graph

This Algorithm will check how many unique components are there in a given graph, with the help of DFS / BFS.
@aaryahjolia  Please assign me this for GSSOC 23'

I'm a contributor for GSSoC '23, I want to work on this issue. Please assign me.

I am interested in providing the code as well as the logic for finding independent components in graph. Please assign this to me.


ERROR: tensorflow-2.5.0-cp37-cp37m-linux_aarch64.whl is not a supported wheel on this platform.

We encounter the same problem. It seems you need the latest pip3 and python3 version installed, otherwise, pip3 may come with the message ".whl is not a supported wheel on this platform".
$ pip3 install --upgrade pip


unable to hide mat-select-underline and shows with weird padding

Bug, feature request, or proposal:
I have been unable to hide mat-select-underline and it shows up with some padding that throws off my alignment. I used the below:

                    {{ingredient}}

            </div>

CSS:
mat-select.mat-select-underline{
display:none;
}

What is the expected behavior?
What is the current behavior?
What are the steps to reproduce?
Providing a StackBlitz reproduction is the best way to share your issue.
StackBlitz starter: https://goo.gl/wwnhMV
What is the use-case or motivation for changing an existing behavior?
Which versions of Angular, Material, OS, TypeScript, browsers are affected?
Using Angular 5 with Chrome
Is there anything else we should know?

This isn't really something that we support. Our components are set up according to the Material design spec and any style changes that you do on top are at your own risk.

I did the CSS to hide the underline, but it didnt work and my underline by default shows up with weird padding.

You might be missing a space before the underline selector:
mat-select .mat-select-underline{
    display:none;
}

Anyway, that padding problem might indicate some other CSS problem. Try to comment out all custom CSS to see if the invalid padding remains.

Thanks @mucbits , the underline display worked. Still can't get rid of the padding, even after removing all the CSS.

I added the below to look at the actual size of the container and saw that the size is larger than other input containers:
::ng-deep .mat-input-flex.mat-form-field-flex{
border: 1px solid black;
}


Doesn't sync right after setup. What could be wrong?

I am using a self-host version of database to sync between 2 windows devices, all of which are of the up-to-date version and on live sync mode.
Files did be uploaded when the first device is set up. (I turn off the encryption so I can see what is in the database). And that's all what happened. New files are not uploaded, new changes are not uploaded and no files are retrieved from the database when the second device was added. (Can also be determined by checking the database)
I used tool and found out that there are internet requests sent to the database server from both devices and "test database" results turned out to be ok on both devices.
What could be wrong?

Sorry for being late and thank you for opening the issue!
There are some possibilities, however, are Suspend file watching or Suspend database reflecting disabled?
These toggles are in the Hatch pane on the setting dialogue.
If it has been surely disabled, please share the report which can be generated by the Make report button to let me reproduce your environment.


Conversions of timeseries mass units, resampling and temporal homogenization

Added some functionality to convert timeseries objects:

to different units (Gt and mwe), also including things such as change in area for example which is defined in the constants for each region.
to return an annual timeseries from higher and lower resolution timeseries
to return a longterm trend timeseries from higher resolution timeseries
a seasonally homogenized timeseries using a higher resolution calibration dataset

Now a Timeseries object can newly return a copy of itself with the converted changes. This is the design envisaged for any changes during the algorithm to each of the datasets. The idea behind that is that during the algorithm the actual data within a Timeseries object will not be edited, but we can return an edited new object. In this way we can compare/use the initial data at any point within the algorithm. Does this make sense?
Note that uncertainties are note implemented yet for this conversion, as the equation for it is not defined yet.

Thanks for the review!
I addressed most of it (marked as resolved for the minor type changes and left the rest open)
I also had a couple of questions (see my comments)

Thanks Tristan for clarifying my questions!
I think I addressed all your points now, but best to have another quick look over it from your side if you're happy with the changes. Good inputs, as always.


Testing use of global env

Added global env for subscription and tenant id and testing use of variable groups

good to go


Errors recompiling Keras on Julia 1.3.1

I see that the package is a bit stale and has not been upgraded to work on Julia 1, however I was able to install it seamlessly in Julia 1.3.1 by executing Pkg.add(Pkg.PackageSpec(url="https://github.com/ayush1999/Keras.jl", rev="master")). Executing using Keras returned errors I wasn't able to fix. The full output is below. Any suggestion is greatly appreciated.
[ Info: Precompiling Keras [031d7243-eb6a-5793-a290-e3c72503329c]
WARNING: importing deprecated binding Compat.Libdl into Blosc.
WARNING: importing deprecated binding Compat.Libdl into Blosc.
WARNING: Method definition iterate(DataFlow.ObjectArraySet{T} where T, Any...) in module DataFlow at /home/adude/.julia/packages/Lazy/mAoZN/src/macros.jl:285 overwritten at /home/adude/.julia/packages/Lazy/mAoZN/src/macros.jl:285.
  ** incremental compilation may be fatally broken for this module **

ERROR: LoadError: LoadError: LoadError: syntax: "..." expression outside call
Stacktrace:
 [1] top-level scope at /home/adude/.julia/packages/Keras/IoYuA/src/ops.jl:13
 [2] include at ./boot.jl:328 [inlined]
 [3] include_relative(::Module, ::String) at ./loading.jl:1105
 [4] include at ./Base.jl:31 [inlined]
 [5] include(::String) at /home/adude/.julia/packages/Keras/IoYuA/src/Keras.jl:1
 [6] top-level scope at /home/adude/.julia/packages/Keras/IoYuA/src/graph.jl:2
 [7] include at ./boot.jl:328 [inlined]
 [8] include_relative(::Module, ::String) at ./loading.jl:1105
 [9] include at ./Base.jl:31 [inlined]
 [10] include(::String) at /home/adude/.julia/packages/Keras/IoYuA/src/Keras.jl:1
 [11] top-level scope at /home/adude/.julia/packages/Keras/IoYuA/src/Keras.jl:4
 [12] include at ./boot.jl:328 [inlined]
 [13] include_relative(::Module, ::String) at ./loading.jl:1105
 [14] include(::Module, ::String) at ./Base.jl:31
 [15] top-level scope at none:2
 [16] eval at ./boot.jl:330 [inlined]
 [17] eval(::Expr) at ./client.jl:425
 [18] top-level scope at ./none:3
in expression starting at /home/adude/.julia/packages/Keras/IoYuA/src/ops.jl:13
in expression starting at /home/adude/.julia/packages/Keras/IoYuA/src/graph.jl:2
in expression starting at /home/adude/.julia/packages/Keras/IoYuA/src/Keras.jl:4
ERROR: Failed to precompile Keras [031d7243-eb6a-5793-a290-e3c72503329c] to /home/adude/.julia/compiled/v1.3/Keras/RBgJ9_OVTEM.ji.
Stacktrace:
 [1] error(::String) at ./error.jl:33
 [2] compilecache(::Base.PkgId, ::String) at ./loading.jl:1283
 [3] _require(::Base.PkgId) at ./loading.jl:1024
 [4] require(::Base.PkgId) at ./loading.jl:922
 [5] require(::Module, ::Symbol) at ./loading.jl:917

can confirm with julia 1.5.3.
I tried:
Pkg.add(url="https://github.com/ayush1999/Keras.jl")
resulting in:

ERROR: could not find project file in package at https://github.com/ayush1999/Keras.jl maybe subdir needs to be specified

or with:
Pkg.add("Keras")
it was not found:

ERROR: The following package names could not be resolved:

Keras (not found in project, manifest or registry)

I think it is definetly useful, I'd used it on ProtoSyn.jl if it worked on Julia 1.7. How hard do you think it would be?

I think apart from adding the usual manifest files (which should be the simpler bit), we'd also need to check if the Flux & Keras APIs have changed. This might be the more involved part.

Agreed. Some julia changes might have alse broke this code.

FYI if code changes here are significant and you want something to work as soon as possible, there are other things you can try:

ONNX.jl (currently under development and you might have to add a few new ops)
https://github.com/invenia/Keras.jl : This is a Julia wrapper around Keras python API. Not sure if it is relevant for your work.

I was exploring the ONNX.jl, actually adding ops as you said (ahah). Run into some problems: https://github.com/FluxML/ONNX.jl/issues/61#issuecomment-1040501987
Perhaps you may help as well. I'm kind of a noob when it comes to these things. I also took a look at Keras.jl, but I may just end up going with the default way of using PyCall to run TensorFlow.


Travel required as a warning/notice

While some people wouldn't mind traveling for the job, it definitely affects the quality of life, work-life balance etc. I think we should have a warning, or at least a notice on the subject. Not sure if we should measure the percentage of travel as a measure (also, not sure how to do it easily).

Kinda new here, but this seems a bit awkward as a thing to flag. Some jobs actually require travel. By flagging it, is it possible that someone would think to take it out, leading to incorrect expectations later on?
Also, some people specifically look for jobs that include travel.
For example, if your job is to perform on-site security evaluations, or perform on-site repairs, or meet face-to-face with customers, shouldn't that be spelled out in the job description?

Ah ... looking through more of the issues I see now that some people are using this more to filter jobs they are evaluating, rather than for employers wanting to ensure their descriptions aren't unintentionally "bad".


Scrolling problem with right sidebar in Linux

Have you read the Contributing Guidelines on issues?

[X] I have read the Contributing Guidelines on issues.

Prerequisites

[X] I'm using the latest version of Docusaurus.
[X] I have tried the npm run clear or yarn clear command.
[X] I have tried rm -rf node_modules yarn.lock package-lock.json and re-installing packages.
[ ] I have tried creating a repro with https://new.docusaurus.io.
[X] I have read the console error message carefully (if applicable).

Description
When using the right sidebar navigation, there is a scrolling issue. It is detailed here:
https://github.com/djipco/webmidi/issues/236
As stated in the above issue, both website using v2.0.0-beta.15 have this issue while older ones do not. It might be a coincidence but it might also be a hint...
Steps to reproduce
Create a page docs page with right-side navigation. Try to scroll.
Expected behavior
Should scroll normally.
Actual behavior
Does not fully scroll the page.
Your environment
No response
Reproducible demo
No response
Self-service

[ ] I'd be willing to fix this bug myself.

Please see if #6587 is a duplicate of this issue. i.e. if the original post had "Experimental web platform features" turned on.


Docs have a lot of empty links

Steps to reproduce
Go to https://github.com/neondatabase/neon/blob/main/docs/SUMMARY.md and f.e. click on "Proxy"
Expected result
Proxy docs
Actual result
No docs. Or remove the link alltogether

That page is a bit of a graveyard indeed.  Please visit https://neon.tech/docs/introduction for info about the product.
https://github.com/neondatabase/neon/pull/8665

You may also find the #neon-oss discord  channel useful.


Bump bom-2.319.x from 1508.v4b_d09ff0e893 to 1539.v6a_85813638f8

Removing the pinned ssh-credentials 😅

@jetersen will you need a release for this one ?

no @Dohbedoh no immediate reason to release this.
This can just be labeled dependencies and released at your convivence of other PRs.


[MINOR] Terminal color is not reset to default after printing AST

When passing --print-ast to the compiler, it prints the AST, in color. This is great, however it does not reset the color back to default, which means the subsequent prompt is of a random color (usually all blue because of types). To fix this, we literally just have to print \033m at the end of wherever we print the AST in color.

\003[m :eyes:

But yeah that would do it. My shell prompt does reset the colour, so I don’t notice things like that...


Pass custom endpoint to GitHubSecurityAdvisoryClient when set

Custom endpoints set via GitHubSecurityAdvisoryClientBuilder#withEndpoint when building the GitHub client did not take effect, as they were not passed to the client instance when calling build() on the builder.

Thanks! But don't sweat it. I'll shadow this class for the time being, I mostly need the custom endpoint for testing.


Unable to install setuptools from GitHub master

It would be nice if pip were able to install setuptools from GitHub master. Instead, if one attempts to pip install, an error about the bootstrap script is emitted:
~ $ pip install git+https://github.com/pypa/setuptools
Collecting git+https://github.com/pypa/setuptools
  Cloning https://github.com/pypa/setuptools to /private/var/folders/c6/v7hnmq453xb6p2dbz1gqc6rr0000gn/T/pip-req-build-j6hkzir0
  Installing build dependencies ... done
  Missing build requirements in pyproject.toml for git+https://github.com/pypa/setuptools.
  The project does not specify a build backend, and pip cannot fall back to setuptools without 'setuptools>=38.2.5'.
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/private/var/folders/c6/v7hnmq453xb6p2dbz1gqc6rr0000gn/T/pip-req-build-j6hkzir0/setup.py", line 193, in <module>
        require_metadata()
      File "/private/var/folders/c6/v7hnmq453xb6p2dbz1gqc6rr0000gn/T/pip-req-build-j6hkzir0/setup.py", line 24, in require_metadata
        raise RuntimeError(msg)
    RuntimeError: Cannot build setuptools without metadata. Run `bootstrap.py`.

    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in /private/var/folders/c6/v7hnmq453xb6p2dbz1gqc6rr0000gn/T/pip-req-build-j6hkzir0/

I'm wondering if there's a solution to this limitation. I can imagine a few:

setuptools could wait for and rely on PEP 517 support and provide its own "installer" (itself) that does the bootstrapping.
pip could special-case the installation of anything that looks like setuptools and run bootstrap.py before installing.
setuptools could materialize the metadata (egg-info) to the repo, avoiding the need to bootstrap (but requiring special handling of that metadata which is derived from other files in the repo).
setuptools could inject a hack to bootstrap and relaunch (this hack might interfere or interact badly with pip's injection of setuptools).

There are probably others. Only the first option seems (somewhat) clean.

Is there a way to install this ?

This is causing me issues. On Ubuntu 20.04, I'm trying to install from a local mirror via
python3 -m pip install --no-index --user<EMAIL_ADDRESS>--no-build-isolation
I think having require_metadata() run bootstrap.py and relaunch makes the most sense, as setuptools is probably the only thing that needs this and it keeps the extra tooling where it is needed. Perhaps it would be less hacky to use importlib to reload setup.py, maybe.

I've tried relying on PEP-517 which has landed, but ran into issues. See also #2001 where I expended some energy on this effort.

According to bootstrap.py, it's only usefull if setuptools is not installed yet, so I though we could call require_metadata only if setuptools is not installed yet, but looks like there's already an import setuptools before the require_metadata() call, so I don't see what bootstrap.py fixes.
Can someone shed a light on what I missed? (I know nothing about egg_info, I may miss something big).

According to bootstrap.py, it's only usefull if setuptools is not installed yet, so I though we could call require_metadata only if setuptools is not installed yet, but looks like there's already an import setuptools before the require_metadata() call, so I don't see what bootstrap.py fixes.
Can someone shed a light on what I missed? (I know nothing about egg_info, I may miss something big).

The underlying problem is this:

Setuptools repo doesn't have metadata (most repos don't).
Setuptools relies on itself (including its metadata) to generate metadata (egg_info command) for a project.
Attempting to run egg_info on setuptools has no effect until metadata is present.

The bootstrap.py function works around this issue by generating some minimal metadata outside of Setuptools, enough that Setuptools can then generate its own metadata.
The require_metadata function in setup.py is a stopgap to provide a clear indication when metadata isn't present and to direct the user to run bootstrap.py to create the minimal metadata before attempting to run setup.py again.
Does that clarify?

The underlying problem is this:

Setuptools repo doesn't have metadata (most repos don't).
Setuptools relies on itself (including its metadata) to generate metadata (egg_info command) for a project.
Attempting to run egg_info on setuptools has no effect until metadata is present.

The bootstrap.py function works around this issue by generating some minimal metadata outside of Setuptools, enough that Setuptools can then generate its own metadata.
The require_metadata function in setup.py is a stopgap to provide a clear indication when metadata isn't present and to direct the user to run bootstrap.py to create the minimal metadata before attempting to run setup.py again.
Does that clarify?

Does that clarify?

A bit, thanks. But I won't spend too much time on it as it looks like it's no longer usefull thanks to pip / PEP 517.

Does that clarify?

A bit, thanks. But I won't spend too much time on it as it looks like it's no longer usefull thanks to pip / PEP 517.


add custom physics parameter

I needed this parameter to disable vertical scrolling of the grid. Horizontal scroll still works fine.

Approved! Thanks for the PR. I will publish this to 1.2.3.


[@shopify/react-network, quilt_rails] Allow client-side access of request headers

Description
Fixes #1472
The hook useRequestHeader in @shopify/react-network only has value on server-side renders, since it relies on a context object available only on the server.
This PR introduces a universal provider component NetworkUniversalProvider to @shopify/react-network. Consuming apps (that render NetworkContext.Provider) wishing to access request headers on both client and server-side renders via useRequestHeader can wrap their top-level app in a NetworkUniversalProvider, passing in a headers prop describing the headers they wish to provide to the rest of the app through context. Then, in components further down in the tree they may call useRequestHeader to easily get those headers on both server and client-side renders.
This PR should not break any existing NetworkContext.Provider/useRequestHeader functionality. Consumers who render a NetworkUniversalProvider without a NetworkContext.Provider will receive an error, but consumers who use useRequestHeader with a NetworkContext.Provider but no NetworkUniversalProvider will continue to receive undefined for their client-side hook calls.
This PR also makes a change in quilt_rails. Previously, we were passing down the custom Quilt headers under the data header. This data gets serialized for the client to use. Since we're now providing an easier way of accessing all headers for client-side renders, it's unnecessary to merge in these custom headers with explicitly denoted data. If consumers of this gem were relying on the serialized data to access custom headers client-side (e.g. via getSerialized) or app props with the webpack plugin, this PR will break their use case.
Tophat
Tophatted using the following steps:

dev clone signage, if you don't already have it
git fetch --all && git checkout hup-testing (this branch is essentially the state of Signage prior to this revert with some minor changes, namely some console logs, wrapping the markup in App.tsx in NetworkUniversalProvider tags, and changing the default fallback locale to fr. If you like, you can git reset<PHONE_NUMBER>0aea305898b86d883434f03a4a0d63 to undo that commit and look at the changes yourself)
dev cd quilt && git fetch --all && git checkout 1472-header-client
yarn tophat packages/react-network ../signage
In signage, dev up && dev server, Ctrl-T to open the app in the browser
Make sure that it's not in French (i.e. we're actually getting and using the X-Brochure-Locale header client-side)
If you'd like to test it further, add some more request headers to the headers prop in NetworkUniversalProvider in App.tsx, then use useRequestHeader to access those headers elsewhere in the app. You should be able to get those headers in any component in the app on both server and client-side renders

Screenshots
These are some of the metrics I picked up while investigating both approaches to this problem. Both involve a single useRequestHeader call and use console.time API.

NetworkUniversalProvider
Manual Deserialize + Memoize

Initial server-side render

Initial client-side render

Type of change

[x] @shopify/react-network Minor: New feature (non-breaking change which adds functionality)
[x] quilt_rails Major: Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

[x] I have added a changelog entry, prefixed by the type of change noted above (Documentation fix and Test update does not need a changelog as we do not publish new version)

@TheMallen and I discussed this a bit more offline during our 1-on-1. Basically, the two possible approaches to this are:

Manually deserializing (and memoizing) the requested headers in the useRequestHeader hook (basically this PR at the time of writing with some polish)
Providing some sort of universal provider component (i.e. HeaderUniversalProvider) that manages that serialization for us and provides header-related context to the rest of the app, which useRequestHeader would read from

Option 2 is cleaner and probably more performant in the long run (having a single deserialization client-side as opposed to one for every single useRequestHeader instance). The downside is that the consumer would have to wrap their app in another provider which adds more complexity relatively speaking.

Looks great, but could we also add NetworkUniversalProvider to the code generated by react-server-webpack-plugin?

Just relating some things discussed offline: since this provider relies on its headers prop to determine which headers to serialize, it's probably best to leave it out of the plugin for now. It'd be weird to define which headers to serialize in a plugin config. ATM the expected use case is that the consumer is responsible for wrapping their own app in the provider.


Add some more entity types

Service

I'm not sure if this is even in NetSuite. I'm going off @fractalcat 's comments here: https://anchorsystems.teamwork.com/tasks/2994666 and here: https://github.com/anchor/engineering/issues/35.

I'll take a look at those and work out if they have any relationship to the standard NetSuite entity model.


chore(storybook): bump to v8 release candidate

This change: (check at least one)

[ ] Adds a new feature
[ ] Fixes a bug
[ ] Improves maintainability
[ ] Improves documentation
[ ] Is a release activity

Is this a breaking change? (check one)

[ ] Yes
[ ] No

Is the: (complete all)

[ ] Title of this pull request clear, concise, and indicative of the issue number it addresses, if any?
[ ] Test suite(s) passing?
[ ] Code coverage maximal?
[ ] Changeset added?
[ ] Component status page up to date?

What does this change address?
Resolves #710
How does this change work?
A clear, detailed description of how this change addresses the issue.
This could be a bullet list if there are several moving parts.
Additional context
Add any other context here.

This has been largely subsumed by #716 and will need to be reworked.


Add source metadata to log entries

Solves #1579

This would require each adapter to extract this data themselves. Would it be possible to do that at some other level?
What if instead of constructing the Ecto.LogEntry directly in the adapter we provide a function accepting the query itself and a list of fields, something like:
defmodule Ecto.LogEntry do
  # ...

  def new(query, fields) do
    struct(%Ecto.LogEntry{source: get_source(query)}, fields})
  end
end

This would also allow us to easily extend the log entry with some metadata in the future, should we need this.

This would require each adapter to extract this data themselves. Would it be possible to do that at some other level?

I don't think there is anything wrong with that. Specially because the source does not always come from Ecto.Query.

Ready, with only "from" source

@josevalim that's a fair point. So maybe instead of query, we should be passing the meta part we pass into every adapter call?

@josevalim ping :purple_heart:

Looks good to me! I will merge it later when focusing on Ecto again. :D

Okay, thnx! Just now I know that this is okay and I can do something else.
Quick feedback on this, from my project running this branch: this is even more helpfult that I was imagine in the beginning :heart:

Mergeed manually!


Unable to build the project

I am new to Java and am facing some issues when creating a build for this project. I tried to git clone
Next, I ran "./mvnw package" and am getting this issue. Can someone suggest how to fix this.
test123:~/environment/spring-petclinic (main) $ java -version
openjdk version "11.0.19" 2023-04-18 LTS
OpenJDK Runtime Environment (Red_Hat-<IP_ADDRESS>.7-1.amzn2.0.1) (build 11.0.19+7-LTS)
OpenJDK 64-Bit Server VM (Red_Hat-<IP_ADDRESS>.7-1.amzn2.0.1) (build 11.0.19+7-LTS, mixed mode, sharing)
test123:~/environment/spring-petclinic (main) $
test123:~/environment/spring-petclinic (main) $ mvn -version
Apache Maven 3.9.2 (c9616018c7a021c1c39be70fb2843d6f5f9b8a1c)
Maven home: /home/ec2-user/environment/maven/apache-maven-3.9.2
Java version: 1.8.0_372, vendor: Red Hat, Inc., runtime: /usr/lib/jvm/java-1.8.0-openjdk-<IP_ADDRESS>2.b07-1.amzn2.0.1.x86_64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.14.314-238.539.amzn2.x86_64", arch: "amd64", family: "unix"

I am getting these error when running the command.

./mvnw package

test123:~/environment/spring-petclinic (main) $ ./mvnw package
[INFO] Scanning for projects...
[INFO]
[INFO] ------------< org.springframework.samples:spring-petclinic >------------
[INFO] Building petclinic 3.1.0-SNAPSHOT
[INFO]   from pom.xml
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- spring-javaformat:0.0.39:validate (default) @ spring-petclinic ---
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  1.905 s
[INFO] Finished at: 2023-06-12T19:47:27Z
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal io.spring.javaformat:spring-javaformat-maven-plugin:0.0.39:validate (default) on project spring-petclinic: Execution default of goal io.spring.javaformat:spring-javaformat-maven-plugin:0.0.39:validate failed: An API incompatibility was encountered while executing io.spring.javaformat:spring-javaformat-maven-plugin:0.0.39:validate: java.lang.UnsupportedClassVersionError: io/spring/javaformat/eclipse/jdt/jdk11/internal/formatter/DefaultCodeFormatter has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
[ERROR] -----------------------------------------------------
[ERROR] realm =    plugin>io.spring.javaformat:spring-javaformat-maven-plugin:0.0.39
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] = file:/home/ec2-user/.m2/repository/io/spring/javaformat/spring-javaformat-maven-plugin/0.0.39/spring-javaformat-maven-plugin-0.0.39.jar
[ERROR] urls[1] = file:/home/ec2-user/.m2/repository/io/spring/javaformat/spring-javaformat-formatter/0.0.39/spring-javaformat-formatter-0.0.39.jar
[ERROR] urls[2] = file:/home/ec2-user/.m2/repository/io/spring/javaformat/spring-javaformat-config/0.0.39/spring-javaformat-config-0.0.39.jar
[ERROR] urls[3] = file:/home/ec2-user/.m2/repository/io/spring/javaformat/spring-javaformat-formatter-eclipse-jdt-jdk8/0.0.39/spring-javaformat-formatter-eclipse-jdt-jdk8-0.0.39.jar
[ERROR] urls[4] = file:/home/ec2-user/.m2/repository/io/spring/javaformat/spring-javaformat-formatter-eclipse-jdt-jdk11/0.0.39/spring-javaformat-formatter-eclipse-jdt-jdk11-0.0.39.jar
[ERROR] urls[5] = file:/home/ec2-user/.m2/repository/io/spring/javaformat/spring-javaformat-formatter-eclipse-runtime/0.0.39/spring-javaformat-formatter-eclipse-runtime-0.0.39.jar
[ERROR] urls[6] = file:/home/ec2-user/.m2/repository/org/codehaus/plexus/plexus-utils/3.0.24/plexus-utils-3.0.24.jar
[ERROR] urls[7] = file:/home/ec2-user/.m2/repository/org/apache/commons/commons-lang3/3.5/commons-lang3-3.5.jar
[ERROR] urls[8] = file:/home/ec2-user/.m2/repository/javax/enterprise/cdi-api/1.0/cdi-api-1.0.jar
[ERROR] urls[9] = file:/home/ec2-user/.m2/repository/javax/annotation/jsr250-api/1.0/jsr250-api-1.0.jar
[ERROR] urls[10] = file:/home/ec2-user/.m2/repository/org/eclipse/sisu/org.eclipse.sisu.inject/0.3.3/org.eclipse.sisu.inject-0.3.3.jar
[ERROR] urls[11] = file:/home/ec2-user/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
[ERROR] Number of foreign imports: 1
[ERROR] import: Entry[import  from realm ClassRealm[project>org.springframework.samples:spring-petclinic:3.1.0-SNAPSHOT, parent: ClassRealm[maven.api, parent: null]]]
[ERROR]
[ERROR] -----------------------------------------------------
[ERROR]
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginContainerException

What am I missing here? Can someone help please?

Try using Java 17 or newer

You also have Maven finding Java 8 in preference to the Java 11 you think you might be using. With Java 11, ironically, the failure would tell you explicitly that you need to use Java 17 instead.


Default locale not working

Hi ! 😃
I'm having an issue with default language on payment page, that page :

Here is some context : I use Shopware PWA with Shopware v<IP_ADDRESS> + Mollie payment module in last version and everything is working smooth so far.
I tried to change the default locale by editing sale channel locale and every URL connected without success, i tried modify Shopware PWA code to tweak the config of order/payment without success, i tried to replace MOLLIE_DEFAULT_LOCALE_CODE and that line  without much success..
Do you have any idea what's happening ? Would it be possible to add a full override on mollie account or module config page ?
Thanks for maintaining the module it is awesome 💯

Hi @IndeedEvan
first of all, thank you so much for your kind words :)
we're putting really so much effort in this plugin
i'm currently finishing the official support of headless and pwa
i didnt check the locale so far, but i'll pay attention..maybe its already fixed because the latest release doesnt yet fully support headles (officially)

@IndeedEvan I've changed in sale channel Language and chose "Localisation according to ISO standard" and it helps me change Mollie checkout language from EN to De


chore: replace @types/is-stream with correct @types/isstream

This changes the installed @types file to use the right typing package for the isstream module that is depended upon concretely.
Checklist

[x] npm test passes (tip: npm run lint-fix can correct most style issues)

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

It seems like file-type is also missing from the types array in the tsconfig.json, though I've never used it so I'm not sure if that was on purpose or not.

I didn't do that on purpose, so if you think it would be useful feel free to add it

Would it also make sense to just remove the key and let tsc automatically find the necessary types it needs automatically from the node_modules/@types/ directory?

If TypeScript does that, yeah that sounds good to me

Sounds good, I've commented out that bit of code.


Possible problem with migration diff with enums involved.

Describe the bug
I think I see a bug with schema diffing (or migration) for my app using a Postgresql db:
I created an initial migration (using migrator.createInitialMigration()) from an existing schema (one that was updated through orm.getSchemaGenerator().updateSchema().

The migration file was created fine but it was not logged to the migrations table because schemaExists  returned false.
To narrow down further I dropped all tables and created them by executing migrate up using the initial migration file. This worked fine.
I then created a new migration. And this added some lines to the new migration file that it thinks are different between the current schema and the entities. I also ran this file. The next migration created would contain the same lines.
The fields in that seem to get processed over and over are relatedType and mailType from queued-mail.entity.ts.

I attach the following files:

the initial migration,
the subsequent migration
the entity and enum definitions in question.
the ddl for this table as exported from my database. The table was created with the initial migration.

Let me know if I can debug anything to help sort this out! Thanks!
migration-issue.zip
To Reproduce
Steps to reproduce the behavior:
I'm sorry I don't have a reproduction repo yet. Please let me know if you need one.
Expected behavior

Initial migration should have been created and logged
Subsequent migration should not contain any model changes.

Additional context
Add any other context about the problem here.
Versions

Dependency
Version

node
12.18.3

typescript
4.0.2

mikro-orm
4.3.2

your-driver
postgres, using pg from mikro-orm

I think I found one problem:
I changed the entity definition for the 2 enums from
  @Enum({ type: "MailType", items: () => MailType, default: MailType.Unknown })
  mailType: MailType // FIXME: set default value how?

  @Enum({
    type: "RelatedType",
    items: () => RelatedType,
    default: RelatedType.None,
    nullable: true,
  })
  relatedType?: RelatedType

to
  @Enum({ default: MailType.Unknown })
  mailType: MailType

  @Enum({ default: RelatedType.None, nullable: true })
  relatedType?: RelatedType

It seems that defining type and items for an int enum is not allowed?
Changing the enum definition does create them the same way they were (int2), but does not cause the newly created migration to contain schema changes over and over. A newly created migration is empty as it should be.
However, the initial migration created from the existing schema was still not logged to the migrations table. I'll try to figure out what causes this.

I think I found why the initial migration doesn't get logged.
I added some comments to Migrator.validateInitialMigration and it seems the comparison between existing and expected is wrong.
I'm logging all the table names that are found in the database versus all those found in the schema. They can't match.
Here's the code with logging:
schema.getTables().forEach(table => {
            /* istanbul ignore next */
            const tableName = table.schema ? `${table.schema}.${table.name}` : table.name;
            console.log("found table ", tableName, expected.has(tableName));
            if (expected.has(tableName)) {
                exists.add(tableName);
            }
        });

Here's the names found in the DB (second are is expected.has(tableName)):
found table  public.attachment false
found table  public.attendee_event false
found table  public.email_preferences false
found table  public.event false
found table  public.event_documents false
found table  public.queued_mail false
found table  public.sent_mail false
found table  public.user false

Here's the set of expected entries:
Set {
  'attachment',
  'attendee_event',
  'email_preferences',
  'event',
  'queued_mail',
  'sent_mail',
  'user',
  'event_documents'
}

The set of existing entries is empty.

Fixed in 4.3.3-dev.12