Not able to type in index.html file

Type: Bug
I have created a json package to develop my full stack project and have created a public folder and inside this folder i have my index.html file. When i open index.html file and try to write code but I'm not able to type anything.
Please help me to resolve
VS Code version: Code 1.80.1 (Universal) (74f6148eb9ea00507ec113ec51c489d6ffb4b771, 2023-07-12T17:20:23.298Z)
OS version: Darwin arm64 22.6.0
Modes:

System Info

Item
Value

CPUs
Apple M2 (8 x 24)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: enabled

Load (avg)
1, 2, 2

Memory (System)
8.00GB (0.33GB free)

Process Argv
--crash-reporter-id 09957996-e5b8-48ca-b22f-af54bcc6dcde

Screen Reader
no

VM
0%

Extensions (30)

Extension
Author (truncated)
Version

html-snippets
abu
0.2.1

bracket-pair-color-dlw
Bra
0.0.6

vscode-tailwindcss
bra
0.9.11

vscode-eslint
dba
2.4.2

es7-react-js-snippets
dsz
4.4.3

gitlens
eam
14.1.1

vscode-html-css
ecm
1.13.1

prettier-vscode
esb
9.19.0

auto-rename-tag
for
0.1.10

code-runner
for
0.12.0

cloudcode
goo
1.22.0

vscode-colorize
kam
0.11.1

node-module-intellisense
lei
1.5.0

twig-language
mbl
0.9.2

vscode-scss
mrm
0.10.0

vscode-docker
ms-
1.26.0

vscode-kubernetes-tools
ms-
1.3.13

python
ms-
2023.12.0

vscode-pylance
ms-
2023.7.40

remote-containers
ms-
0.299.0

cpptools
ms-
1.16.3

material-icon-theme
PKi
4.29.0

vscode-yaml
red
1.14.0

LiveServer
rit
5.7.9

code-spell-checker
str
2.20.5

html-preview-vscode
tht
0.2.5

vscode-icons
vsc
12.4.0

vim
vsc
1.25.2

gitblame
wad
10.4.0

html-css-class-completion
Zig
1.20.0

(1 theme extensions excluded)

A/B Experiments
vsliv368:30146709
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
vserr242:30382549
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscod805:30301674
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593cf:30376535
pythonvs932:30410667
py29gd2263:30792226
vsclangdc:30486549
c4g48928:30535728
dsvsc012cf:30540253
pynewext54:30695312
azure-dev_surveyone:30548225
282f8724:30602487
89544117:30613380
showlangstatbar:30737416
vsctsb:30748421
03d35959:30757346
pythonfmttext:30731395
pythoncmv:30756943
fixshowwlkth:30771522
hideindicator:30785051
pythongtdpath:30769146
i26e3531:30792625
gsofb:30797622
pythonnosmt12:30797651
pythonnoceb:30797650
e537b577:30795824
h0f32768:30792100
dsvsc013:30795093
dsvsc014:30797589
cmakesidepanelv2:30779593

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.80.2. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

Up to date yet not working

/confirmPlease

Please perform the following three tasks to diagnose the root cause of the issue:

[ ] 1.) Disable Extensions

Select View and pick Command Palette...
Run Developer: Reload With Extensions Disabled
👉 See if the issue reproduces

[ ] 2.) Disable Configuration

Select View and pick Command Palette...
Run Profiles: Create a Temporary Profile
👉 See if the issue reproduces

[ ] 3.) Try VS Code Insiders

Download VS Code Insiders
Install and Run it
👉 See if the issue reproduces

Then pick one of the three resolutions depending on which step has helped:

Disabling my Extensions helped
Please run the command Start Extension Bisect and follow the instructions to find the extension that is causing this issue.

Please report the issue to the extension causing this.

Disabling my configuration helped
Please report back more details about your configuration, including settings.

Using VS Code Insiders has helped
✅ This likely means that the issue has been addressed already and will be available in an upcoming release. You can safely use VS Code Insiders until the new stable version is available.

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


How a Kong Basic Auth Plugin can be restricted to set of consumers?

Discussed in https://github.com/Kong/kong/discussions/13367

Originally posted by sasahoo-tibco July 12, 2024
I have set up the basic auth Kong Plugin and created a Consumer using a Kubernetes secret. This configuration works for all consumers using that secret. I have an ingress that uses this plugin. However, I want the Kong Plugin to work only with a specific set of consumers, not all. Specifically, I would like to know if the Kong Plugin can be configured to work with a single consumer.
For example:
Ingress 'A' uses Kong Basic Auth Plugin 'Ka' and should work only with Consumer 'A'.
Ingress 'B' uses Kong Basic Auth Plugin 'Kb' and should work only with Consumer 'B'.
Ingress 'A' should not authenticate Consumer 'B', and Ingress 'B' should not authenticate Consumer 'A'.
Is there a solution for this scenario?

Have a look here: https://discuss.konghq.com/t/limit-routes-to-specific-consumers/9774
Does this answer your question?


Mithril redesign

A fork of issue Reasons we use Mithril #1026
Here we can propose our approaches to Mithril's logo, slogan/tagline, or site design (freeware only)
Reason: Mithril's community is lacking.  A redesign in parallel to a rewrite can promote growth to the mithril community with a well-defined branding.

My approach is to show Mithril as a rock-solid foundation to any project, with either a minimalist feel (D3 Stonism) or a louder, explicit feel (Rock it).  I feel like a better tagline would to keep the 'bounce rate' lower.
Rock it

Tagline: 'The JavaScript framework for scalable solutions'
D3 Stonism

Tagline: 'Your bedrock for JavaScript'

The origin of the name has nothing in common with the project itself. Forcing the project into this mold will lead to off the mark USPs and tacky taglines. It will also add to the confusion when sifting through the thousands legitimate Hobbit/LOTR sites.
A branding exercise does not start with the name, but with the unique benefits this library brings.

You can argue the same for React with 'React youtube'.  You propose a common risk-factor evaluation, but the end-goal is not to make mithriljs famous.  The end-goal is to strengthen the mithriljs community, and a little jazz can do wonders.
I'll agree though I don't like the hobbit/lotr theme, and I don't think we should be focusing on the theme as much as the code, but the community is needed IMO

I think the goal should be a clean & modern design to reflect Mithril. To set the tone of what we can be aiming for here is a prototype (by no means pixel perfect):

@v4n The logo + name there feels a little too "fat", if you know what I mean...The font and "fat" style to it reminds me too much of Immutable.js's logo, which IMHO is awful. It just feels really tacky to me.

@v4n 's change from italics makes a stronger image, but @isiahmeadows is right that the bolding is too extreme. Somewhere between them would be great imo. The italics don't add to the logo.

@v4n @drew11b I like that idea, I took some time trying to steal ideas from Haskell's site.

Some ideas on the visual direction this could go in:

New color. Mithril isn't green.
A different take on the logo (but the existing one is nice too)

I also think that, similar to the react js site, there should be a lot of interactive code samples on the home page, increasing in complexity as you go on.
Since I came here from react, I was attached to the JSX syntax and have been using the MSX transformer as part of my build process. Having the option to switch to that syntax in the interactive code samples may lead to a better proportion of react developers trying out Mithril. That, combined with the new lifecycle hooks, should make it pretty familiar territory for them. Just an idea.
I didn't do anything different with the layout--I like how the existing landing page is arranged. But here's my take on a possible look for the new site:

Seeing these ideas pop up make me really think the logo and branding really just need a complete redo. :smile:
As it stands, for a Web framework, we really should have a modern-looking Web page. Looking worse than even jQuery's not-very-good website sounds like a signal to pitch everything to me. :wink:

I, for one, like @sebastiansandqvist's proposal.

@sebastiansandqvist 's proposal looks best so far, should see if there are other proposals anyway.

@sebastiansandqvist is aesthetically pleasing, but is also essentially a splash of paint on the original design - instead of thorough redesign.  The core problem isn't that the existing site isn't aesthetically pleasing to the eye - the problem is it does not communicate why mithril is any better than any other library.
Preferences for JSX, and colors are important information, but they need to be grounded in communication.
We need to dig deeper, which is the reason for #1026.  I would have advised against tackling these issues yet.  I think it is too early.  But please, if you do want to talk design - take into account why people have stated they use mithril.
Design is communication.  When coming up with a design, try to communicate your interpretation of either that thread or your personal reason for using mithril.
@v4n's font choice may be a little too bold, but its grounded in a personal theory of Mithril, and communicating that:

I think the goal should be a clean & modern design to reflect Mithril

Whether or not you agree with the design, it would be good if other suggestions were grounded / substantive - instead of just being pretty / flashy / eye-catching.  @v4n deliberately is not invoking LOTR's typography because it does not communicate the values @v4n wanted to invoke.
I'm not saying I prefer either design - I am saying I prefer the approach of @v4n's design
Please read over what other's have said in #1026 and make your design reflect and communicate those sentiments.
That said, I really do think this isn't the sort of work that should be handled by a group, it should be an iterative process handled by a single designer who takes responsibility for a particular vision.
But if we are all going to discuss design, we need to go deeper or we will just bike shed unproductively eternally.
Also, I am fairly sure (could be wrong) @ACXgit is already tasked w/ the redesign by @lhorie.

@JAForbes You're right about my proposal not changing anything about the current site. The purpose was partly to explore a new visual direction (since much of this thread is about establishing some kind of branding for Mithril) and partly to say that I think the current layout does a lot of things well.
A github issue isn't the best place for a redesign to take place, though, and if there is already something underway handled by a single person then that is fantastic--in that case either this thread is unnecessary or can help give that designer some ideas. I don't think anyone here approached this with the expectation that the final logo/slogan/design would be their proposal, but rather that this would be a place to share ideas, whether visual and conceptual.
If ideas for the design of the site aren't open to the community, then that is fine, but I was quite excited by the thought that an open source project could be designed by its community. This thread was the first I've seen of its kind.
Your critique that I didn't explain any of the decisions I made visually is totally valid, though. So: The thin but uppercase text was what came to mind when considering "light-weight but robust". The color change was fairly arbitrary, but was from the idea that in Lord of the Rings, Mithril is a light purple-blue metal. That said, I steered away from LOTR in choosing a typeface because the reference really has nothing to do with Mithril itself. For the change in the icon in the logo, I wanted to strip away as many lines as possible while keeping the structure of it mostly the same.
In general, though, unless we really end up bike shedding or stepping on another designer's toes here, I don't see any cause to preemptively halt the discussion or discourage future posts. At least not this early.

