Skip to main content
Responsive Theme Started by TE · · Read 29803 times 0 Members and 1 Guest are viewing this topic. previous topic - next topic

Re: Responsive Theme

Reply #15

Oh goody. ;D TBH I think shipping with one good light (default) variant and one good dark one would be best, for a vanilla package. Some people can't handle light themes (migraines etc) but most office environments require a light theme. One of each would cover all bases.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Responsive Theme

Reply #16

Oh and since Norv is refactoring the back end into something totally unrecognisable, I think the front end could benefit from a moderate amount of something similar. It would be much easier to build a clean front end if not worrying about inherited SMF 2.0.x crud. That's how I was able to get my other theme so light on CSS: I was able to build the interface using only what was needed.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Responsive Theme

Reply #17

yep, agreed.. the front-end needs refactoring, too.. I've suggested that a few weeks ago..
http://www.elkarte.net/index.php?topic=354.0
Don't know if we should do that before Elk  is going 1.0 final, it's a lot of work and would delay the relase date ... (Elk shouldn't go Vaporware, IMO)
Problem is, we'd need developers in order to help... Interested?  ;D
Thorsten "TE" Eurich
------------------------

Re: Responsive Theme

Reply #18

As long as I don't have to use GitHub. :P

Seriously, if I have to pig around with that thing a) it'll waste time and b) make me grumpy. That means a) less time for coding and b) I'll decide there are other things I can do that are more fun. I just know this will happen. Been there before.

If you just want me to write code, that's not so bad. Writing code I can do.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Responsive Theme

Reply #19

Here's an alternative: use SVN with the repositories, and yet participate to a similar workflow as we do:
https://github.com/blog/1178-collaborating-on-github-with-subversion
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: Responsive Theme

Reply #20

Sorry. That looks like more GitGibberish and more trouble. I'll wriite code. I'll post code either here or in the GitHub issues chat thingy. I'll attach files anywhere you like, and download files from anywhere you like. I will not use Git itself. Just wont. Not interested. If that's required, you'll have to ask someone else.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Responsive Theme

Reply #21

Have you read it? It's SVN. It's that SVN thingie of yours. I have searched for it specifically.

You are welcome to write code and/or attach files if you want. Just please note there's no guarantee we can get to all of them, not because we don't want to, but it makes things time consuming. At least try to submit small and consistent changes, please, and keep your repo/installation updated. Last times we have tried that, there were many changes in batches - very hard to merge. The pace of github is usually very fast, and we have quite some work to still do.
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: Responsive Theme

Reply #22

Ok, well in that case it may be less annoying for everyone if I don't get involved too much. I'm really going to want to rewrite most of the front end anyway, just to get markup and CSS down to saner levels, apart from anything else. With the other stuff I've got going on in life, that's not going to be a quick process. TE wants to skip it as much as possible, just so you can get something out the door. I'm sure the basic software will be perfectly competent for a first version, however you release it.

The one thing I would suggest is some a11y improvements for the drop menu system, and other collapsible elements. I can give you those sometime in the form of easy replace/paste code for the templates, if TE doesn't have time to look at it. Also happy to give an opinion if you want front end bugs thumped later.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Responsive Theme

Reply #23

That sounds great, thank you! :) Feel free to play around with stuff, that's what we're doing after all.

"Rewrite most of the thing" is not a bad thing per se, don't get me wrong there. We have already been doing just that on some core components, and - some silly bugs apart - the thing works, and looks better on the inside. (lol) Because, we try to do it in small or manageable and always-working chunks, even backwards compatible. (where possible)

But, anyway, my hope is that for themes we can make things easier for custom theming. You know, like as easy as possible to make, update, not be too bothered by them mods, stuff. I'd have another suggestion too, here (please shut it if inappropriate): make a custom theme per your liking, and grumble at anything which makes it difficult or bad.
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: Responsive Theme

Reply #24

Ant, I would personally love to help you on this. If you want to post files, go forth to your hearts content. I will help move your code into my repo, and merge into elkarte repo's if you want. I'd suggest starting another topic. I'll find it, mark it as notify for me and try to keep tabs on it.
Success is not the result of spontaneous combustion, you must set yourself on fire!

Re: Responsive Theme

