How to style vespene?


#1

I really like the minimalism of vespene but ultimately I'd want to style it a bit. I saw you have a collection of *.css and *.min.css files in /vespene/static. Do you have a preferred way of compiling them? Would you consider adding a "custom.css" and link it in theme.j2?

I've already started experimenting with what might work and what is probably a bad idea. I'd like to try doing these things as close to the original codebase as possible, to see if anyone else thinks they are a good idea. Have you though about a styleguide or how you'd be willing to accept CSS PRs?


#2

Hi @muki,

Awesome!

Yeah what happens is those static files are served up by the "whitenoise" module, so when you change them you have to do "make collectstatic"

Pretty much any changes are fair game, including introduction of something like less/compass/whatever (whatever is the best these days?) as well as changing any of the *.j2 templates which power the view.

I do realize we need to include more about how to work on these in the development setup guide.

I'd like to keep the red/white/black colorscheme for the most part but I'm generally up for all kinds of upgrades, including introducing better presentation frameworks.

Right now I am using bootstrap3 because of compatibility with Django crispyforms (a template library that allows better tabs and so forth than normal) - their support for bootstrap4 did not work perfectly well with all widgets.

The other thing I eventually want to do is make a better editor widget for JSON fields that ensures the JSON remains valid or otherwise at least highlights it, as well as probably making the build script and build output panels larger and better formatted.

In any event, this is a part of things I never had a lot of time to get into, so I definitely look forward to learning from those that know a lot more about these things.

I have been thinking about it alot, and the only thing I don't really want to do is introduce something like Angular/React, which while very impressive, could become fragile or cut down on contributions. Keeping it a multi-page, template driven app has proven really good for development.

Finally, I'd just say (this goes for anything) if you have any ideas that you think you might not be sure about if they'd be good, or want some feedback, or want to know what something does - asking prior to submitting a PR can sometimes avoid having to rework some bits.

(The CSS now is just in vespene.js, if that ends up being a product of the build environment it is probably easiest if we just checkin the results to avoid people needing to install the npm toolchain stuff?)


#3

Thanks for the thumbs up on this. I haven't done much yet, but I'm very interested into working through this. For now, I only did one thing of consequence. It's not pretty but substantially improved my experience - I replaced the script editor TextArea with an Ace plugin (just changed the DjangoWidget). Still didn't make it "disabled" on builds so I won't PR it, especially since I think I'll need to PR the Django Ace plugin before this works.

I did some research into how to best add CSS preprocessor capabilities to the project. With some of our previous Django projects we would compile SCSS and JS with Javascript (npm tooling and such) which I never liked, at least not in the way we implemented it at the time. But since here we'd only really need CSS preprocessing would you be willing to use an extension like this to manage styles?


#4

That editor looks GREAT

I don't know about the sass processor but my gut tells me there's too much automagic there.

My personal preference would be to pick something up that has really widespread use for even non-Python developers, to open up development for frontend developers who didn't know python yet.

We could make sure it was well explained in the development guide.

I know it's not super automatic having that build step, but it might be more transparent if something went wrong, and I like to keep dependencies low so there are less things to break.


#5

It looks very automagical to me as well now that you mention it. And I totally agree with the stuff you say after that, especially about non-python devs.

The only thing still bothering me is the fact for most of the frontendy stuff you'd need a node installation to run npm and stuff. And I'm not sure installing node on a machine in the same way we install python is the best practice here, so that starts to look complicated to me.

However, if the indended changes are going to be purely CSS it's simple to keep a simple script you run after you're done that runs a standard sass compiler. It can even be as simple ass sass style.scss > style.css (where style.scss includes all the things). But if there are any plans on fancy JS stuff then this won't cut it.


#6

I don't think I'm going to be introducing too many Javascript things.

While I would like to learn them, I think that sets too high a barrier to entry, so we are probably going to stick to just basic jQuery and a few useful libs. By this, I mean I don't predict we'll ever be building from typescript.
That opinion may change though.

One example of something more advanced is the current homepage goes to "/projects" and I want to build a dashboard of all the recent builds (last 10), any projects with failures, and so on. If I were to paginate those widgets it would really require something more advanced. Or I might NOT do that right away but still do something basic with something like d3.js. (Tangent: the REST API will be coming, this is something I originally had in and largely working but removed it so I could focus, knowing it could be added back quickly once the object model settled down).

My suggestion for now is we check in javascript and CSS build products so we don't require people who are doing installs to do frontend build steps, but we do require it for front-end developers making changes there and we put that in the development guide.

I think it's ok to get those kind of development tools from npm or wherever.

Sound good?

ALSO: please do send me the code for that awesome editor :)


#7

Yup, I'll try to have something by next week, we're in the middle of a launch so I hope to get round to something presentable during the weekend or soon after that.

As far as the editor is concerned: I tried to mess with the code as little as possible. Everything is in these two commits, and the second one is just setting the syntax highlighting style. I put the CSS directly into the template because I wasn't sure where to put it which in turn triggered this conversation.

  1. https://github.com/danesjenovdan/vespene/commit/47dda197d6f95acdfba3f8a27b4671a4d5994472
  2. https://github.com/danesjenovdan/vespene/commit/8e4888042a5799452fef7950e813950dc9c25430

#8

That's super clean, wow! Also, no problem!

Looks like the ace editor css can go in vespene.css but that's the only thing I'd really change other than removing the comments and commented out old stuff.


#9

Hi @muki,

If you've like to send me a pull request for the above I'd be glad to get this merged in. Alternatively, I'm happy to manually try to apply your changes myself on a branch and fix the attribution in git. Let me know.


#10

Sorry, I've been out of the loop these past couple of weeks. I'll make sure I have a commit packaged for you by the weekend (currently the script editor is not "disabled" when viewing a past build if I display the fancy editor). Me pulling and trying to install the latest from master was the necessary intro into this.


#11

Awesome - yeah - no rush!