@sebastiansandqvist Sorry for singling you out, I really wanted to make a more general statement.  I like your reasoning! :)  I also like your design.  Your design was so visually pleasing that it exemplified the point I was trying to make.
It may seem I was pre-emptively halting a discussion, but a) I don't have control over anything and b) there is a lot more context, both in the previous thread and in the original gitter discussion that led me to state my case.
This thread seemed to be continuing a trend toward's attracting users, instead of communicating what mithril is and why it is valuable in order to attract users.  And I wanted to state that I think that is problematic for a number of reasons that have already been discussed at length in #1026.
Reading over the comments I already see a couple bike-shedding comments taking place.    Discussion that is purely about personal taste instead of a justification based on communicating is always going to be bike shedding.  So if this thread is going to be productive, any criticism should revolve around what you want to communicate and why that design is or isn't successful in communicating that.
I think there are many reasons why it is probably impossible to design by committee.  But I have absolutely no control over this or any discussion, just stating my position.  So if people think the case I'm making is invalid, that is completely fine.
There are some fine design minds in this community so perhaps the discussion could be productive.  I am just noting my scepticism.

@sebastiansandqvist nice design, definitely visually appealing. Glad you added some reasoning on your second comment.
Echoing what @JAForbes mentioned, it's important the brand communicates what people should expect with Mithril. Mithril has a lot of good attributes, unfortunately not all of them can go in the same design (e.g. powerful (thick font) vs lightweight (thin font)).
We need to prioritizing what are the most important attributes and message we want to embed into the brand.
Personally I like where @sebastiansandqvist is going. Just one comment: In the top navbar the symbol & 'mithril' text feels a bit unbalanced due to the symbol being thicker.

@isiahmeadows JQuery is a prime example of what I'm saying.  Yes the design is ugly, but the site communicates well, and therefore it is a success.
Whether its the corporate support, the advertisement for sibling libraries, the bold icons referring to cross browser and CSS 3 compliance, The JQuery Foundation and mentioning that it is used by "millions of people", even the link to Support  It's all completely on message: JQuery is a safe, proven bet that is easy to use.
Yes it mentions being smart, and it has code samples etc.  But most of the website is about that assertion.
And from every angle, it is a better website than mithril's despite it's subpar aesthetics.
And the messaging isn't just the text content, knowing your message informs your; layout, palette, font everything.  You have to start with your message, it can't be tacked on at the end.
An example.  Considering their message is "reliability" and "ease to use":
Font
Italics suggest fast, and flexible.  It fits into the message of ease of use and extensibility.
But the font-weight is actually pretty thick, which suggests reliability and strength.
Blue Tones
Blue is the colour of the enterprise.  There have been studies that a salesman wearing a navy blue suit will sell more than a salesman wearing another colour.  Blue is the colour of IBM, Intel, HP, Dell, HE, AT&T, Microsoft and on and on.  Blue suggests safety and strength.
This is completely on message.
When you look at the site: https://jquery.com/ think about what it is trying to communicate, and how successful it was.  I personally think JQuery is a solid pitch at the demographic it is targeting.
JQuery is targeting the mainstream audience that doesn't know or care about Javascript, or Virtual DOM, they want to ship a product and they want it to work.  They are choosing this library for business reasons.  In my experience, enterprise doesn't even care that much about performance, so there is no reason to elaborate on how fast JQuery is.  There is no reason to have benchmarks given the audience and the message.
Now Mithril doesn't necessarily want to target JQuery's audience, or Haskell's audience, or even React's audience.  We need to determine who that audience is, and what we want to say to them.
That is why every decision in the design has to be focused, targeted and communicating.  And that is what #1026 is all about.

@JAForbes Yes, it is a strange approach, but as your belief is that design attracts users, my belief is that design attracts community.  Criticizing just to criticize is not some kind of solution to anything.  I'm not suggesting this is the best way to discuss redesign, but from the looks, this approach is sparking a fair amount of discussion and promoting ideas, nothing deconstructing except yourself.
Although,  I have spoken with a few of my buddies who've been using mithril for around 6 months in production, and they have said they use it because "It's simple, function-based, and the least opinionated [Virtual DOM JS framework around]". If you wanted a why-to-use-mithril quote, I believe this is what you are looking for.
I'd also say that the aspect of redesign matters more than what is redesigned.  The core truth that the community is involved is adventurous, yet pleasing.
I personally believe that this is a discussion and in no course a final answer.  The majority here are Mithril developers while at the same time this is not a web design community, so we are in a valid argument, but probably not here.  Let it take it's course, there are a million ways to approach a problem, this may be a great way.
@sebastiansandqvist very nice, I think the code bit should be closer to the top of the page to show what Mithril is, but it's cool.

I also need to express that to compare Mithril to jQuery, we have to account that jQuery has/had no reason to promote growth as they have been the dominant JavaScript library and are still holding the grail as the direction to take to learn JavaScript.  They are just references to what may or may not be a right way to express Mithril. I don't think there is an overuse in a particular color, nor is there a one true answer as to why people want to use Mithril.
I will take a whim to say that these taglines like VueJs and Mithril's current are not working very well because they seem biased (the frameworks are trying to express why they're better), opposed to Preact's objective look on their library, but of course the name helps.  Taking how GitHub dominated over SVN, developers want and need tools that don't get in their way, fast is just a bonus.

Other proposal logotype with color (w/reversed) and a new slogan:

@Javacodia I love a lot about this for so many reasons!

"Light-Strong" playfully summarise the exact sentiments espoused by so many developers
It is playful, which gets to what @Bondifrench said, about Mithril being fun.

The font is strong and light, thick and thin
The colour is fresh, like mint.  It feels professional without being conservative.  Strong without being heavy
I like that the slogan says The instead of A.  It's confident.

A few critiques:

I personally think we should get away from the word framework for reasons already stated.
Artisan is clever, but also evokes the hipster scene which is a lot of style and not much substance, which isn't mithril at all.  Something to consider.
I think that slogan could pack even more message into it.  e.g. "The Light, Strong JS library for building Applications", or "The light framework for building strong applications".  Explicitly state what it does, instead of assuming the culture can fill in the gaps.

Great!

I'm a bit into machine learning, there is tool that generates a multitude of different logos, one you give it a word. Maybe a few of us can use it to try to get to a nice one?

@orbitbot

I’m a bit confused by this issue and the discussion so far. Not that I wish to step on anyones toes and my intent is certainly not to offend anyone, but I feel that the whole discussion so far is bikeshedding. We’re almost literally discussing the color to paint the shed :smile:

Quite literally, that's the whole point of this issue. :wink:

[...] mainly since it doesn't pass an important test at first glance: credibility.

I agree. It could use a lot of improvement in that area.

Some other comments are closer to what I would see as a useful discussion to have: spitballing content for the website, and how to present the usefulness of mithril in an effective manner. In my experience it's actually easier to design around constraints, so exploring the contents of the site would be the most useful thing to do (at least until the rewrite is actually finished :wink: ).

@orbitbot

I’m a bit confused by this issue and the discussion so far. Not that I wish to step on anyones toes and my intent is certainly not to offend anyone, but I feel that the whole discussion so far is bikeshedding. We’re almost literally discussing the color to paint the shed :smile:

Quite literally, that's the whole point of this issue. :wink:

[...] mainly since it doesn't pass an important test at first glance: credibility.

I agree. It could use a lot of improvement in that area.

Some other comments are closer to what I would see as a useful discussion to have: spitballing content for the website, and how to present the usefulness of mithril in an effective manner. In my experience it's actually easier to design around constraints, so exploring the contents of the site would be the most useful thing to do (at least until the rewrite is actually finished :wink: ).

Due to the bikeshedding nature of this bug, it may take that long before we really get an idea of the design in the first place. Conceptually, the rewrite isn't going to be a massive difference from what already exists. It's just going to be a bit smaller in scope, with several things like m.request, m.route, and m.deferred/m.sync going away in favor of built-ins and external equivalents instead (window.fetch, new Promise and Promise.all, and an external module).

In the spirit of Stealing good ideas from other places™: [list of tutorials]

Yeah...we really need to have live tutorials and other resources for beginners. We really need to have a lower bar for entry so people can learn better.

Other useful things that people from different backgrounds would appreciate is probably "Example of Mithril + X" [...], as well as "Mithril for Angular developers" or "How is Mithril different from X".

That would be useful, as well. I think @lhorie could really help with the "Mithril for Angular developers", since he himself was working with Angular when he wrote this framework (that his company later switched to). Oh, and for your vdom addicts, a "How is Mithril different from React" is pretty much obligatory.
// React + React Router
import {Component} from "react"
import {hashHistory} from "react-router"
class TagSearch extends Component {
    getInitialState() {
        const tag = decodeURIComponent(
            hashHistory.getCurrentLocation().slice(5)) // /tag/

        return {
            tag,

            // A null tag is valid.
            fail: tag != null && !validateTag(tag),

            // Set the initial value based on the URL.
            value: tag != null ? tag : "",
        }
    }

    onsubmit(e) {
        // Just in case the browser has already dropped the legacy
        // versions or doesn't support the newer version.
        if ((e.which || e.keyCode) === 13 || e.key === "Enter") {
            e.preventDefault()
            e.stopPropagation()

            if (validateTag(this.state.value)) {
                hashHistory.push(
                    `/tags/${encodeURIComponent(this.state.value)}`)
            } else {
                this.setState({fail: true})
            }
        }
    }

    render() {
        return (

                Search for tag:
                <input type="text"
                    value={this.state.value}
                    onInput={e => this.setState({value: e.target.value})}
                    onKeyDown={e => this.onsubmit(e)} />
                {state.fail ? (

                        Tags may only be a comma-separated list of phrases.

                ) : null}

        )
    }
}

