Was just looking around 2.1 a bit, and noticed something in the CSS.
/* Let's get a bit more flexibility in font sizes for quotes and code. */
/* We just need to stop em compounding when elements are nested. */
.bbc_standard_quote .bbc_alternate_quote, .bbc_alternate_quote .bbc_standard_quote,
.bbc_standard_quote .bbc_code, .bbc_alternate_quote .bbc_code, .bbc_standard_quote .codeheader,
.bbc_alternate_quote .codeheader, .bbc_standard_quote .quoteheader, .bbc_alternate_quote .quoteheader {
font-size: 1em;
}
It's pretty obvious that whoever was messing around with the coding for bbc quotes and code does not actually know what this block of code was for. How can I tell? :D
Well the code for blockquotes is now this:
/* Blockquote stylings */
blockquote {
margin: 0 0 8px 0;
padding: 6px 10px;
font-size: small;
border: 1px solid #d6dfe2;
border-left: 2px solid #aaa;
border-right: 2px solid #aaa;
}
Font-size: small; is an absolute sizing that will not compound when nested. That's fine if you want that font-size. No problem there. However, the code blocks use font-size: 0.85 em; instead, and of course that is a sizing that will compound when nested.
The whole point of the block of code quoted at the beginning of the post (ie: Line 384+ in whatever RC2+ nightly is on my box) is to stop font-sizing compounding in nested quotes. It even says so. Furthermore, since it uses classes and descendants for targetting it actually overrides your declared font-size for quotes, because that is only declared on the basic tag name.
If you want to use an absolute sizing for quotes then it would make sense to do the same for code (but please, not x-small as people do want to read them). If you are going to do that, then there's no need for additional code to stop nested quotes and code compounding for font-size. The main reason it was put there originally was because at the time IE8 was relevant, and IE8 did not support font sizing in rem. If you want maximum flexibility of font sizing, without any worries about what will happen when elements are nested, rem is the way to go. It's supported by just about anything that is actually in use these days (see https://caniuse.com/#feat=rem if you're worried).
So, suggestion. Ditch this pile of crud:
/* Let's get a bit more flexibility in font sizes for quotes and code. */
/* We just need to stop em compounding when elements are nested. */
.bbc_standard_quote .bbc_alternate_quote, .bbc_alternate_quote .bbc_standard_quote,
.bbc_standard_quote .bbc_code, .bbc_alternate_quote .bbc_code, .bbc_standard_quote .codeheader,
.bbc_alternate_quote .codeheader, .bbc_standard_quote .quoteheader, .bbc_alternate_quote .quoteheader {
font-size: 1em;
}
And use this for blockquote and .bbc_code:
font-size: 0.85rem;
That way they're equally readable and match well, and there are no problems with sizes compounding, and you save a pile of crud in your file. :)
(This tip is provided free of charge because someone might want cleaner code. Ant is too jaded to bother doing the whole GitHub thang and the whole arguing with people about what gets done and what doesn't thang.)
ETA: Just noticed something else:
blockquote cite {
display: block;
border-bottom: 1px solid rgba(0, 0, 0, 0.1);
font-size: 0.9em;
margin-bottom: 3px;
}
There's no need to call rgba transparency there. It's just bloat. This would be just as good for looks and is less verbose:
border-bottom: 1px solid #ccc;
I do hope someone has not been making a habit of using full rgba syntax where a basic hex code will do just as well.
Ok, thanks for the laughs. I just found one of the funniest things I've ever seen, and damned near fell off the chair laughing. :D
.popup_window, #main_menu .popup_window, #genericmenu .popup_window {
position: relative;
z-index: 99;
width: 90%;
box-shadow: 0 3px 6px rgba(0, 0, 0, 0.5);
border: 1px solid #777;
border-radius: 7px 7px 3px 3px;
min-height: 285px !important;
max-height: 5em;
Notice those last two lines. Now tell me they're not hilarious. No sh!t, this is truly awesome stuff. I'm still laughing. :D
The min-height has some use. The max-height is... not going to help.
You're gonna be busy if you start reporting those. Maybe easier to make some PRs.
Quote from: Arantor on September 28, 2019, 12:19:53 PM
The min-height has some use. The max-height is... not going to help.
The bit that had me ROFLMAO was some earnest young munchkin was obviously struggling with this conundrum, wondering why their min-height wouldn't work, and finally had the bright idea of thumping it with !important. Hey, it works now! Yay me!
Quote from: Gwenwyfar on September 28, 2019, 12:28:50 PM
You're gonna be busy if you start reporting those. Maybe easier to make some PRs.
Maybe. Maybe not. Frankly the easiest thing to do would be to rewrite the whole file and just hand over a copy. That way I'd have a good one even if nobody could be bothered implanting the changes in the repo. I won't be doing that this week though as I'm in the middle of something else. I just took a quick look at 2.1 as a bit of an amusing sidetrack.
But if you want to do PR's here's a good one for you: the quickbuttons code is rooted. No keyboard accessibility for most of it. Why not? No href's on the anchors, so there's no way of tabbing to them. This is a very easy fix for the "More.." button. You just change this:
// Handle the sublist
if($key == 'more')
{
$output .= '
<li class="post_options">' . $txt['post_options'] . 'To this:
// Handle the sublist
if($key == 'more')
{
$output .= '
<li class="post_options"><a href="#" onclick="event.preventDefault()">' . $txt['post_options'] . '</a>Straight away you have full keyboard access to the drop menu. Easy. Piece of cake, and y'know what? Back when it was originally coded, it did have full keyboard access to the drop menu.
So that's the "More.." button sorted. The next problem is the Quick Edit button. That has no href by default either, and here's the fun part. Code is this:
else
$html .= '
<a' . (!empty($li['href']) ? ' href="'.$li['href'].'"' : '') . (!empty($li['javascript']) ? $li['javascript'] : '') . '>
' . (!empty($li['icon']) ? '<span class="main_icons '.$li['icon'].'"></span>' : '') . (!empty($li['label']) ? $li['label'] : '') . '
</a>';So just as a test I threw in the same href as I used to fix the "More.." button behaviour.
else
$html .= '
<a' . (!empty($li['href']) ? ' href="'.$li['href'].'"' : 'href="#" onclick="event.preventDefault()"') . (!empty($li['javascript']) ? $li['javascript'] : '') . '>
' . (!empty($li['icon']) ? '<span class="main_icons '.$li['icon'].'"></span>' : '') . (!empty($li['label']) ? $li['label'] : '') . '
</a>';Which should work, but it doesn't. What it does is bork the markup. It puts the correct code in the anchor opening tag, but for some weird reason also outputs the anchor closing tag as this:
</ahref="#">Which is highly inventive, but unfortunately completely screws any semblance of functionality. It's also not at all clear why it is doing this, since there's nothing in the template to indicate it would behave like that. So if you want a juicy bug to get your teeth into, that would be a good one to start with. If you can fix that one, suddenly you'll have keyboard accessibility for the quick edit too (and probably several other things).
QuoteMaybe. Maybe not. Frankly the easiest thing to do would be to rewrite the whole file and just hand over a copy.
Ditto.
QuoteBut if you want to do PR's here's a good one for you: the quickbuttons code is rooted. No keyboard accessibility for most of it. Why not? No href's on the anchors, so there's no way of tabbing to them. This is a very easy fix for the "More.." button. You just change this:
I'm assuming that "you" wasn't
me "you". I'm done with the duct taping.
Wouldn't it make more sense to add a <button>? Since it's an empty anchor, that's more like button territory.
Nothing is stopping you from submitting changes to the repo you know..
Isn't 2.1 in RC2/RC3 phase? Rewriting lots of template code prob. won't be added into main repo until after a stable version is out. Which is anyone's guess..so submitting things that will go in a 2.2 or even 3 version seems kinda ..well, you have to be patient. :)
Although default theme can always be fixed/improved/polished its "done" now, and said efforts might possibly be better spent in doing custom themes....until that time when default theme CAN catch up. Wrong?
Quote from: Bloc on September 28, 2019, 03:10:42 PM
Isn't 2.1 in RC2/RC3 phase? Rewriting lots of template code prob. won't be added into main repo until after a stable version is out. Which is anyone's guess..so submitting things that will go in a 2.2 or even 3 version seems kinda ..well, you have to be patient. :)
Although default theme can always be fixed/improved/polished its "done" now, and said efforts might possibly be better spent in doing custom themes....until that time when default theme CAN catch up. Wrong?
Even before RC any big changes were frowned against, even just for the theme. 2.1 had all sorts of ideas from different people. It was all very debatable.
The theme is "done" but still full of issues. Which at least there is someone working on, now, but was largely abandoned before. It would be a big sham if it's released this way because then every single theme made on it will have to be fixed, instead of it being fixed only once in the main repo. If this was done, everyone could work on a proper thing that is easier to handle.
Agree on that. In the end its up to the team really. It would seem theres alot of issues to deal with so the changes would not be minimal.
Bloc: the issue I suggested is an actual bug, at least IMO. It's also one that (as shown) can be fixed simply by making the offending elements more consistent with the other button in the same strip of buttons. IOW, give them all a href. That's all it takes. They should already be like that, since that's how they started out. What's happened is that someone has written new global code to generate all quickbuttons, which is fine as a concept, but has never give any thought to how anyone other than themselves might want to use the interface, which is frankly pretty slack.
And CSS bugs and bloat in an RC are obvious candidates for fixes, since they don't require any changes in markup or logic.
And not the only one, by far. If you add "general bloat and problems that can be fixed in the css only" that list is quite hefty. Although I haven't been keeping track of what is being fixed since I left the team. I'm hoping the list will be smaller by release.
My gut feeling, based on my recent messing around with a similar situation in 2.0.x default CSS, is that the final version of 2.1 index.css could be shipped at around 60kB uncompressed, with no loss of functionality or looks. In fact it could even look a bit better in some details, while still being the same theme, and would be easier to customise.
From a fairly quick scan and a little bit of messing around, the situation appears to be similar in several other CSS files too.
Yup, sounds like a fair estimate to me.
Quote from: Antechinus on September 28, 2019, 06:46:46 PM
Bloc: the issue I suggested is an actual bug, at least IMO. It's also one that (as shown) can be fixed simply by making the offending elements more consistent with the other button in the same strip of buttons. IOW, give them all a href. That's all it takes. They should already be like that, since that's how they started out. What's happened is that someone has written new global code to generate all quickbuttons, which is fine as a concept..
The code that you are referring to was not there and has not been there for many years, I am the one who wrote the generic quickbuttons template and all I did not remove important relevant code whatsoever, fact is, the issues you mention were there before the generic quickbuttons template was made and are still present now.
Quote from: Antechinus on September 28, 2019, 06:46:46 PM
but has never give any thought to how anyone other than themselves might want to use the interface, which is frankly pretty slack.
So your statement is irrelevant.
One thing that would really help is getting rid of floats as much as is (easily) possible. If things like buttonlists are done with either inline-block or table-cell or flex, then suddenly there's no need to worry about clearing floats or changing float direction for RTL. Inline-block is probably the simplest for a lot of cases since it doesn't require any declarations on the parent. It wasn't an option when 2.0.x was coded, so some of the thinking that went into 2.1 alpha was affected by precedent, and floats got used because everyone knew how they worked.
Quote from: SychO on September 28, 2019, 07:10:22 PMThe code that you are referring to was not there and has not been there for many years, I am the one who wrote the generic quickbuttons template and all I did not remove important relevant code whatsoever, fact is, the issues you mention were there before the generic quickbuttons template was made and are still present now.
In that case, someone removed the href before you got to it. I know for a fact it was there originally. But ok, if you're cool with thinking about how other people might want (or need) to use the interface, then surely adding a href is the sane option here. There's no good argument for
not having it, AFAICT. Why make special cases of those two buttons just to reduce functionality?
No one made a special case of those two buttons, it's just that no one thought of what you are mentioning.
I thought of it, back when I wrote the alpha code. ;) I mentioned that before. They were all marked up the same, except that at the time the quick modify was still using the old separate image as well. If someone fluffed it after that, it ain't on me. And fair enough, if someone fluffed it before you got to it, that particular change isn't on you either.
Anyway, I think it would make sense to have a default href="#" so that all buttons in that class are accessible by keyboard. Offhand I can't think of any cases where that would break functionality, as long as they have the onclick="event.preventDefault()" to go with the href.
It's just weird that the current code for generating quickbuttons screws the anchor's closing tag when you add the href and onclick in what seems like the obvious place in the ternary. That's definitely unusual behaviour. If that bug is fixed, it should all be good to go (and no, I don't know what's wrong with it at the moment, but I suspect it's somehow tied to javascript).
Well, either way it doesn't matter who did what when, I am sure they were trying to do their best, the only thing that matters now is that this was noticed and can be fixed.
It would of course be more of help if you were to post a PR where you submit all your suggested changes since it seems like you are reviewing all of the CSS code, but thank you for the reports nonetheless :)
I posted a fix for a couple of issues, I didn't for the .popup_window element's min&max height because I have plans for that family of elements(https://github.com/SimpleMachines/SMF2.1/issues/5665)
PR: https://github.com/SimpleMachines/SMF2.1/pull/5812
That "fix" will break functionality. It needs to be like this:
<a' . (!empty($li['href']) ? ' href="'.$li['href'].'"' : ' href="javascript:void(0);"') . (!empty($li['javascript']) ? $li['javascript'] : '') . '>
That will work. Yes, I have tested both. ;) Note that it does need the space in front of the href.
While messing with that, I've come up with some better CSS for the quickbuttons. The short version is that putting the styling on the li means no indication on li>a:focus, whereas if you put the styling on the anchor it looks consistent on hover and focus.
Also, it makes sense to put the .quickbuttons and .button code together in the file, because they share a lot of code. At the moment the code for several things is all over the place, which encourages people to lose the plot.
What I've done on local is remove the .button and .quickbuttons declarations that were jammed in with a pile of other things towards the end of the file (around Line 3700 ish), and instead just declare the necessary gradient for .button and .quickbuttons once, where it will be of some use to the average mug who wants to tweak their theme. So the stuff at the end of the file is now like this:
/* Those classes are sharing exact same gradient. */
/* Background of buttons */
.dropmenu li ul, .top_menu, .dropmenu li li:hover,
.dropmenu li li:hover > a, .dropmenu li li a:focus, .dropmenu li li a:hover,
#top_section,
.popup_window, #inner_section {
background: linear-gradient(#e2e9f3 0%, #fff 70%);
}
Which frankly is still a bit silly as it really should be up with the elements it is referring to. The file is severely bloated, but putting that particular declaration at the end of the file does nothing to reduce that. The big gains for brevity are elsewhere. Haven't got that far yet.
Anyway, the new (recommended, looks better and functions better) code for .button and .quickbuttons is:
* Styles for the standard button lists.
------------------------------------------------------- */
.buttonlist, .buttonrow, .pagelinks {
z-index: 100;
padding: 5px 0 5px 0;
margin: 5px 0 5px 0;
}
a.button, .quickbuttons>li>a {
display: inline-block;
padding: 0 8px;
background: linear-gradient(to bottom, #fff 0%, #e2e9f3 70%);
color: #444;
font-size: 0.85em;
line-height: 2em;
text-transform: uppercase;
text-decoration: none;
height: calc(2em + 2em * (0.9 - 0.85)); /* "input" font size minus ".button" font size */
border: 1px solid #ddd;
border-right: 1px solid #bbb;
border-bottom: 1px solid #aaa;
border-radius: 3px;
box-shadow: 1px 1px 1px #ddd;
}
.pagesection .button {
color: #346;
}
.button:hover, .button:focus,
.quickbuttons>li>a:hover, .quickbuttons>li>a:focus {
color: #222;
border: 1px solid #ddd;
border-left: 1px solid #bbb;
border-top: 1px solid #aaa;
box-shadow: -1px -1px 2px #ddd, -1px -2px 4px #ddd inset;
}
.button:hover, .button:focus {
color: #af6700;
}
/* the active one */
.button.active {
background: #557ea0;
color: #fff;
font-weight: bold;
border: 1px solid #558080;
text-shadow: 0 0 1px #000;
}
.button.active:hover, .button.active:focus {
color: #ffc187;
background: #557ea0;
box-shadow: none;
}
/* In a .buttonrow, the buttons are joined together */
.buttonrow {
margin: 0 5px;
}
.buttonrow .button {
display: table-cell;
border-radius: 0;
}
.buttonrow .button:first-child {
border-radius: 3px 0 0 3px;
}
.buttonrow .button:last-child {
border-radius: 0 3px 3px 0;
}
/* in a titlebg, the buttonlist is of small height */
.titlebg .buttonlist {
margin: 0;
padding: 0;
}
/* The quick buttons */
.quickbuttons {
margin: 11px 0 4px 0;
clear: right;
float: right;
text-align: right;
font-size: 0.75rem;
}
#recent .quickbuttons {
margin: 0;
}
.quickbuttons>li {
float: left;
}
.quickbuttons>li>a {
display: block;
height: auto;
padding: 0 4px;
color: #222;
line-height: 1.375rem;
border: 1px solid #ddd;
border-right: 1px solid #bbb;
border-bottom: 1px solid #aaa;
/* This is a case where shorthand hex
/* is best for a box-shadow. It always
/* overlays a blank background, so there
/* is no benefit in the longer rgba syntax. */
box-shadow: 1px 1px 1px #ddd;
border-radius: 0;
}
.quickbuttons>li:first-child>a {
border-radius: 4px 0 0 4px;
}
.quickbuttons>li:last-child>a {
border-radius: 0 4px 4px 0;
}
.quick_edit, .post_options {
position: relative;
}
/* Drop part of QuickButtons */
.post_options ul {
display: none;
position: absolute;
top: 100%;
right: -1px;
z-index: 90;
margin-top: 4px;
padding: 6px 0;
background: #fff;
font-weight: normal;
text-align: left;
border: solid 1px #999;
border-left: solid 1px #aaa;
border-top: solid 1px #bbb;
border-radius: 4px 0;
/* This is a case where rgba syntax is
/* worthwhile for a box-shadow, as it
/* overlays post text, which should
/* remain visible for best effect. */
box-shadow: 2px 3px 3px rgba(0, 0, 0, 0.2);
}
.post_options:hover ul {
display: block;
}
.post_options ul a {
display: block;
width: 12em;
padding: 0 6px;
line-height: 2.2em;
text-decoration: none;
border: 1px solid transparent;
border-width: 1px 0;
}
.post_options ul a:hover, .post_options ul a:focus {
background: #e2e9f3;
border-color: #c4cbd3;
}
.quickbuttons li.inline_mod_check {
padding: 1px;
}
/* Note: The next declarations are for keyboard access with js disabled. */
/* @WIP: Note: these have been broken by someone. Does lead dev want them fixed? */
.quickbuttons ul li a:focus {
margin: 0 -9910px 0 9910px;
}
/* Cancel for hover and/or js access. */
.quickbuttons ul li:hover a:focus, .quickbuttons ul li a:focus {
margin: 0;
}
Note the bit at the end. It is up to Sesq (or whoever is Big Dev Numero Uno these days) if he wants all drop menus being keyboard accessible with js disabled. I know he made approving noises when Gwen was talking about a11y a while back.
If he doesn't want that, the redundant code can be removed. If he does want it, it is easily achieved providing (and this is important) people are prepared to take the code given and to not (this means not) frig around with anything they do not understand (which, let's face it, every code junkie loves doing :P ).
Quote from: Antechinus on September 29, 2019, 08:45:51 PM
That "fix" will break functionality. It needs to be like this:
<a' . (!empty($li['href']) ? ' href="'.$li['href'].'"' : ' href="javascript:void(0);"') . (!empty($li['javascript']) ? $li['javascript'] : '') . '>
That will work. Yes, I have tested both. ;) Note that it does need the space in front of the href.
looking at the image, that's not the exact edit that is posted :P
here's the exact edited (https://github.com/SimpleMachines/SMF2.1/pull/5812/commits/4d07fca2eacd9fe873fa3ae07d522942ac3413da) line
<a href="' . (!empty($li['href']) ? $li['href'] : 'javascript:void(0);') . '"' . (!empty($li['javascript']) ? $li['javascript'] : '') . '>it's the same just declares href once instead.
I'll take a look at the other code changes you posted later(gotta run), but from reading what you are saying, totally sounds good :)
Ah. Righty o then. I missed that you'd changed the front of it too. My bad.
And come to think of it, that quickbuttons CSS can probably be cleaned up a bit. Unless I'm missing something, I don't think that ul actually needs to be floated. There are probably a couple of other declarations that could be made more concise too.
Ah now I know why the style was applied to the list items instead of the anchors, you can turn on "Checkboxes" for quick moderation, if the li is styled then the checkbox will look consistent with the rest, otherwise you got yourself a checkbox next to the quicbuttons that is not styled like the rest, I don't think wrapping the input with an anchor is a good idea though.
I like that you got rid of the selectors that were using the "not()" function, that one can be a real pain because its priority level is high.
I made some edits though; I put back the "cursor: pointer;" for the sake of submit inputs, and "text-decoration: none;" on the button hovering effect (underline in a button is .. eh weird) and the gradient background for the ".post_options ul" element, I don't dislike the style, I just think it's inconsistent with the rest of the theme and should retain the same style. I dropped the "font-size: 0.75rem;" on the quickbuttons, it is unnecessary since the anchors have their font-size set, however they look smaller than before, too small.
Also the hovering effect on a buttonrow button which is sibling to an active button, the shadow effect is kinda weird.
In that case I'd suggest just having an extra declaration for the one that wraps the checkbox, if you want that look. It wouldn't take much (presumably just add .inline_mod_check in one place). That way at least the anchors all work consistently on hover or focus. I know Apple makes focus have a distinct outline, but Firefox and friends don't (and the Apple outline is seriously ugly anyway).
IIRC originally we didn't bother wrapping the checkboxes in any styling. They were just checkboxes sitting after the buttons, which I thought was fine, but wrapping it in an li is fine too if you prefer that. And I must have missed the text-decoration thing.
TBH I think some of the current styling details (which are not original) are pretty ugly, so personally I'd have no qualms about making them less ugly. For example, the gradient on buttons and quickbuttons had been inverted from the original, which made them look rough as guts, so I flipped it back to the original. Similar deal with the drops. I think they're pretty gruesome at the moment, so making them a bit less gruesome is not a bad thing (while keeping the theme as a whole the same). Especially if it can be done while saving some code. I'm not going to start World War 3 over it though. :)
QuoteAlso the hovering effect on a buttonrow button which is sibling to an active button, the shadow effect is kinda weird
Not sure what you mean there. Must have missed that too. Those are only used in the calendar and maybe a couple of other places, right? I'll take a look.
ETA: I see what you mean now. Easy tweak. I'll do something for it if you like.
ETA2: Aha. I see what the problem is with the checkboxes. There's no class assigned to the li, which is inconsistent with the rest of the buttons. I think it would be sensible to assign a class. They used to be .inline_mod_check, which is why there's a declaration for that in the file.
'quickmod' => array(
'class' => 'inline_mod_check',
'id' => 'in_topic_mod_check_'. $output['id'],
'custom' => 'style="display: none;"',
'content' => '',
'show' => !empty($options['display_quick_mod']) && $options['display_quick_mod'] == 1 && $output['can_remove'],
)ETA3: Hey there is no button text underline on hover on my box. Not with the code I was running.
Oh hey: what's the minimum PHP version that 2.1 is comfortable with? I've been a bit lazy about upgrading my local, but for the moment I'd like to keep the ability to run some old 1.1.x stuff for reference, so if running on 5.6 isn't going to cause any problems I might leave it for now. If it's going to cause issues, I'll upgrade the local to 7.1 and figure out something else for running the old stuff.
Minimum version for 2.1 is php 5.4.
I think it may actually be 5.6....
Ok, so 5.6.26 should be fine for now. Handy to know.
Hold on to your hats, guys. I'm about to post code on Github. :P
ETA: Used GitHub without even swearing once. It's a miracle.
https://github.com/SimpleMachines/SMF2.1/pull/5812#issuecomment-536790818
Am not, that means not, going to fire up Sourcetree though. I'm quitting while I'm ahead. :D
It's 5.4...
Hey this next bit isn't a bugfix as such. It's just something I got it into my head to play with briefly. I thought I might as well put it up here to see what people think of it.
The new admin home page has always looked a bit messy to me. All the stuff is down the bottom, and although it is in rows it gives the visual impression of not really being structured. It's a bit hard to find things quickly as it doesn't seem to scan well. So I threw a few CSS tweaks at it, and I think it's a better look for the same content. I find it easy and natural to scan.
This is all using flex, with a parent div set to flex-wrap, auto width for the fieldsets on larger screens, and 48% width kicking in at 640px screen width. The last section (maintenance) just goes to full width automatically as it's the only one in its row. It should all be bulletproof, and it will have automatic RTL support without extra code being required.
The only markup change required is one wrapper div around the bunch of fieldsets, to give the required flexbox parent. The rest is just CSS tweaks.
Yea it seems like the 'inline_mod_check' class got lost somewhere along the way, anyway I'll restore that and use it like you did.
is there any reason for the marked redundant code ?
.quickbuttons > li > a, .inline_mod_check {
display: block; /* can be removed */
height: auto;
padding: 0 4px;
color: #222;
line-height: 1.375rem;
border: 1px solid #ddd; /* can be removed */
border-right: 1px solid #bbb; /* can be removed */
border-bottom: 1px solid #aaa; /* can be removed */
box-shadow: 1px 1px 1px #ddd; /* can be removed */
border-radius: 0;
}
.button, .quickbuttons > li > a, .inline_mod_check {
display: inline-block;
padding: 0 8px;
background: linear-gradient(to bottom, #fff 0%, #e2e9f3 70%);
color: #444;
font-size: 0.85em;
line-height: 2em;
text-transform: uppercase;
cursor: pointer;
height: calc(2em + 2em * (0.9 - 0.85));
border: 1px solid #ddd;
border-right: 1px solid #bbb;
border-bottom: 1px solid #aaa;
border-radius: 3px;
box-shadow: 1px 1px 1px #ddd;
}
I also removed the over-specification here
a.button, ... to .button, ...
buttons aren't always anchors.
Also the shadow effect you used on buttons is nice assuming buttons will always be used on light elements, when they're used in elements such as the cat_bar which has a blue like background, the shadow effect is bad, so I do prefer how the buttons looked before to be honest.
I haven't pushed any of the changes to the PR yet, will do so soon.
wish we could make use of the var() function though, too bad it's not supported across all browsers.
Well, if you want a different shadow effect on dark backgrounds all you need to do is define it. I didn't change that though. I only reversed the direction of the background gradient. Frankly I thought the way they were before was ugly as hell on light backgrounds, which I why I put them back to the original gradient direction. That still works on a catbg background. It's only the perimeter styling which might not work.
And, having just taken a look at it, I agree the perimeter styling could be improved. TBH I'm not entirely sure if the perimeter styling is even best on light backgrounds. I think it could still be tweaked slightly. Will have a play with it if you like.
Quotebuttons aren't always anchors.
Yes it still seems fine without the tag there.
.quickbuttons > li > a, .inline_mod_check {
display: block; /* can be removed */
height: auto;
padding: 0 4px;
color: #222;
line-height: 1.375rem;
border: 1px solid #ddd; /* can be removed */
border-right: 1px solid #bbb; /* can be removed */
border-bottom: 1px solid #aaa; /* can be removed */
box-shadow: 1px 1px 1px #ddd; /* can be removed */
border-radius: 0;
}The display:block is necessary there as they are defined as inline-block earlier in the file. That's because I wanted to pick up the existing styling from the .button class for the .quickbutton anchors, without having to declare it all over again. See back here:
.button, .quickbuttons>li>a, .inline_mod_check {
display: inline-block;
padding: 0 8px;
background: linear-gradient(to bottom, #fff 0%, #e2e9f3 70%);
color: #444;
font-size: 0.85em;
line-height: 2em;
text-transform: uppercase;
height: calc(2em + 2em * (0.9 - 0.85)); /* "input" font size minus ".button" font size */
border: 1px solid #ddd;
border-right: 1px solid #bbb;
border-bottom: 1px solid #aaa;
border-radius: 3px;
box-shadow: 1px 1px 1px #ddd;
}It makes sense to re-use that code for quickbuttons, but it also makes sense to declare the .quickbuttons anchors as block later, because otherwise you have to mess around with the gaps between buttons that will be forced by inline-block.
It's ok dealing with that gap once on the li's, to avoid having to clear floats and to get automatic support for RTL, but dealing with it twice on the anchors as well as the li's is a bit pointless. It's simpler to just declare the anchors as block display so they fill the li's.
But yes, those borders and box-shadows can be removed if you like. I was thinking of tweaking them some more, so had left them in both places so I could try comparisons, but not needed in the repo as such. :)
Hey just found a related bug. The quickbuttons in the strip on the profile>alerts page have a checkbox at the end, but that's not picking up any styling on the li. Not sure at the moment where that one is defined (haven't looked yet) but giving it the .inline_mod_check class seems like the sensible option.
ETA: Oh and would suggest changing the margin on the .quickbutton li's. My suggested code is this:
margin: 0 -.2rem 0 0;
But this works better (automatic for RTL, and slightly cleaner looks IMO):
.quickbuttons>li {
position: relative;
display: inline-block;
margin: 0 -2px;
}
Buttons also seem to need a text-decoration: none on hover. I'm sure I tested that, but I may have lost the plot somewhere, because underlining on hover is back. :P
So this works:
.button:hover, .button:focus,
.quickbuttons>li>a:hover, .quickbuttons>li>a:focus {
color: #222;
cursor: pointer;
text-decoration: none;
In which case it's not needed back here:
a.button, .quickbuttons>li>a, .inline_mod_check {
display: inline-block;
padding: 0 8px;
background: linear-gradient(to bottom, #fff 0%, #e2e9f3 70%);
color: #444;
font-size: 0.85em;
line-height: 2em;
text-transform: uppercase;
text-decoration: none; /* can be removed */
That one is not needed as they are defined that way (global for all anchors) at the start of the file. It's only the hover that is a problem.
Do you want me to do some more testing and get all of that into one sensible post? :D
ETA: Really, with the way the border styles are, it would make more sense to do the initial declaration as border: 1px solid; and then do the different colors by using the border-color attribute.
border: 1px solid #ddd;
border-right: 1px solid #bbb;
border-bottom: 1px solid #aaa;
Changed to:
border: 1px solid;
border-color: #ddd #bbb #aaa #ddd;
Is less verbose overall, since on hover and focus it's only the color that needs to be declared again:
border-color: #aaa #ddd #ddd #bbb;
Hey the only place that seems to have the .button class on a dark background is the admin search bar. Are there any other cases that I'm missing?
If that's the only one, how about just moving it to the information panel beneath the cat_bar? I did that yesterday on my 2.0.x mutant and IMO it's a much better look. Currently the admin search bar on 2.1 is a mess on narrower screens anyway.
ETA: Or, since I know what it's like trying to convince people to do something different, if you're determined to leave the admin search inside the catbg, so you can have fun fighting to get a decent responsive layout from that arrangement :D, then just give it specific styling in admin.css. That way, index.css is not cluttered by declarations that only admins will need, and you can style template_admin_quick_search() any way you like.
Excellent thread, Ant & SychO.
Just a note this is being tracked in GitHub over here:
https://github.com/SimpleMachines/SMF2.1/pull/5812
Yes, I know. :D This thread is getting a bit messy. I'm going to try to rationalise all of this stuff on local soon.
Quote from: Antechinus on October 02, 2019, 05:41:58 PM
Hey just found a related bug. The quickbuttons in the strip on the profile>alerts page have a checkbox at the end, but that's not picking up any styling on the li. Not sure at the moment where that one is defined (haven't looked yet) but giving it the .inline_mod_check class seems like the sensible option.
No worries, I took care of all the quickmoderation checkboxes everywhere.
Quote from: Antechinus on October 02, 2019, 05:35:55 PM
The display:block is necessary there as they are defined as inline-block earlier in the file. That's because I wanted to pick up the existing styling from the .button class for the .quickbutton anchors, without having to declare it all over again. See back here:
I don't think it is, since the quickbuttons list items are floated left.
Quote from: Antechinus
Buttons also seem to need a text-decoration: none on hover. I'm sure I tested that, but I may have lost the plot somewhere, because underlining on hover is back. :P
I already fixed it like I mentioned previously.
Quote from: Antechinus
ETA: Really, with the way the border styles are, it would make more sense to do the initial declaration as border: 1px solid; and then do the different colors by using the border-color attribute.
Lovely :D
You might want to just pull the branch where I pushed all changes (https://github.com/SimpleMachines/SMF2.1/pull/5812/files) and take a look, pulling branches is a lot easier than manually applying changes, it helps in the review process.
Quote from: SychO on October 07, 2019, 08:31:25 AM
I don't think it is, since the quickbuttons list items are floated left.
Not in my code they're not. :D I think they are better as inline-block. It saves having to worry about clearing floated content, and it swaps direction for RTL automatically, so no extra float code to worry about for RTL.
IMO this is a better solution for most menu strips. We had to use floats in 2.0.x because IE6 and (I think) IE7 didn't support inline-block, but from IE8 onwards and in any other browser there is full support for inline-block. The only slight catch with inline-block is the roughly 0.25em gap it forces after each element. If you need them sitting tight against each other that's easily dealt with in most cases by margin: 0 -1px. It doesn't matter for the main menu or buttonlist classes because they have gaps between buttons anyway.
The other nifty thing about inline-block is that for narrow screens you can change how they stack (basic code and screenshot here: https://www.simplemachines.org/community/index.php?topic=569433.msg4033649#msg4033649) so it's a bit more versatile than floats in that way too.
QuoteYou might want to just pull the branch where I pushed all changes (https://github.com/SimpleMachines/SMF2.1/pull/5812/files) and take a look, pulling branches is a lot easier than manually applying changes, it helps in the review process.
Bleh. :P GitHub. :P Me hatez GitHub. :P
I was thinking of doing that the other day. Turns out I'd have to go and register Sourcetree (trial period expired ages ago, around the last time I used GitHub). I couldn't be bothered at the time. Might be bothered soon.
Quote from: Antechinus on October 07, 2019, 02:22:57 PM
Bleh. :P GitHub. :P Me hatez GitHub. :P
Well, Git not GitHub, GitHub is just the platform that uses the version control system "Git"
So you would just have to install git, open your server public folder, open Git Bash there(git command line), and run
$ git clone https://github.com/SychO9/SMF2.1.git
$ git checkout -b antechinus
$ git pull upstream antechinus
Or if you're not comfortable with a command line, you could just install Git then GitHub Desktop.
Just throwing bits of information though, not trying to convince you or anything
The problem is, for many people (including, I think, Antechinus), the problem is the Git part of GitHub, and the blurring between Git and GitHub is mostly irrelevant.
Quote from: SychO on October 07, 2019, 02:43:26 PM
Well, Git not GitHub, GitHub is just the platform that uses the version control system "Git"
So you would just have to install git, open your server public folder, open Git Bash there(git command line), and run
$ git clone https://github.com/SychO9/SMF2.1.git
$ git checkout -b antechinus
$ git pull upstream antechinus
Read this: GitHub for n00bz (https://simplemachines.org/community/index.php?topic=539661.msg3836819#msg3836819) :D
Also this: If GitHub had built Twitter (https://www.simplemachines.org/community/index.php?topic=539661.msg3836544#msg3836544) :P
Quote from: Arantor on October 07, 2019, 02:50:27 PM
The problem is, for many people (including, I think, Antechinus), the problem is the Git part of GitHub, and the blurring between Git and GitHub is mostly irrelevant.
GitHub itself makes a bad thing worse. It's the poo on top of the poo cake.
Interesting, what about the -Hub part is bad? (Honestly, there are worse. I should maybe introduce you to Gerrit instances sometime so you can see how poo it can really be.)
Everything about the -Hub part is bad. :D This is why my instructions for n00bz specifically state that any attempt at a GUI that was built by GitHub should be avoided like the plague. This is in relation to downloadable stuff anyway. Obviously you have to use their interface on their actual site. That's not too bad. It's the desktop stuff that is abysmal.
And no, I really do not want to see anything worse.
Yeah, the official desktop GUI is terrible. I don't know how it is today, but when I was using it they were dropping things like showing you when there were differences to sync (oh noes, how dare my interfaceh have a number on it, death to all numbers and to all buttons!) so obviously this meant you never knew if there was anything new. Merge conflicts? Oh just go to the command line to solve them.
Fortunately other programs that are actually decent exist.
I found Sourcetree was excellent for "kevlar vest between me and GitHub". I just have to get enthused about actually registering my copy now, since the trial period has expired.
SourceTree used to be good but they keep changing the UI is various ways for no good reason, and it's slower than ever. I recently did some big commits (4000 lines) where the UI became unusable and I had to drop to command line anyway.
At work I don't have any choice, our workflow requires pushing commits in a way that no client understands.
Quote from: Arantor on October 08, 2019, 02:19:16 AM
SourceTree used to be good but they keep changing the UI is various ways for no good reason.
Glad you said that, because I was thinking the same. In fact when I first used it I had no problem finding my way around, but the later versions seem more complicated to me, logic seems to have gone out the window. Not only that, when I install the damn thing it disappears from my Windows 10 start menu and can't find it. I gave up with it. Been playing with gitkraken recently.
Ok. So maybe I won't bother registering my copy. Is Gitkraken nice and simple? I want to do everything with 3 buttons and no CLI.
Quote from: Antechinus on October 08, 2019, 02:51:27 AM
Ok. So maybe I won't bother registering my copy. Is Gitkraken nice and simple? I want to do everything with 3 buttons and no CLI.
Might be simple for those that know what they're doing, but I find the whole repo stuff generally confusing. Wish someone would post a actual workflow based on SMF in particular.
There's a load of tuts on youtube, https://www.youtube.com/watch?v=ub9GfRziCtU
Quote from: Antechinus on October 08, 2019, 02:51:27 AM
Ok. So maybe I won't bother registering my copy. Is Gitkraken nice and simple? I want to do everything with 3 buttons and no CLI.
I haven't used GitKraken mostly because I don't care enough about SourceTree's revamps of the UI enough to change and most people don't do the kinds of major works that I do, so it's probably fine.
But it doesn't look like it'd be significantly different effort to drive GitKraken; most of the fundamental complexity is Git anyway and a lot of it isn't really avoidable on some level.
Quotebut I find the whole repo stuff generally confusing
That's because it's actually really complicated, far more than it ever appears, mostly because when you have a copy of the code, you now have your own repo with its own history alongside the parent. Great for doing stuff offline and sending online later, not so great for 'simple'.
I'll try and post something for the SMF workflow but ultimately what Ant has in his signature is a workflow that'll work and not require too much mental overhead.
Yep, that's why I came up with it. :D
Looks like Gitkraken won't be any better. I might just go register Sourcetree. If it's too annoying I can always try something else later.
See, I just use the repo directly on my machine as the folder inside XAMPP so I don't have a second copy of anything and can commit whenever I like directly from whatever I'm working on, but that has its own issues.
Quote from: Arantor on October 08, 2019, 03:11:30 AM
I'll try and post something for the SMF workflow but ultimately what Ant has in his signature is a workflow that'll work and not require too much mental overhead.
Thanks. That would be really helpful if you could please. Actually a new dedicated topic just for this subject would be ideal, and easier to follow. ;)
I will try sourcetree again and see how it goes. I've just got to learn to persevere and stick with one system that works.
*scratches head* well I use GitHub Desktop just fine, I mean what it offers is enough, clone repositories, create branches, push, pull, publish. It's true it used to be somewhat full of bugs and hard to use, but they've fixed a lot and it is much better now.
What more could one ask for ¯\_(ツ)_/¯
I just looked at the newer version of the app (built in Electron), and honestly it looks more confusing to me than someone who deals in SourceTree frequently.
If you're explicitly following the GitHub expected workflows (either you're the main collaborator and can push to your own repo, or you're forking and making a pull request), you're probably fine. Anything more exotic and it doesn't look like it'd handle it.
I also don't expect it to handle anything like a stash, let alone interactive rebasing (which SourceTree can do both)... but I'd be concerned that an app has to reach 2.0 to be 'usable'.
Been reading up about Gitkraken. Apparently you can't use the free version without being logged in to their servers, which is unacceptable anyway.
Well yes, you can at least use it well enough to be able to contribute to other repositories by posting pull requests, anything more complex than a pull push, I turn to the CLI.
It's enough for me because it saves me a lot of time on the repetitive git add, git commit, git push, git pull, git branch -b...etc
Quote from: Antechinus on October 07, 2019, 02:22:57 PM
QuoteYou might want to just pull the branch where I pushed all changes (https://github.com/SimpleMachines/SMF2.1/pull/5812/files) and take a look, pulling branches is a lot easier than manually applying changes, it helps in the review process.
Bleh. :P GitHub. :P Me hatez GitHub. :P
I was thinking of doing that the other day. Turns out I'd have to go and register Sourcetree (trial period expired ages ago, around the last time I used GitHub). I couldn't be bothered at the time. Might be bothered soon.
you actually dont need sourcetree or git anything to pull down the branch and test out the code... to make it easier for you as of when you click the link you can download all the files in branch from here
https://github.com/SychO9/SMF2.1/archive/antechinus.zip
you can then install and test it out.
Quote from: Arantor on October 08, 2019, 04:25:56 AM
I just looked at the newer version of the app (built in Electron), and honestly it looks more confusing to me than someone who deals in SourceTree frequently.
If you're explicitly following the GitHub expected workflows (either you're the main collaborator and can push to your own repo, or you're forking and making a pull request), you're probably fine. Anything more exotic and it doesn't look like it'd handle it.
I also don't expect it to handle anything like a stash, let alone interactive rebasing (which SourceTree can do both)... but I'd be concerned that an app has to reach 2.0 to be 'usable'.
Pretty much. And with two people in it, you already get conflicts, which, if it can't solve by itself, it will toss you the command line for.
Anything more complex than pull and push was through the command line when I used it.
Quote from: Antechinus on October 08, 2019, 02:51:27 AM
Ok. So maybe I won't bother registering my copy. Is Gitkraken nice and simple? I want to do everything with 3 buttons and no CLI.
You can do everything in Gitkraken (except fix conflicts in a PR, which is a bummer, or I didn't figure out how it works yet, because their conflicts interface is neat) through a nice interface. I like it. The flow of which thing goes where when you're doing something between two branches can be confusing at first but other than that I think it's fairly simple to use. If you're only doing master then you don't even have to worry about it.
QuoteBeen reading up about Gitkraken. Apparently you can't use the free version without being logged in to their servers, which is unacceptable anyway.
Well you'd be logged to GitHub anyway. I think they do that through their servers? I'm not sure. I don't recall having to create any account/connection just to use it locally, just using your email/key to link it with GitHub...
QuoteSee, I just use the repo directly on my machine as the folder inside XAMPP so I don't have a second copy of anything and can commit whenever I like directly from whatever I'm working on, but that has its own issues.
That's what I'm trying to do now. It's much simpler without the constant checking online files against offline ones.
- Get everything installed: check <3 Now only need to use it as a repo. And now with the sass source files outside and compiling to inside the repo so I don't need to keep track of .gitignore and missive files.
I think we're going a little off topic, but to sum up some of the things:
* fixing conflicts is always hard and why none of the Git tools themselves ever try because it's 1) out of scope and 2) needs a human input as to what should be the final resolution anyway
* GitKraken doesn't just have you logged into GitHub (or, more accurately, the underlying Git implementation has you logged into GitHub when you need to be) but I think it also mandates being logged into GitKraken's servers too because it's not actually a free product
* using SMF or similar as a repo is easy enough, wherever your webserver is (be it /var/www/html or similar), "git clone https://github.com/SimpleMachines/SMF2.1.git smf" (or use the clone to make a folder in that place), and you're done, you can then go to localhost/smf or whatever and the files are already just there
I have 100% changed from doing uploads of new files to my various sites(especially all the different Themes folders)to *just* using pulls from Github. Github Desktop is used to push things on my local test-sites and if any files should -not- be pushed, I use .gitignore. The program works fine for me, even when changing branches. I think its *way* you use branches that can cause trouble, its no set rules afaik, it can be used in different ways, even working with forks instead of branches could work.
Advantages from the old way of compare/change/upload for me is less hassle in making sure everything is updated(one pull call now) and I can keep stricter access to files on the server - my regular ftp user cannot upload new or overwrite files wihout it belonging to it(which none do), but when logged in with ssh I can sudo git pull/push changes making it more secure.
Great summary, Arantor :) Just my 5 cents here.
Quote* fixing conflicts is always hard and why none of the Git tools themselves ever try because it's 1) out of scope and 2) needs a human input as to what should be the final resolution anyway
Yep, which is why Gitkraken's interface for it is neat. It just shows you both sides and lets you add per line or per chunk of both while viewing the end result. The problem with PR conflicts is that github doesn't recognize it as such, it submits as a new commit rather than a conflict fix, which doesn't seem to work.
Technically that's what goes on under the hood anyway; you have a commit that represents the point at which two branches are merged (the "merge commit"), and the conflict resolution step is an amended version of that commit.
It's also why you might sometimes do merges via rebase rather than with actual merges depending on what you're trying to do and how much you care about your history being clean; if you're me and you deal in managing massively complex codebases with core changes, you might want to minimise the cruft in your branches so that when it comes to upgrade time, you can filter out the core commits and keep just your changes in their own little branch ready to replay over the updated codebase later. But that's getting into funky territory.
Y'all remind me of my uni teachers. Refusing to use modern stuff (in general talking, Git is the particular case now) instead of adapting to the new times. That's why I'm still coding in C, and that's why people in Biotechnology degree are using Pascal for programming in 2019.
I sincerely hope I'm not included in that 'y'all', on the nature that my day job literally couldn't be done in Git with any GUI I've ever seen (since none of them seem to support git push origin HEAD:refs/for/branch syntax by default which makes life complicated since that's how Gerrit works), and that at any given time I have literal dozens of branches within my repos including feature branches of feature branches, and some hefty infrastructure for soft-merging feature branches for the purposes of deploying test environments with multiple feature branches at once.
And let's not forget the dozens of submodules I have floating around.
That's another curse that people rarely remember (and even SMF has a submodule in its repo last I checked)
It's obvious that what can't be done, can't be done. What I'm saying here is that the common arguments of Git(Hub) are like "Git bad. GitHub bad. Everything bad".
Quote from: Arantor on October 08, 2019, 08:31:55 AM
Technically that's what goes on under the hood anyway; you have a commit that represents the point at which two branches are merged (the "merge commit"), and the conflict resolution step is an amended version of that commit.
It's also why you might sometimes do merges via rebase rather than with actual merges depending on what you're trying to do and how much you care about your history being clean; if you're me and you deal in managing massively complex codebases with core changes, you might want to minimise the cruft in your branches so that when it comes to upgrade time, you can filter out the core commits and keep just your changes in their own little branch ready to replay over the updated codebase later. But that's getting into funky territory.
That's what I thought when I tried, but the result wasn't what I expected and it still said there were conflicts. Maybe I didn't do it right.
Rebases are a bit trickier to work with at that level, aren't they?
@d3vcho();
To be fair, for non-technical people, Git is fundamentally a disaster. It's obtuse and hard to use and a fundamental barrier to entry. I have yet to understand how GitHub actually got popular, because I have learned very firmly that while this stuff is trivial for me to deal with, it's really not trivial for others. I'm usually the one doing merge conflict resolution at work because it's *hard* and just casually dismissing the complaints of others because it's things we don't find difficult is a huge problem because we're delegitimising the concerns of others. It's the intellectual equivalent of 'works on my machine' - it works for me therefore I don't see why you have a problem. I'm trying to be less obnoxious about it with other people, but it's not entirely successful.
What we should probably be teaching people that, instead of making them deal with all the logical overheads that Git mandates, they could probably actually use an SVN client which for many people is an order of magnitude simpler to actually work with. (And yes, GitHub does actually support SVN clients as a front end (https://help.github.com/en/articles/support-for-subversion-clients))
Let me know the next time you explain Git, from scratch, to someone who has been developing for years without it and see how difficult you actually find getting them to understand it. Why make them have to understand it when they just want to get on and write code?
@Gwen rebases are... interesting. Essentially what you're saying is 'ok, I have a list of commits, each of which represents adding-some-lines, changing-some-lines, now I want to change the order of commits, and I want to make those two commits into one commit, and so on. You can do an awful lot with rebases, including merging branches by just including the commits from both branches in the right order, but doing it manually is effort, though if you have a good reason to keep your repo tidy, and you do it regularly, it's not so bad.
Oh, wow. And here me thinking of simple rebases @_@
Quote from: Illori on October 08, 2019, 05:08:05 AMyou actually dont need sourcetree or git anything to pull down the branch and test out the code... to make it easier for you as of when you click the link you can download all the files in branch from here
https://github.com/SychO9/SMF2.1/archive/antechinus.zip
you can then install and test it out.
Really? Damn. You mean there are files and stuff in the repo? With code n stuff in them? And a nice little folder full of things like intsall.php? I'd never realised. :P
Quote from: Arantor on October 08, 2019, 08:47:23 AMWhat we should probably be teaching people that, instead of making them deal with all the logical overheads that Git mandates, they could probably actually use an SVN client which for many people is an order of magnitude simpler to actually work with. (And yes, GitHub does actually support SVN clients as a front end (https://help.github.com/en/articles/support-for-subversion-clients))
Yep. The old Tortoise/svn/Mantis system was a piece of cake.
QuoteLet me know the next time you explain Git, from scratch, to someone who has been developing for years without it and see how difficult you actually find getting them to understand it. Why make them have to understand it when they just want to get on and write code?
Double yep. As some people may have noticed, I don't have a problem writing code. I just object to people who want to make it more difficult than it needs to be, given that I do it in my free time basically just because I like writing code sometimes.
GitHub was supposed to speed up development. Call me thick, but I haven't actually noticed that SMF dev is now a blazing fast process compared to how it used to be.
I'm digging the git terminal on visual studio right now it seems very responsive, and I use GitHub desktop too sometimes cuz been using it since it had a bad UI and always worked for me
Quote from: Antechinus on October 08, 2019, 02:19:53 PM
Quote from: Arantor on October 08, 2019, 08:47:23 AMWhat we should probably be teaching people that, instead of making them deal with all the logical overheads that Git mandates, they could probably actually use an SVN client which for many people is an order of magnitude simpler to actually work with. (And yes, GitHub does actually support SVN clients as a front end (https://help.github.com/en/articles/support-for-subversion-clients))
Yep. The old Tortoise/svn/Mantis system was a piece of cake.
QuoteLet me know the next time you explain Git, from scratch, to someone who has been developing for years without it and see how difficult you actually find getting them to understand it. Why make them have to understand it when they just want to get on and write code?
Double yep. As some people may have noticed, I don't have a problem writing code. I just object to people who want to make it more difficult than it needs to be, given that I do it in my free time basically just because I like writing code sometimes.
GitHub was supposed to speed up development. Call me thick, but I haven't actually noticed that SMF dev is now a blazing fast process compared to how it used to be.
Speed up development? Not so sure about that..but there are other advantages. I like the history thing, even branching though I don't use it that much. Being able to pluck out a time in history and use code from that..but still keep the most recent things, thats worth gold to me. :D
Quote from: Antechinus on October 08, 2019, 02:19:53 PM
GitHub was supposed to speed up development. Call me thick, but I haven't actually noticed that SMF dev is now a blazing fast process compared to how it used to be.
Of course not, but also the size of the team is not the same as it used to be. And apart for the speed, I believe that the quality of the code has improved since we use GitHub. Take 2.1 for example.
Quote from: d3vcho(); on October 08, 2019, 02:43:54 PM
Quote from: Antechinus on October 08, 2019, 02:19:53 PM
GitHub was supposed to speed up development. Call me thick, but I haven't actually noticed that SMF dev is now a blazing fast process compared to how it used to be.
Of course not, but also the size of the team is not the same as it used to be. And apart for the speed, I believe that the quality of the code has improved since we use GitHub. Take 2.1 for example.
Well, the code has the benefit of an extra decade of development around the web as a whole, which is always going to be a significant factor. You would expect 2.1 to be more advanced.
Quote from: Bloc on October 08, 2019, 02:41:53 PMSpeed up development? Not so sure about that..but there are other advantages. I like the history thing, even branching though I don't use it that much. Being able to pluck out a time in history and use code from that..but still keep the most recent things, thats worth gold to me. :D
That was the original claim. Moving to GitHub was going to open up a new golden era of oodles of happy bunnies contributing megabytes of awesome code, thereby speeding up development to levels previously undreamt of. Hasn't exactly turned out that way. Which is not the fault of anyone contributing now, but is still an amusing contrast to the original claims (which I remember, having been there at the time).
Quote from: Antechinus on October 08, 2019, 03:07:43 PM
That was the original claim. Moving to GitHub was going to open up a new golden era of oodles of happy bunnies contributing megabytes of awesome code, thereby speeding up development to levels previously undreamt of. Hasn't exactly turned out that way. Which is not the fault of anyone contributing now, but is still an amusing contrast to the original claims (which I remember, having been there at the time).
I'm pretty sure that if the development was still happening on SVN which is not open to the public as in Git using GitHub, 2.1 would be in a worse state right now.
Quote from: Antechinus on October 08, 2019, 03:07:43 PM
Quote from: Bloc on October 08, 2019, 02:41:53 PMSpeed up development? Not so sure about that..but there are other advantages. I like the history thing, even branching though I don't use it that much. Being able to pluck out a time in history and use code from that..but still keep the most recent things, thats worth gold to me. :D
That was the original claim. Moving to GitHub was going to open up a new golden era of oodles of happy bunnies contributing megabytes of awesome code, thereby speeding up development to levels previously undreamt of. Hasn't exactly turned out that way. Which is not the fault of anyone contributing now, but is still an amusing contrast to the original claims (which I remember, having been there at the time).
Well, for one thing, you'd not have any of my changes there if it wasn't in GitHub... it's a tool, not a solution to all SMF's problems as these things tend to be put out as. On another hand, there is very little incentive for anyone to go there nor much explaining how the process works for those interested (I had to ask on IRC, that's bad), which is probably another contributor. There's actually not much incentive or information in general how to contribute (the number of people who didn't even know charter was a thing is but one example), but again I doubt that's all of the reason SMF is so stalled right now.
The official mods/themes repos are also there now and public for the same reason (no need to be on the team to help), but of course everyone will forget it exists.