Reply #25

Quote from: TestMonkey – That sounds great, thank you! :) Feel free to play around with stuff, that's what we're doing after all.

"Rewrite most of the thing" is not a bad thing per se, don't get me wrong there. We have already been doing just that on some core components, and - some silly bugs apart - the thing works, and looks better on the inside. (lol) Because, we try to do it in small or manageable and always-working chunks, even backwards compatible. (where possible)
Umm, yeah. Small and manageable and backwards compatible is no fun at all. :P I like coding like a wombat digs burrows: stubbornly going in the chosen direction, with fudge nuggets flying everywhere. ;D


QuoteBut, anyway, my hope is that for themes we can make things easier for custom theming. You know, like as easy as possible to make, update, not be too bothered by them mods, stuff. I'd have another suggestion too, here (please shut it if inappropriate): make a custom theme per your liking, and grumble at anything which makes it difficult or bad.
TBH I'm probably not the best person to ask about difficulty. I frequently recode mods slightly before installation, just to suit my presentation preferences, or just install them on the default theme to have the db sorted and then write my own template/css stuff in the custom theme without even bothering to actually install the mod on it. IOW, I've pretty much forgotten what difficult is like, as far as basic front end stuff goes.

That said, I had thought of doing a custom theme at some point. It's a good way to get a feel for the app. I don't expect it to be any more difficult than theming for SMF. Can't see how it would be, so that's ok. Anyway that's better as a seperate, personal project rather than as part of the current dev cycle. I'll try to keep dev suggestions at this stage down to stuff that is easily implemented.

However, a custom theme would probably be a good interface testbed for Elk 1.1, or 2.0 or whatever you're intending to call it.

ETA: Hmm. Had a thought. One ideal test case would be a theme that uses light and dark variants, with completely different accent colours. If anything is going to cause trouble, it'll probably be stuff that makes that degree of css detail within one theme difficult or impossible. This is also a good test case for a default theme, since ideally the app would probably ship with a light theme and a dark one (which would probably be better as variants rather than seperate themes).
Last Edit: June 09, 2013, 01:03:56 am by Antechinus
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Responsive Theme

Reply #26

QuoteThat said, I had thought of doing a custom theme at some point. It's a good way to get a feel for the app. I don't expect it to be any more difficult than theming for SMF. Can't see how it would be, so that's ok. Anyway that's better as a seperate, personal project rather than as part of the current dev cycle. I'll try to keep dev suggestions at this stage down to stuff that is easily implemented.

However, a custom theme would probably be a good interface testbed for Elk 1.1, or 2.0 or whatever you're intending to call it.

It's actually necessary during today - Elk 1.0 stable.

Bloc has already tried to, with not so good results:
http://www.elkarte.net/index.php?topic=353.0
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: Responsive Theme

Reply #27

Oh, that. Well I think that partly comes down to getting a tad ruthless on markup, to get rid of as much shiz as possible. That will help to reduce the amount of css required.

However, the current css is a mess though (mainly coz someone left it like that). It would be a nightmare to work with, because there are conflicting declarations in umpteen places, just because it was WIP and stuff was getting added where it would override other stuff some deranged couldn't be bothered searching for at the time. :D

Once that is rationalised, it shouldn't be too bad.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Responsive Theme

Reply #28

Y'know one obvious place to save css would be buttons. If they're all made the same for special fx then that could be handy. Obviously people could still do custom styling in their own themes just by using the classes seperately, but if you want the simplest default theme then that is one place to start. They could all be listed together by default:

Code: [Select]
.quickbuttons, .main_menu, extra_stuffz {color: purple;}
.quickbuttons:hover, .main_menu:hover, extra_stuffz:hover {color: orange;}

;D
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Responsive Theme

Reply #29

Thinkings again (meh) - a lot of the css crud in the 2.1 files you inherited was down to trying to export that admin centre theme to the rest of the forum without changing 2.0.x markup.

If people were sensible enough to not give a rat's about 2.0.x markup in the admin centre, or about keeping bits of the 2.1 Alpha theme, things could be (lots) simpler. Admin, in particular, ended up being pretty convoluted css just to get that look over 2.0.x markup. It could be done with equally clean looks and less code to run it.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P