// Mithril (rewrite)
import m from "mithril/render/hyperscript"
import createRouter from "mithril/router/router.js"
const Router = createRouter(window, "#")

const TagSearch = {
    oninit({state}) {
        const tag = Router.getPath().slice(5) // /tag/

        // A null tag is valid.
        state.fail = tag != null && !validateTag(tag)

        // Set the initial value based on the URL.
        state.value = tag != null ? tag : ""

        state.onsubmit = e => {
            // Just in case the browser has already dropped the legacy
            // versions or doesn't support the newer version.
            if ((e.which || e.keyCode) === 13 || e.key === "Enter") {
                e.preventDefault()
                e.stopPropagation()

                if (validateTag(state.value)) {
                    Router.setPath(`/tags/${encodeURIComponent(state.value)}`)
                } else {
                    state.fail = true
                }
            }
        }
    },

    view({state}) {
        return m(".tag-search", [
            m("label", "Search for tag:"),
            m("input[type=text]", {
                value: state.value,
                oninput(e) { state.value = this.value }
                onkeydown: state.onsubmit,
            }),
            state.fail
                ? m(".warning", [
                    "Tags may only be a comma-separated list of phrases.",
                ])
                : null,
        ])
    },
}

Of course, above the fold slogans and colors are important to catch attention, but that's hardly where the meat is.

If we don't have the audience's attention, they're never going to see the meat. When you're trying to persuade someone, you have to have their attention before you can persuade them of anything. Otherwise, you might as well be trying to convince a brick wall to move.

@Bondifrench I wonder if it's me, since it's generating mostly irrelevant and/or not very good logos. :smile:

Things I like about @sebastiansandqvist's design:

The blue is a nice colour. The gradient is just enough of a hint at something metallic, which is probably about as far as any kind of "mithril" analogy needs to go. I find that particular shade/gradient suggests a very nice material as well.

My favourite font choice so far.

I like the 3 interlocking shapes motif. I'm not sure what it was originally intended to suggest, but to me it says M V C. I much prefer @sebastiansandqvist's shapes to the circles. Much more elegant IMO.

I concur with @orbitbot's points. Content design is more important at this time.
Points I would like to add to the landing page:

A short description what Mithril is about, before moving to the elevator pitch and the why
More convincing arguments: who is working with Mithril

@orbitbot I don't think content and UI design need to be separate and in many cases need to be combined.  For example, content needs to be placed in certain spots, but without a UI, what content ideas are available?, and vice versa.

Design is much harder than is being depicted by a lot of these comments.
Separating different disciplines of design arbitrarily will not avoid bike shedding.  Bike shedding is just arguing about personal taste as opposed to trying to refine a message.
You can't decide on "content" until you know what you are trying to say.  This new content thread will just be people arguing over word choice instead of colours / fonts.  It all has to be based on a unified message.  Once you have that, everything flows from there.
If you don't know your message and your audience, your content will be less effective.
I agree that designing with constraints is important.  I'd take it further, I'd say it is necessary.
But the only constraint that is meaningful is: what you want to say, and who you want to say it to.
Once you have that you can decide on:

layout: what is emphasised vs what is de-emphasised.
layout: what lands on the main page, and what is just a link.
layout: detail vs abstraction
content: Are code examples important, which ones?  Who is reading them and why?
content: Do we want to seem different ( a risk, but more intriguing ), or similar ( safer, but less interesting)
content: Logos, Fonts, Colours, I've already covered above how much that is controlled by your
messaging
usability: Does the layout work on devices we want to target
usability: Is this content itself, understandable by our target audience, as opposed to one of us

Everything.  It's a much longer list.  But hopefully you get the idea.  Every decision in every iteration is essentially the same question with a new context: "Does X communicate the message better than Y"
A lot of this discussion makes design seem like a layer cake, where we can just make up each layer as we go along, refining as we go.  That isn't going to be the best cake on any axis.
A designer can wrangle all these different concerns, it is their job.  It is harder than what is being inferred here.  I'm surprised some of the designers in our community haven't already said as much.
Designing anything is a lot like choosing your stack for an application.  You can't decide on each layer in isolation, you need to think of the best combination for your context as a whole.
A lot of you seem to want to rush to the finish line.  But it's the wrong finish line.  Getting their faster doesn't mean you win.
After #1026 settles down, there should be another thread that aggregates those ideas down into a single idea / message.  This is the seed that informs every branch on the tree that will take form.
Then there could be separate threads that reference each-other, but are all branching from that core message.  If there is disagreement, it can be resolved by deciding which side better communicates the core message.
Perhaps some of you think the message is obvious.  But you would be surprised how much different people interpret and value things differently.  That is exactly why #1026 isn't asking people what the message should be, it is asking them why they personally use mithril.  Because even discussing the message is not productive without having some data to back it up
So, please don't start a content thread.  Or any other design related thread.  You can't design in silos or by committee.  It seems exciting that it is all being done in the open, because it is unheard of.
But it is unheard of for a reason: it doesn't work.

@JAForbes I think you are misunderstanding the issue, the point of the discussion is a conglomeration of efforts to propose what may or may not work.  Whether or not anything here will be used is not up to us.

You can't design in silos or by committee.
It seems exciting that it is all being done in the open, because it is unheard of.
But it is unheard of for a reason: it doesn't work.

I would like to see your point of reference.

Perhaps some of you think the message is obvious.

Critique is powerful, conflict is not

@rdsteg I am critiquing this process.  I am not sure why you think I'm doing anything but that.
I want the redesign to be as productive as possible, and as a member of the community I am critiquing this process because I think it is counter-productive and a waste of a lot of people's valuable time.
This perspective is based on historical precedent and my personal experience.

I would like to see your point of reference.

Well, the burder of proof is on you because it is so rare for design by commitee to work.  But anyway here is some recommended reading:

https://en.wikipedia.org/wiki/Design_by_committee
https://en.wikipedia.org/wiki/Groupthink
https://en.wikipedia.org/wiki/Blind_men_and_an_elephant
https://en.wikipedia.org/wiki/Abilene_paradox

Look at ~2010 Microsoft, complete disarray, separate divisions that can't cooperate, and yet any one person could see a clear path of unification, but because of the division of labour it simply wasn't possible.  Compare it to 90's era Microsoft, they had a single high level goal:
"A computer on every desk and every home".  A unified vision that informed every branch of their business, and they were successful.
Any post-mortem I've read on any successful project has a clear pattern; they had a niche, they had a vision they executed on it.

I think you are misunderstanding the issue

I am not misunderstanding the point of this thread.  The point of this thread is for us all to suggest ideas for different designs - these designs may or may not be used, it is just a place to have a discussion that could inspire the actual designer.
That sounds innocuous, but it isn't.  Even if you only consider the opportunity cost, it is counter productive to invest community energy in a process that has no output.
In these sorts of discussions there also tends to be a trend towards the lowest common denominator.  Valid ideas are watered down because there is someone who has a personal preference against it.  The community trends towards choosing the safest option ( Group Think ) ultimately, the community chooses an option that is sub-optimal and that no individual would ever have chosen Abeline Paradox.

I think @sebastiansandqvist has the best idea design-wise. I think if we have a couple of willing people to work on this then they are to jump in and get on.
I think vue has nailed it https://vuejs.org/

If I may spend a couple of words on the matter as a designer, I would strongly suggest to focus on the message first. Design is visual communication, once the idea you want to transmit is clear the design follows. Design is functional to the content, so if we aim to the best result we need to clear what the content will be first.

@ACXgit brings up a really good point (I'd argue it's the most important one). So with that in mind, what things would you guys like to see in the docs for the rewrite?
Here's what I think is the bare minimum necessary:

API docs (explanation in prose, runnable code examples, signature docs)
Tutorial for beginners (installation, simple application)

may be more than one tutorial, if it simplifies explaining various parts of the API

Other things I think would be nice to have

architectural styleguides, similar to angular
comparisons w/ other libraries and frameworks
benchmarks
tutorials for hooking to various libraries (e.g. bootstrap, dragula, RxJS, etc)
tutorials for x-to-js languages (e.g. typescript)
lots of examples of various complexities

The homepage needs to prioritize things that are differentiators for someone coming from a background of jQuery and/or another framework (likely Angular 1 or React). I'm thinking:

showcase easy installation and super straightforward sample code
highlight simplicity in some objective ways
who is using it

Benchmarks and code size are the two things that get mentioned the most on twitter, etc
Any other ideas?

Guys, I'm not really interested in a discussion about how to design a site in general. I'm more interested in what kinds of things we could have in the site to make it a good resource, and interesting ways to show priority items in the homepage.
Discussions about usage of color and styling elements are welcome too, but in my opinion, they are secondary to the goal of making the site relevant and engaging for users

@orbitbot

What I fail to understand here is how a content thread would be anything else than trying to figure out the message and how to tell that story, in a more ordered fashion than a (this) discussion that mainly is about ideas for the graphic design.

The difference is, such a discussion would be an aggregation of data instead of people debating their own personal preferences.  So it's straight forward, there is a constraint, you can make a case but it has to refer to raw data.

I resent talking about "The Message", "The Design" and "The Content" in abstract, because it just leaves everyone believing they've understood everything in the same way without that actually being remotely the case.

That is the precise reason why deciding on a message is important.  So we can make concrete decisions instead of abstract one's.  So we can have a goal that focuses discussions, that simplifies debates.  The Francis Ford Coppola quote I posted above is a great example of how knowing your theme/message expedites the design process.

I believe that a way of discovering what you are trying to say is to try to write some content to see if it actually comes out well. In the process you might discover what parts are lacking.

This is the best way to design anything as an individual.    But this process doesn't work as a collective because we all have own interpretation, connotations and value systems which makes thorough exploration of your own harder.
@lhorie

@ACXgit brings up a really good point

(Correct me if I'm wrong @ACXgit), but I think @ACXgit was agreeing with me.  Suggesting content right away, or suggesting particular aspects of a design before you know your theme/message harms communication in the long run.  It's so important to have a consensus on what we are trying to say, ahead of time.

Guys, I'm not really interested in a discussion about how to design a site in general. I'm more interested in what kinds of things we could have in the site to make it a good resource, and interesting ways to show priority items in the homepage.

The only reason I'm talking about design in general is to underscore the importance of the process.
If you would rather jump to the end of the process, of course you can, it's your project.  But I strongly believe if you do, the existing problems with the website will not be solved.

@JAForbes I think figuring out the scope of the content is the next logical step. I'm going to risk sounding like an dictatorial ass but I actually disagree that we need consensus on the message. Different things are important for different people and you can never make everyone happy, and saying we need a message is not very actionable. What contributors need to keep in mind are the goals of the site.
The goal of the homepage should hopefully be fairly obvious: to draw people to try Mithril. Even if most of us think aspects A and B are Mithril's true strengths, there's no point preaching to the choir, and simply saying things like "it's simple" or "it scales" is just going to fall on deaf ears (even if those claims might be technically true).
To get people on board, the homepage content has to address the audience's pain points: Why should busy-on-a-deadline-Bob be using Mithril when they can pick Angular or React? How can we erase common doubts in sceptics? What can a cool kid brag about? These may or may not be things you and I think are important or even valid points, but the points need to speak to the audience. One way to put yourself in the audience's shoes is to ask "what would the Aurelia/Vue/Ampersand homepage need to show to convince me to try them?". One could even go around the office doing that exercise to get different points of view.
Once a potential user decides to make the commitment to spend 15 minutes on a tutorial, the quality of the content will then have to speak for itself. A learn-the-whole-damn-thing-in-thirty-minutes tutorial is something people have used as bragging points in the past, and a in-depth section about integrating with dozens of real life and cool-kids libraries is a good way to signal quality via a go-above-and-beyond tactic. A solid section on architecture is something a lot of people would appreciate.
  It's great to get you to weigh in.  In fact, my entire point is there needs to be a single direction.  Dictators help with direction.
I think you are imagining I want us all to agree on some vague hollow platitude like "It's fast".  I don't want that at all.  There doesn't need to be a consensus, there needs to be an agreement that a decision has been made on what to focus on (by you or someone else). #1023 was meant to aid that decision.
Skipping into actual application without having that decision / focus, is just going to lead to discussions with no destination.  As you said yourself, different things are important to different people.  That is why it is so important for a set of constraints / parameters on what is on and what is off the table.
Designers often call those constraints, the message, the vision, or the statement.  It all sounds a bit like a cult, but hey! I didn't make it up, and its effective.
But if you think you don't need that, then that's cool.

Personally I understand constraints to be a different thing from the vision, but whatever. Potato, potahto :)
Anyways, here are some parameters:
Artistic:

Something better than a huge static image as above-the-fold content in the homepage (like Angular.io). Some alternatives: Ruby showcases its ""know-what-you-mean"-ness. Yama showcases development speed. There's lots of room to be creative here

I don't have a strong opinion on colors or fonts. The main complaint I've heard is that the current design looks dated/ugly. Personally, I prefer minimalist designs, but as long as it has a modern feel and it's easy to read text, I'm cool with it.

logo: the borromean rings are the logo. Could maybe try playing with stroke thickness and colors? Could at least use SVG instead of the horrible CSS hack I'm using now

don't evoke LOTR, it kinda distracts from the point

responsive design

Things I think are important enough to be on the homepage

Selling points: size, speed, batteries-included. We can probably drop the safety section, since nearly every other framework is on the ball too nowadays

Validation: famous companies using it, maybe community stats (e.g. gitter subscribers). Drop old twitter comments

Sample code snippet. Something short but more functional than hello world

Some sort of comparison with other frameworks. Performance was a big differentiator before, but now maybe installation effort is more relevant? Needs to be visually appealing.

Calls to action: invite users to dig deeper. Link to tutorials, sample projects

@lhorie What is the current state of the redesign? Is something currently underway, and are you looking to have community input here? It was mentioned that there was already someone tasked with the update. But, if you are looking for community input, what would be most helpful at this stage?
@JAForbes I think that there's a difference between design by committee and making it open source. If I make a pull request, for example, the core contributors determine whether it is merged or not. If my PR is not inline with their vision, of course there was some wasted effort, but often there is a bit of discussion beforehand to prevent that from happening, and that discussion is what I believe this thread aimed to be. We've instead effectively been bike shedding the process here and I don't think that's productive either.

@sebastiansandqvist: @ACXgit offered to help w/ the designing and I'm probably going to be the one writing most of the documentation. As far as community input goes, I'm interested in hearing about ideas for sections to add in the docs and out-of-the-box ideas (things like the Yama demo as an alternative to a hero static image, as I mentioned above). Viral marketing ideas would be good too.
Re: look and feel, my conversations with @ACXgit so far were mostly about overall style (the thing I mentioned about my liking of minimalist design). He suggested I take a look here: http://beautifulopen.com/ and I told him Vault was the closest thing to what I'd try to implement if I were to take a stab at the redesign myself.
In the interest of moving design forward, we could possibly start iterating on your proposal (since it has the most likes so far). Or others could pitch their ideas. I'd love to see one from @ACXgit at least.

@lhorie Thanks for direction, the original idea was to just get visuals that portrayed ideas.  I still hope people can post their ideas visually, but the direction was lacking, sorry.
I have to say vault looks a lot like vuejs, and I would reccomend staying away from the vuejs approach to stay away from creating a stereotype of 'react knockoff'
Slide-out navigation for docs is a definite YES for me. Check out this approach: http://www.material-ui.com/
These are possibly the best docs I have ever navigated through.  If anyone has a better suggestion than this, it would be beneficial.
I think open-sourcing the site can speed up a lot of the process.  After all, I think the main problem is the current look of mithril.  The quicker a first rendition is made, the more people can start to promote the growth.
Possible niches that can throw mithril ahead:

Mascot

Hello Mithril (like droid but something for mithril)

Silly/funny/surreal landing

deer head
animated
glorious landscape

Engaging one-page app

such scroll
A lot might here might seem way off-topic, but I feel like mithril has run behind in terms of head-start for it's competition for the virtual dom gold, and I'd like to see mithril grow ten-fold.  If nothing else, I can see mithril as 'the door to the virtual dom world' for new users.

The hamburger menu / slide out documentation thing has some issues, google for "hamburger menu" to find discussions. In the material-ui example @rdsteg linked they've put too much subnavigation there, as an example.

Maybe you'll be happy with something like this then: https://guides.emberjs.com/v2.5.0
Karma's small page might be something to consider, and vorlon shows off a simple animation that works well, good finds.
I knocked the vault design too soon, on second look it might be quite what mithril may be looking for.  It expresses 'small' by their 5-word slogan, an easy to understand visual concept of what it does, and some fantastic artwork.  I don't know what mithril's future theme will be, but following those guidelines might result in awesomeness.

@rdsteg I am quite fond of the Ember docs. Just like in MSDN docs or the like you get to choose which version you want. E.g. Mithril 0.2.x or 1.x. All information about 0.2.x is already there, so we could just copy the content into the new layout. But the layout itself should be driven by everything we need from 1.x and possible future content.
Concerning the new homepage itself, I would like to see a focus on sharing wisdom in the form of pure JavaScript snippets. Mithril is not "cooler than the others". That would be disrespectful. Mithril is also not more feature rich. We don't need to sell any buzzwords. When I first read Leo's blog posts I was really delighted. They were short and focused. They didn't show you anything arcane. ES5 + Mithril's structure and Boom! you're done. So my vote goes for a couple of examples to show off what Mithril has to offer right on the front page. On top of that could be Mithril's "Snippets of Wisdom" (like the old blog posts) which we could just link to as a small news-ticker.
Examples
To me Mithril is like the swiss army knife of virtual DOM components. So we should show off what we've got in very concise examples, e.g.:

a list component: Build a list item component and add it to a list component. Add a click handler to the list item component which can be defined via the list component (this handler will be handed down to the list item component). Add API methods to get the data and to manipulate it. A list item can be toggled between visible and hidden state. -> show a list of names
a filter component: Build a "search bar"-component with a filter function. Add it to the table container component. Use the list components public API to access its data and filter it using the visibility toggle. -> show the previous list of names, but filtered
fetch data: Use Github's API to fetch Mithril's contributors and show them in the list. -> show a list of Mithril's contributors (still filterable, of course)
search via query strings: Use the router to enable filtering via query strings. -> show a list of Mithril's contributors; now not only filterable, but changing the filter also sets a query string in your URL. Changing the query string in the URL also triggers another filter

These short examples can be presented as embedded JSBin (or whatever service you prefer) containers on the page which also briefly describe what the code does. There should be a link to a tutorial explaining what needs to be done to achieve this (and possibly why) somewhere in the description. This way we can build more complex tutorials and show off parts of it on the homepage. Reusing the code from the homepage's example in advanced tutorials builds upon a strong familiarity with the code for users since they already saw parts of it. Advanced topics could then cover:

adding animations (than again looking at the rewrite this could turn into a beginner friendly topic)
An SPA with multiple pages where one page has more than one of those example lists from the homepage (core problems: how to get the router to route the pages and handle all query strings correctly + how to isolate the list -> make it idempotent)

Blog
What got most of my attention on Mithril's homepage has always been the blog. The very focused and concise articles helped me get a feeling for Mithril. I'd love for all of us to write concise articles like that as little snippets of wisdom as a seperate part of the blog. The reason for this divide is that the main blog can be used for any news (like conferences, announcements e.g. for new versions, as a stage for partner projects, etc.) and the other part can solely be for these snippets of "mithril in action". This way we would have the old blog, but would'nt mix it with different kind of articles. And it needn't be a part of the docs, so we could also flood it with manuals for e.g. "How to build a data driven component for a firebase backend". It may or may not be a good example and it may or may not help people, but seperating it from the official docs gives us more space to go wild on our ideas instead of linking the official docs with How-Tos for third party libraries.
Docs
The documentation has always been top notch and contained many useful pieces of information. I personally would love it to stay like that and not be "just another fat JSDoc", because Mithril's API surface has always been very small (and the rewrite looks like it will be small aswell). So maybe we could split it up into 2 kinds of docs:
A small JSDoc with the most needed information about the API like e.g.:

Import path: Which module does this function come from?
Signature: the function's name, parameters + short description, return type + short description
Description: A short description of what this function does with one or two examples (only happy paths)
more information: A link to a overall architecture document or an appendix which explains the functions inner workings in greater detail.

Architecture
Docs for a deeper dive into Mithrils inner workings would be needed. The different redraw strategies of Mithril <1.x are a good example of that. These can be seperated by their overall topics e.g.:

Routing: What makes a route? What does the router do to your browsers history? History.push vs. Hash? How to use query strings?
VDOM: The redrawing mechanism in detail -> What does Mithril do to your via hyperscript generated objects? How does a component livecycle look like?
Templates: How does hyperscript work?

I think I might have overdone it with my musings, but maybe it helps someone to distill something sane from it. Sorry for echoing anything that was said before, but these are the most important bits to me.
- Jay

@Draggha Indeed, a newsletter would be a nice feature too

As a newcomer (a couple of days) to the project I have been reading the API docs a lot. I'm finding it hard to get a good overview of functions parameters when looking at the signatures.

Maybe having some kind of table structure could help to make it more readable? Something like @ArthurClemens Polythene library uses in the docs?

@rzetterberg that's an awesome idea!

@lhorie I would agree as well. Polythene isn't the only one - I believe Angular 2 uses that kind of thing as well, and there's several others I can't remember right off.

@porsager just shared w/ me a logo suggestion: http://porsager.com/mithril
What do you guys think?

Clumsy
On 18 May 2016 2:26 p.m., "Leo Horie"<EMAIL_ADDRESS>wrote:

@porsager https://github.com/porsager just shared w/ me a logo
suggestion: http://porsager.com/mithril
What do you guys think?
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/lhorie/mithril.js/issues/1033#issuecomment-220025081

@dontwork Did you check out the mono and color version as well? I would love a more elaborate critique ;)

@porsager IMHO that logo by virtue of being a box is quite bulky which I'm not sure manages to convey the lightness, and speed of mithril as a framework.

@nordfjord Yeah, I can see that the 3d one might feel a bit heavy.
My idea behind it was actually to outline the simple, modular and composeable nature of using mithril.
I don't think it looks heavy or clumsy in the colored / mono variants. The 3d version was mostly thought of as an interesting way to show the idea behind it.

I've gone through the logo creation process for an open source project, twice, and at the designer end, so I know how frustrating the process can be (most likely is). Especially developers tend to search for "deeper meaning" (read: superficial image puzzles). Luckily we haven't had that here.
And nevertheless, you need to have feedback.
To me the logo variants (all 3) feel heavy like a building. Somewhat Drupal meets MTV. Perhaps it's my eighties generation.
My personal connotation with Mithril is lighter and more flexible.
But I like the use of the M as main element.

@orbitbot Thanks for the feedback. The superhero/shield angle was actually chosen not only to bring out the M from the shape, but also to fit in a little with the html5 logo
I know leo likes the Borromean rings, and I've also tried to play around with them, but it's hard not to have them look like the Bio Hazard symbol.
@ArthurClemens Thanks for the feedback. I do see the resemblance to drupal and mtv, so the question is if this idea can be worked to something lighter, or if we should look in an entirely different direction.
Not frustrating yet, just wanted to put the suggestion out there, but yeah, with oss, there are a lot more opinions than when working with clients (except when their 10 cats are included in the decision process as well ;) ).

@porsager I forgot to mention I absolutely love the font you chose :)

@porsager the perspective used for the logo is reminiscent of wide angle photography which is often used to capture large objects, hence the "heavy" impression it gives.

@pygy I'd have to agree with that one...

I thought I needed to add this input.

Mithril is going under a complete overhaul so something like @sebastiansandqvist's is too similar to the current

Expressing what a framework or library has to offer through a logo is very hard to reason about and won't get very far in this discussion.  I support a more unique adventure towards a logo, something that none have touched before.  'm()' as a logo could be something to consider if mithril is looking to continue to use that style long-term.

 The first one is mine :D but I love the big one. It would look great with the lower thin font. I would love to hear your opinion and make it even better if its possible. @lhorie

@ludbek tried making a couple animations real quick, i like the idea

here's another idea i had, i didn't put time into it so it didn't render so well... take it more as a concept

@rdsteg yeah the logo is a lot easier to animate but once its been selected ;)

@orbitbot  yeah it does. The main concept behind the logo is the letter 'm' and two pieces of metals being tangled together(just like in mithril).

When i think of mitrhil, i think of a bar of metal and the first picture which then comes in my mind is something like the minecraft iron bar.
Click for Picture
That could be a easy to remember and simple logo.

@ludbek I like the idea, but I'm not as sold on @rdsteg's animation ideas...they just feel a tiny bit cheesy (like 99% of all animated logos IMHO, but that's a debate we can discuss elsewhere).
@nbrunch No. Please, let's not associate a web framework with Minecraft... :cry: (Plus, Minecraft doesn't even have mithril as a resource unless you're using a mod that includes that.)

@nbrunch
Okay...in all seriousness, I just don't think, for a sleek, clean, and powerful Web framework, the intentionally low quality, blocky style of Minecraft and similar would really help advertise Mithril to the general, potentially unfamiliar audience. To be honest, low quality and blocky graphics, even if it's intentionally done well, may undermine the credibility of Mithril as a web framework to some newcomers, especially those in corporate environments already writing at scale or those who are non-technical and looking for some "bright and shiny" thing to "show" their developers and "impress" them, so they end up stuck using it, even if it weren't their first pick.
Even sites like jQuery's and Rails', even though they may not have the best design, are at least clean and professional, and have the ability to draw people in. Python, a language named after the comedy series Monty Python, with a rather eclectic and humor-loving community, still has a respectable, clean, professional website. If you want to see the how clear credibility makes a difference, compare the popularity of Racket and Scheme, two extremely similar languages, to their websites. One of the biggest complaints about Lua is its website and lack of decent tutorials gives the false first impression it's obscure when it's in fact very popular for scripting games and embedded hardware/applications because the language is very simple with simple, first-class FFI bindings, and with the reference VM, tiny and light on memory. It fails to establish the credibility it should, or it would likely be competing with Python directly by now.
We should stick with something at least generally expected of a Web framework, if we want to expose more people to the library. It'll also help a bit more in SEO, which really matters this day and age, no matter what your site is.

@isiahmeadows
seeing your point of a professional look of the website.
(and i know that minecraft has no mithril, its just stupid me who always thinks of the metal bar ; ) )
But i don't like an animated logo, because i associate every moving (animated) piece on a website with adverts or 90's  tag also its more complicated to produce stickers and t-shirts (which hip developers really like ), because you always have to ask in which state the logo is correct: for example the logo @rdsteg : is m () the logo or m(mithril)
Same is the again recognition.
What do you think about a more colorful logo ?

@nbrunch I agree about the animated logos. Some sites can get away with deliberately low quality, and it's possible to create a decent animated logo without making it super cheesy, but it's extremely hard to actually make something interesting with it.

This issue lasts for almost a month and I remember talks about mithril logo or redesign a year ago or so. Honestly, I started using Mithril because I saw it on Github first and read the code. If I saw the current project page - I'd probably though it's some project abandoned years ago - tweets from 2014, everything is square and pale etc.
In my humble opinion it would be better to apply any of the designs suggested above and keep it for a month or so to see how that affects the visitors. Like some A/B testing. I bet that any redesign would improve user experience, so instead of looking for a perfect one - why not to try a good-enough one?

@zserge That's what we're trying to fix.

Here's my idea for a logo (I have an SVG saved for each as well):

The simple, soft monochrome style represents the simplicity of the framework. Most of us that love Mithril love its simplicity and elegance, and a simple, elegant logo best captures that sentiment.
I chose the text, m(), because that further emphasizes the simplicity and elegance of the framework. It's the most common method you ever call, and it has an aesthetic appeal even in the code itself. You can't get much simpler of an API than that even with macros.
The font, Calibri, was chosen for its rounded edges and minimalism otherwise, because I wanted to make the logo feel approachable and less edgy (no pun intended :smile:). I avoided monospace because I wanted to avoid giving a rigid, structured feel to it.

In case you're wondering about the details, here's enough of a description you could fully recreate it your self:

Size: 300x300 pixels
Light color (background in light, text in dark): 100% white (#FFFFFF)
Dark color (background in dark, text in light): 75% black (#404040)
Font: Calibri, 160 point
The text is centered both horizontally and vertically inside the logo
The text is exactly m().

I created it in Inkscape, in case your version differs from what's here.

With a dot in the middle, makes an eye!
m(•)
m(•).
This would suggest the view purpose and add some opportunities for custom styling of the dot/logo (e.g. iris, blink animation, iris animation ...)

I absolutely love @porsager's logo — to me, it doesn't feel heavy, it feels sturdy. It feels like blocks, yes, building blocks. This seems apt, considering Mithril's separable parts coming together to form a cohesive whole, not to mention how it gives developers building blocks to make their app with. It's built from a very simple shape, just a couple of cubes together, reflecting Mithril's simplicity. I love the colors, too.
Also, I think this logo may feel less "heavy" to y'all when used in practice. Some possibilities:

I also queried three random friends, two programmers and a designer, and they all love it.

Apart of coding I also do design, and I've seen this exact logo idea used so many times (honestly at least 3 times I can recall, last time just a weeks ago or so). Not an issue if you don't mind your logo colliding with other projects.

@lord Thanks a lot, and thanks for the great mockups which i probably should have done to begin with as well ;)
@darsain Would love it if you could link to any of them. The first thing i did after doing the very first sketch was to Scavenge the internet for anything like it, and the only similar one i found was one from 2006 which has never been used. If i had found anything that it would collide with I wouldn't have spent the time to go further than the hand sketch.

@porsager the blue blocky M version looks like the next letter in the Nodal Font.

...or the natural offspring of Nodal+Webpack.

I think it might be useful to suggest a deadline by now; anyone who wants to suggest a logo can be taken into account, but the thread seems to becoming a circular doubt as of now.  I'll close the issue by friday.

@lhorie What do you think of @rdsteg's idea? IMHO I'd give it one more week than he would (Friday next week, not this), but I'm starting to see similar, and the beginnings of an emerging consensus.

I'd say close on Monday, there doesn't seem to be many posts throughout the week

@rdsteg I'm saying giving it one more full week. That includes a full weekend as well. :wink:

@rdsteg
(Sorry for deleting your post...I clicked the wrong post + button when I tried editing my post...)

I'd say close on Monday, there doesn't seem to be many posts throughout the week

There's been a few decent posts during the week, so I'd like to give it a full week. I'll give it until Monday the week after next, unless the conversation fully dies out before then.

@hville Yeah I see the style is the same, but honestly I don't see that as a problem at all?
I extended the kerning on the letters a bit, but this would be my final suggestion..

@porsager design is really hard because everybody has an opinion ;). The black and white version works better. Relying on shades of similar luminosity and tint makes it hard to find when scaled down.
I actually liked the old Mithril page. Not pretty, but of the many Javascripts projects around, it was a good example of communicating what, why, how right up front without scrolling or navigating.

Closing for now. A new issue can be opened later when we're ready.

Uploaded album of submissions here: http://imgur.com/a/PC8I1

+1 for Javacodia s suggestion (bottom version).

@kvanberendonck Note that the site is already live with a logo similar to the old one. (I wouldn't be averse to changing it, though.)

Oh I know, I was just under the impression that it was not final.
If it is final, then the look and feel of the current site in comparison to some of the wonderful suggestions here gave me that impression (no offence intended, just saying it how it is).

Here's a design concept I floated on Gitter a while back:
http://www.spacejack.ca/mithril-design/

FWIW I like the current website/branding. I like its plainness and information density.
For newcomers, the first thing they see is "What is Mithril?", and then they can immediately get a taste with "Getting started".
For veterans, most of the time they'll be visiting the website for docs, which are immediately available in the sidebar.
The website is nothing more than it needs to be, which I think is very reflective of Mithril itself.

I think the current website has a home brew feel to it , and as a company that's not the type of feel you want to get from a library before you adopt it.
There needs to be a way to communicate both lightweight/meticulous and enterprise-ready at the same time .

(Because it /is/ enterprise ready, we've been using it since inception to power a cutting edge ERP that translates desktop apps to the web, streaming huge amounts of data through a web socket for client sided data analysis views )

@kvanberendonck I do kind of get a similar less-professional appearance from it, too, like it hasn't had much design put into it.

This is my final update.


added useful information for building on osx

tested on osx 10.13.4

Looks good to me, I'll merge and fix the spelling mistakes


"latest" release not pointing to binaries for automation

We have setup automation via Puppet to download the latest linux-amd64 release of ctop. However, your latest release doesn't contain binaries, so the automation fails. I humbly request that you either use a separate label for "latest binaries' or ensure that the "latest" label contains them (by, perhaps, releasing the -deps, then another version with the binaries.)
Thanks

Apologies for the hassle @joeljacobs; the latest release is out now and all future release will include the same binaries.


[GPU] adding support for CUDA 11.2

Adding CUDA 11.2 support.
@mengdong can you please review?

/gcbrun

Thank you Brad for adding cuda 11.2 support. This PR looks good to me. I don't have any compatibility issue with cuda 11.2 in mind at the moment.

@medb this has been consistently failing over the last couple of days due to zonal resource issues. Any suggestions, or do we just need to wait until resources free up?


Compatible Win 8.1 and WP 8.1?

Hello
Is it compatible on old Win 8.1 and WP 8.1?
Because I get this error message when I use it:
"This functionality is not implemented in the portable version of this assembly.  You should reference the NuGet package from your main application project in order to reference the platform-specific implementation."
Regards

I only support UWP and above


[Bug]: Script not working with "Shorts reels" section.

Describe the bug
Script is not working for shorts reels section when hit the small screen.
Screenshots

Fixed:
https://github.com/sapondanaisriwan/youtube-row-fixer/blob/04d8167654f89f650e65565ef12721f719e54e13/src/content-scripts/inject/main.js#L52-L61


[Feature Request] Add an option to the rename rom to datomatic match

Just found this tool and it's really cool.
One option I'm missing, for example while running the validate command, is to rename the rom file to match the filename found in the dat file. This will help a lot while "normalizing" a rom library.
A more detailed description of the flow would be:

Validate the rom against the datfile
If a match is found check if the rename option is enabled
if the rename option is enabled check if the current rom filename matches the one from the datfile match.
If the filename doesn't match, rename the current rom file to match the one from the datfile.

e.g: rom64 validate --rename
Same option could be available for the convert command as well.
What do you think?
Thanks

Hi there! I'm happy someone is finding this tool to be useful :)
Thanks for getting in touch with a suggestion. I think the idea makes sense and I'm having a look at a clean way to do it. I need to review the datomatic file more to see if there can be duplicate names for hashes, and come up with a sensible way to deal with file naming conflicts.
But like I say, the idea is a good one and I'll be looking into it!

The tool is not only useful, is brilliant. The perfect fit for a script to normalize a big rom collection.
I wish I can find the same for other systems, like NES, SNES, Megadrive/Genesis, etc.
Keep up with the good work.

I was working on a new more generic tool that is multi-platform. I decided to do that one in Rust as a learning project, so it was taking a long time. I might get back on it. I did have the basics of a couple platforms working though.
Give this version a try and see how you like it :) https://github.com/mroach/rom64/releases/tag/v0.5.4

Works like a charm!
BTW I will keep an eye on https://github.com/mroach/romboss. :)
Keep up with the  good work.
Thanks


Improve frameless window on windows

Some changes to the frameless window on windows, reducing the resize artifacts and the behavior is more simular to electron.
Added a wrapper function for GetSystemMetric since it ended up being called a lot

Played around with this a bit in a VM and wasn't able to really see any visual difference with master, but I'm also not very sure what I should be looking for. Is there anything in particular I should do to test this?

The difference here is pretty smal.
The master version have 3 colored edges on left right and bottom side (something that was not visible to me originally until i played around with theme/effects settings in windows) this gets rid of those weird edges.
The other thing is resizing, and there is a few different things here: (This could potentially be different on other systems?)
Using PresentStrategy::Sequential mode with present_after = 1, ie waiting for vblank removed all resize artifacts with titlebar visible / normal mode, and made resizing seem a lot less "jiggly" in borderless mode.
In borderless mode the best option might actually be to use PresentStrategy::Flip and call handler.prepare_paint() inside WM_SIZE after the handler.size() call, atleast that gave very nice results on my system. I could update the PR to use this mode in borderless, unless there is some reason we want to avoid using Flip and/or not call prepare_paint() in WM_SIZE ?
I tried to make some recordings to show the resizing differences but the recording software was not good at capturing it, I might try some different software later

@rhzk I've invited you as a collaborator on the druid repo, so feel free to merge your own approved PRs and also to provide approving reviews of others' PRs in circumstances where you feel comfortable doing so. :)

Thanks for the invite @cmyr. I will let this PR simmer a bit more, just in case I might realize a better or simpler way to do something or something I missed.

sounds good!

@cmyr @rhzk I would suggest merging this, because we won't get any data on its effects until then, and we can always reverse it out later if there are problems.


The messenger window sometimes doesn’t work.

Thanks and noted, it is a peer-to-peer messager, so you need to connect to peers before messaging.


Add negation of expect_path to testdir

I want to assert that a testdir does not have a particular file in it, but I couldn't figure out how to do that with the data that is publicly available the the testdir API.

Please feel free to add an expect_not_path function (or something with a better name, if you can think of one).
Also, if you're working on my Rust subtitle code, you might enjoy trying:

Switching to nightly Rust. For this, you need rustup, and then run rustup install nightly (once) and rustup override set nightly (in each project's top-level dir).
Installing the Rust Language Server.
The open source text editor Visual Studio Code (not to be confused with Visual Studio).
The Rust add-on to VS Code. Type Control-Shift-P and type ext install rust, or look up the "Rust" extension in the GUI.

This will give you a SublimeText-style editor, but with extensive Rust integration, including completion, pop-up documentation, and the ability to mouse over a variable to see the inferred type. I find that it makes Rust development go surprisingly quickly and painlessly.

expect_no_path might be better?
And feel free to add expect_does_not_contain as the opposite of expect_contains. There is no useful opposite for expect_file_contents, contrary to what I might have mentioned earlier. :-)
Once you've added these and anything else you need here, I'll make a new release.

OK, I'm going grab this issue and implement the new methods. (I want them for another project.) Just letting you know so that we don't both work on them. :-)

OK, I've added the new APIs in 0.1.3!


Support for dynamic metadata

This is a patch to support metadata key/value pair which returns a dynamic value. This is to provide functionality akin to Python's LoggerAdpator

Metadata can either be provided at compile time via the parse_transform or per-process when added using lager:md/1.
Metadata functions are only evaluated on message emit
By default there is no change to existing behavior, except in the case of somebody wanting to log a function reference without converting it first, e.g if you wanted to see #Fun<module.function.arity> in the logs, however all tests currently pass
Have written some tests to ensure the correct behavior of this new behavior

If you don't use this functionality there should be no noticeable effect on performance.
The only places where it has an impact will be in the formatter when trying to resolve an atom in the configuration which has to make a call to get_metadata. The function now has to evaluate a guard before falling through to the next case.
Doing some basic tests of performance, doing lookup on the old and new get_metadata 10 million times takes about 3.9 seconds for each of them, with the new function being about 0.02 seconds slower on average, with 0.08 seconds being the worst and -0.02 being the best I saw.

Thanks. We will discuss this change during our monthly triage session - scheduled for March 16, 2200 UTC (1400 US/Pacific)

Hi @mrallen1, I've had to push another change, as I've just discovered a race condition.

Logger Process logs a message
Lager Process transmits message through to the backend async and returns
Function Process dies
Lager Backend Process starts formatting message, can't resolve the function as the function has now died.

The change I've pushed is to allow the function to be resolve at log or on emit (and you can specify per function). While resolving on log won't completely eliminate this race condition, if the Logger Process and the Function Process are the same process/app then it should reduce it. I've updated the README with the consequences, advantages/disadvantages of either.

Hey - thanks for the PR. We discussed it today and have a few questions:

What's the use case for this functionality? Can you give a scenario where its useful for you?
Why does the function not accept the metadata lager already injects (like pid, line number, etc)

Would it be possible to use the lager:md/1 functions to achieve similar ends?

Hi @mrallen1
Thank you for taking the time to look at the pull request.
Our particular use case for this functionality is tracing calls across systems. For the Erlang parts we are attempting to use sequential tracing to trace calls through various Erlang apps, so that when we log messages information relating to the call being traced is included.
E.g. In our output log we can have this sort of format
2017-03-17 10:00:00.000 app1 <trace id 1> INFO
2017-03-17 10:00:00.001 app1 <trace id 2> INFO
2017-03-17 10:00:00.002 app2 <trace id 2> INFO
2017-03-17 10:00:00.003 app2 <trace id 1> INFO
If we had unlimited time we would integrate this with something like Zipkin, however in the short term it is unlikely.
Initially we looked at using lager:md to store the information, however the nature of sequential tracing would require us to call lager:md in every message handler that might directly or indirectly log a message, and also after we receive any reply message (e.g. by directly or indirectly invoking gen_server:call). This proved to be somewhat onerous and error prone, and having lager automatically call a function as part of logging seemed like a cleaner solution. The particular function we are using queries the sequential trace label for the calling process, and uses this to look up trace information to be added to the log message. This is why we had to define the on_log | on_emit syntax for the transform since the trace information could be gone by the time the message was emitted by the backend, and so needs to be queried at the point of logging.
As for why the function doesn't accept the other populated values - we hadn't considered it as it wasn't required for our use case, however we can't think of any reason why it shouldn't.

Just bumping this as reminder to discuss during the next monthly triage session

Thanks for the bump.
We did discuss it today and I did merge it onto a local branch to play around with it.
Would you please extend your write up in the README to include some examples of the kind of output the on_emit and on_log functions should generate?
I see in the test you're using a literal atom as an example of static data and in the other test function you're using monotonic_time - I think the feature write up in the README would be a lot clearer if you would put in some good examples and illustrate why someone might want to use this feature.

Bump on this? Are you still interested in merging this?  Thanks.

Hi @mrallen1, yes I'm still interested. I'll have some time soon to work on updating the README.

Great, thank you!

Thanks for the update!


[fix]: single line comments with # || tippani, multiline comment with…

New Pull Request

[x] Descriptive Comments
[x] Format for pull request [type]: Description
[x] Bug free code
[x] Easy to understand language

#3 Solved.

tippani This is a single line comment for Bhanai Language
# This is a single line comment
"""
This is
a multi
line comment
"""

for single line comments, either you can use # or tippani keyword.


Check Catenax-ng links in all repos

Issues have been created for all repos. example https://github.com/eclipse-tractusx/sldt-digital-twin-registry/issues/460

PRs raised:
https://github.com/eclipse-tractusx/sldt-digital-twin-registry/pull/463
https://github.com/eclipse-tractusx/sldt-semantic-hub/pull/292
https://github.com/eclipse-tractusx/sldt-discovery-finder/pull/164
https://github.com/eclipse-tractusx/sldt-bpn-discovery/pull/163

@agg3fe : Can we close this issue?

yes this can be closed.


docs: new toctree

This is a proposed new totree that uses more the potential of the header bar of pydata-sphinx-theme. All the previous documentation has been moved to "legacy" and will be empied as long as the other sections get filled.
The main objective of the PR is to discuss the structure and also to create the placeholders of each documentation folders to avoid merge conflicts.

Is there a way to redirect the URLs of the old page to the new location in RTD? We have links on github and stackoverflow we don't want to break. Also, for google indexing it's not good that pages which have a good rank now disappear.

Usualy I have 2 builds on RDT: "stable" and "latest"
if your link is not refereing any specific branch i.e. https://ipyvuetify.readthedocs.io/ then it will point to the default stable.
If it's specified "https://ipyvuetify.readthedocs.io/en/latest", then it's too late and I need to code faster

master is already relying on pydata-sphinx-theme but readthedocs latest is still pointing to rdt-sphinx-theme (default). So for a reason I cannot explain (as visitor cannot see the RDT parameters) it seems latest is not pointing on it.

yeah, see: https://github.com/widgetti/ipyvuetify/pull/238#issuecomment-1693383967. I pointed RTD back to a commit with the old theme, because you were not ready.
But what I mean regarding this PR, we should break URL's already used in the world by moving/renaming pages.

This plugin looks like it would work for adding redirects fr the old URLs: https://pypi.org/project/sphinxext-rediraffe/

now I get your point, and then yes rediraffe is the one to go (I think they use it in matplotlib). should I code it in a following up ?

It can be done after we agree on the re-arranging of pages and the new structure is implemented.

Would you want me to fill the different sections in this PR? I wanted to keep the scope of my PR reduced (as you suggested) so until this one is merged I cannot move on with the documentation update.

Hi @12rambau, I'm not exactly sure what you are trying to accomplish with this change. We are pretty happy with the structure as is. I also like the main page to be a short summary an image like you made in the previous PR: https://ipyvuetify--277.org.readthedocs.build/en/277/index.html. The main page in this PR is just a tree of text.

I'm setting the headers in the top navbar.

I would like to split the current documentation bewteen "getting started" and "advance usage".
In advance usage I would like to add a widget composition example using class.
In the currently empty gallery section I would like to copy/generate real-life examples from the one in the Vuetify examples using ipyvuetify syntax.
The api section will be created automatically by autoapi when it is merged (I'm waiting for https://github.com/readthedocs/sphinx-autoapi/pull/399)

Oops.. I wanted to check what the docs in master Iooked like and thought that was the last merged PR.

my branch is again conflicting with main, @mariobuikhuizen, @maartenbreddels could you provide insight on what I should be doing to move forward?
As you requested I'm making as small PR as possible but without them being merged/reviewed I simply cannot move forward.

Let's first see which new content is added, then see if and how we need to change the structure.


0.2.10 Blows up on Ubuntu during NPM Update

Tested on OSX, and this does not do it there.  Just Ubuntu.
Also tested intalled via NPM version 0.2.9 on Ubuntu and it works as usual.  Anything you might have done in the last release to cause this?

Here's the error:
  npm ERR! Failed unpacking /home/app_folder/.npm/jsdom/0.2.10/package.tgz
  npm ERR! error installing<EMAIL_ADDRESS>Error: `tar "-zmvxpf" "/home/app_folder/.npm/jsdom/0.2.10/package.tgz" "-o"`
  npm ERR! error installing<EMAIL_ADDRESS>failed with 2
  npm ERR! error installing<EMAIL_ADDRESS>   at ChildProcess.<anonymous> (/usr/local/lib/node_modules/npm/lib/utils/tar.js:219:20)
  npm ERR! error installing<EMAIL_ADDRESS>   at ChildProcess.emit (events.js:67:17)
  npm ERR! error installing<EMAIL_ADDRESS>   at Socket.<anonymous> (child_process.js:172:12)
  npm ERR! error installing<EMAIL_ADDRESS>   at Socket.emit (events.js:64:17)
  npm ERR! error installing<EMAIL_ADDRESS>   at Array.0 (net.js:837:12)
  npm ERR! error installing<EMAIL_ADDRESS>   at EventEmitter._tickCallback (node.js:126:26)
  npm ERR! Error: `tar "-zmvxpf" "/home/app_folder/.npm/jsdom/0.2.10/package.tgz" "-o"`
  npm ERR! failed with 2
  npm ERR!     at ChildProcess.<anonymous> (/usr/local/lib/node_modules/npm/lib/utils/tar.js:219:20)
  npm ERR!     at ChildProcess.emit (events.js:67:17)
  npm ERR!     at Socket.<anonymous> (child_process.js:172:12)
  npm ERR!     at Socket.emit (events.js:64:17)
  npm ERR!     at Array.0 (net.js:837:12)
  npm ERR!     at EventEmitter._tickCallback (node.js:126:26)
  npm ERR! Report this *entire* log at:
  npm ERR!     <http://github.com/isaacs/npm/issues>
  npm ERR! or email it to:
  npm ERR<EMAIL_ADDRESS>  npm ERR!
  npm ERR! System Linux 2.6.32-33-generic
  npm ERR! command "node" "/usr/local/bin/npm" "install"<EMAIL_ADDRESS>  npm ERR! cwd /home/app_folder/deploy/jsdom
  npm ERR! node -v v0.4.11
  npm ERR! npm -v 1.0.103

looks like you have a couple options here

upgrade node to 0.6.x (which includes its own robust tar implementation)
upgrade tar on ubuntu

closing for now, if these options don't work please reopen

Ah - OK.  Sounds good.  Thanks Elijah.


chore: replace convex_style with aineko_style

Not sure I understand this PR, what changed that necessitates this?

We will transfer ownership to aineko-dev and open source that repo.


Generated pom.xml does not include selected dependencies

I selected RestEASY JSONB, H2 JDBC, and Hibernate ORM with Panache extensions and downloaded/unzipped code-with-quarkus.zip. The pom.xml did not include the selected dependencies.

Found the bug, Created the failing test, just have to fix it.. 👍


Component: Masthead: Accessibility - issues related to hamburger menu once it is expanded

Detailed description
Issues :-

Close icon - screen reader is reading the label as open menu button
After expanding the Hamburger menu visually there is close button, IBM logo link and the options but screen reader is reading content which is not visually available.
For example user profile and search edit combo box.

Issues on Web components :

Hamburger menu - There is no label for the hamburger menu, , screen reader is announcing as button without any label.
IBM logo link - screen reader is announcing the mentioned control as  " link " and is not operable.

Expected :-

Give appropriate label.
screen reader should not read visually hidden components

Expected results for web components :

Provide a descriptive label , a generic example would be  "side Navigation"
screen reader should announce appropriate label/ link text. Make the logo operable.

Additional information

@kennylam I am closing this bug based on the MegaMenu discussions in the 7/13 QA meeting.


"Argument required: Bundle"

Pulling latest head results in a slew of the error "Argument required: Bundle" being spat out upon processing my bundle config file. Moving back to the commit (06088de2) prior to "Allow comments after Bundle declarations" (d840b240) causes the error to cease.
Mac OS X 10.6
MacVim 7.3.53
Using https://github.com/edgecase/vim-config

@gmarik wow man, the fact that double quotes can't be used is pretty counterintuitive.  It'd be great if there was at least a warning.  I hit this and spent about an hour trying to figure it out.
Thanks for the awesome plugin!


[B108:hardcoded_tmp_directory] Probable insecure usage of temp file/directory.

bandit reports:
Issue: [B108:hardcoded_tmp_directory] Probable insecure usage of temp file/directory.
   Severity: Medium   Confidence: Medium
   CWE: CWE-377 (https://cwe.mitre.org/data/definitions/377.html)
   Location:
      ./run_kraken.py:
         29 :     with open("/tmp/kraken_status", "w+") as file:
      ./server.py:
         22 :         f = open("/tmp/kraken_status", "rb")
         37 :         with open("/tmp/kraken_status", "w+") as file:
         43 :         with open("/tmp/kraken_status", "w+") as file:
         49 :         with open("/tmp/kraken_status", "w+") as file:
   More Info: https://bandit.readthedocs.io/en/1.7.4/plugins/b108_hardcoded_tmp_directory.html

Usage of /tmp/kraken_status was added in pr #158. @paigerube14 if I get it right you want to record RUN, STOP, PAUSE events and send the logs over HTTP when a GET request is coming for / path.
Do you really need to store the log on disk? Could it be stored in an io.StringIO memory buffer instead?

@sandrobonazzola how did you get that security output? Should we add that as a github workflow so we can more readily catch errors like this

closing with PR being merged


art - exception if generator response is empty

avoid exceptions from empty generator responses in ART
  File "/opt/drop/Dropbox/dev/garak/garak/probes/art.py", line 101, in probe
    response = generator.generate(challenge)[0].strip()

this is now the "constructive tension" functionality in art/atkgen


Improvement: Remove pubspec.lock

According to Google Dart guidelines:  > For library packages, don’t commit the pubspec.lock file. Regenerating the pubspec.lock file lets you test your package against the latest compatible versions of its dependencies.https://dart.dev/guides/libraries/private-files#pubspeclock In that sense, since DragAndDropLists is a package, pubspec.lock should be removed

Thanks for noticing that @freitzzz !

Thanks for noticing that @freitzzz !

Np :)


feat: wilderness-level-indicators added

New plugin intended to highlight players in the wilderness within the same combat bracket.

Goes against Offers additional information about other players, with the purpose of scouting PvP targets


Feature: Decorate classes without @Decorators.

If I have existing models that are used in other apps not requiring type-graphql or graphql at all, it'd be nice to be able to decorate those without wrapping them.
Lets say I have:

/** @org/db/Doc.ts */
interface Doc {
    _id: ObjectId;
    createdAt: Date;
    updatedAt: Date;
}

abstract class Document<T extends Doc> {
    public doc: T;

    constructor(doc: T) {
        this.doc = doc;
    }

    get id(): string {
        return this.doc._id.toHexString();
    }

    // ...
}

/** @org/db/User.ts */
interface UserDocument extends Doc {
    name: string;
}

class User extends Document<UserDocument> {
    get name(): string {
        return this.doc.name;
    }
}

/** @other/graphql/___.ts */
import { ObjectTypeDecorator } from 'type-graphql';
import { User, Document } from '@org/db';

const documentDecorator = new ObjectTypeDecorator(Document);
documentDecorator.field('id');
documentDecorator.field('createdAt');
documentDecorator.field('updatedAt');

const userDecorator = new ObjectTypeDecorator(User);
userDecorator.field('name');

// can now use "User" as a type throughout.

Interfaces doesn't exist at runtime, so we have absolutely no type metadata available 😞
Maybe you should write your code generator that will convert the interfaces to classes with decorators? 🤔

The above code example is classes backed by interfaces.  I want to use type-graphql on existing classes without having to wrap them to get the fields, etc.

@j
You can call the decorators manually, like in transpiled code:
class User {
  name: string;
};

ObjectType(options)(User);
Field({ nullable: true })(User.prototype, "name");

I don't want to expose utils like ObjectTypeDecorator as it's against TypeGraphQL goal to define classes with decorators to produce GraphQL schema.
In my production apps I just use the shim and the decorators on unrelated classes like RegisterFormState :wink: I can share the form state, input type shape and typeorm entity at once 😉

Mobx has an interesting approach, https://mobx.js.org/best/decorators.html. Maybe that approach would work for you?

@cramhead that's pretty dang cool.  It's sort of what I was thinking originally.
I've since moved my models to my graph layer and with apollo federation coming soon, will be moving every model to it's specific service.  Originally we had models and repositories in their own package and I wanted that library to be unaware of type-graphql and to just decorate the classes after the fact.  I ended up not doing this though, but the Mobx approach looks pretty cool.


Automated Freelancing Service

Project Details
How would you describe your project?
Discord server with a custom bot that manages freelancing orders. We will use Discord's brand new shiny slash commands.

/ticket will create your own ticket channel called #ticket-yourname
You will then select the service you want from the list and enter a description of what you need
Approved freelancers will be able to pick up your project and join the channel, ask for more info etc
The assigned freelancer will use /invoice <amount> to request TNB payment from you (to an escrow wallet for new freelancers or directly to the freelancer's wallet for established freelancers)
The #ticket-yourname channel will live as long as needed, until a the freelancer uses /close (we will keep old channels for 7 days)

What problem does this project solve?
Super easy work requests.
Who is the target market?
Anyone who needs work done: art, consulting, everything.
How will this project benefit the network and/or the community?
Need graphics? Advice? A website? Github issue solution? This service will offer reliable, timely and consistent services.
How is this project centered around thenewboston?
We only accept TNB as payment.
What is the estimated completion date for this project? (rough estimates are acceptable)
May 4th 2021
Please include a detailed roadmap for your project below. This must include a list of all milestones where payments will be awarded upon completion of each.
1. April 10th
Initial setup and hiring.
2. April 20th
Create, install and set up the open source ticket management bot.
3. April 30th
Improve the ticket management bot.
What is your Discord username?
Pixel#5000
Milestone Details
Setup
Set up Discord server, legal Terms & Conditions and recruit 1-2 freelancers for each category: graphics, web development, Discord bot development, financial consulting, project management, community management, marketing, promotional material
Requested Payment Upon Completion
13,333 TNBC
Bot

/ticket  - Creates a new private ticket channel with the current user
/claim  - Claims the ticket for the current freelancer and adds them to the channel
/invoice  - Prints an invoice in the current ticket channel
/close - Closes the current ticket channel, marks the task as done and releases escrow'd funds to the freelancer (deletes channel after 7 days)
/refund - Refunds the funds in the escrow wallet to the customer

Requested Payment Upon Completion
23,333 TNBC
Milestone Description

Allow customers to submit reviews via the bot into a public #reviews channel
Freelancers' will have statistics that will be displayed when a freelancer accepts a job (jobs completed, average ratings)
/close <1-10 rating> [text] - Closes the ticket & submits a review (star rating anonymised, average will be visible after 5 orders and updated every 5 orders)
/prefer @freelancer - Mark the current freelancer as the preferred freelancer, allowing them to claim the tickets by that customer before other freelancers can

Requested Payment Upon Completion
23,334 TNBC

#
Objective
Estimated Value (coins)

1
Set up Discord server
500

2
Terms & Conditions
5,000

3
Freelancer agreement & recruit 10+ freelancers
4500

4
Set up Discord bot code
1000

5
/ticket
5000

6
/claim
5000

7
/invoice  & /close & /refund
10,000

8
/close <1-10 rating [text] & display statistics on ticket claim
10,000

10
/prefer @freelancer
5,000

11
Expert financial advice throughout the project (split into 3 milestones)
10,000

what is the estimated time needed for each objective? (in hours)

@angle943  The times are calculated at 1000 TNBC / hour. Most of these things will take at least 2-3 hours (code, structure, tests, deployment etc) and of course for software engineering you have to at least double the estimates.

Hey @Kycermann, the government reviewed and we think this is an awesome idea. One change we would like to request to the proposal, for legal reasons can you please remove all mentions of "USD" in your milestone descriptions?
Also we did have one question for clarification, this project/bot would be hosted on a Discord server separate from the main thenewboston server, is that correct?

Hey @buckyroberts, all done. I was planning to have freelancing/services in a seperate server- but I'm more than happy to set it up in the official one!

Hello @Kycermann , we approve this project. We have decided upon 50000 coins upon the completion of this entire project (as one milestone).

Hi, apologies for delays. I'm working on it and it'll be ready soon :)

How can I contribute to this project?

If you'd like to help with finding freelancers and moderation, add my Discord- Pixel#5000. Cheers!

@Kycermann, please submit a milestone payout request for this project: https://github.com/thenewboston-developers/Projects/issues/new?assignees=&labels=Milestone+Payout+Request&template=milestone-payout-request.md&title=NAME_OF_PROJECT+-+NAME_OF_MILESTONE+-+MILESTONE_NUMBER

Approved for 50k TNBC.


Composer save: fallback to use saved parent page ID

Let's assume that:

we are creating a page via Composer
the page type has Publish Method set to Choose from all pages when publishing
we set the page handle in the Page Settings -> SEO panel
we set the parent page in the Page Settings -> Location panel

Currently, when we try to publish the page, the parent page ID is only retrieved from the page type or from a cParentID post field, but not from the currently saved data. This causes the inability to publish the page since the parent ID set in the Location panel is not retrieved: let's retrieve it.

Pull request updated