January 19, 2015
On Monday, 19 January 2015 at 16:44:04 UTC, Andrei Alexandrescu wrote:
> On 1/18/15 6:50 PM, DaveG wrote:
>>
>>
>> Here's where I'm at. The menus don't use javascript (except when the
>> screen gets so small it needs a button to open the navigation, the
>> button uses js). It scales with screen size and should work on mobile
>> (untested) - I changed doctype to html5 and added metatags for mobile.
>>
>> https://dl.dropboxusercontent.com/u/114394/D-site/redesign/index.html
>
> Could you please submit a PR to my better-menus fork on github? Thanks! -- Andrei

I need to fix a few things tonight. Also, is there some way to know what the current page is when generating the html? It would be nice to know what page you are currently on. Actually now that I think of it, with sub-navigation I also need to know the parent so it can be expanded when on a sub-page. I can do it in javascript, but that's not ideal.
January 19, 2015
On 1/19/15 9:37 AM, DaveG wrote:
> I need to fix a few things tonight. Also, is there some way to know what
> the current page is when generating the html? It would be nice to know
> what page you are currently on. Actually now that I think of it, with
> sub-navigation I also need to know the parent so it can be expanded when
> on a sub-page. I can do it in javascript, but that's not ideal.

Sadly no. You have the title of the current page as $(TITLE) which is by default the extensionless filename but many pages are setting differently.

I think javascript is the way to go.

Should we pull my stuff so the others come on top of it?


Andrei

January 19, 2015
On 2015-01-19 18:00, DaveG wrote:

> The vertical menu expanded from the top works well with relatively few
> items (in the case of bootstrap, eight). Personally, I don't think that
> method works well with many items (we currently show 13, and up to 26
> when expanded). It is particularly weird when the menu takes up more
> than the height of the screen and you loose the context of where you
> are. Maybe I'm in the minority, what do other people think?

I think we already have do many items in the menu, this would be a good opportunity to reorganize the menu a bit.

-- 
/Jacob Carlborg
January 19, 2015
On Monday, 19 January 2015 at 19:47:25 UTC, Jacob Carlborg wrote:
> On 2015-01-19 18:00, DaveG wrote:
>
>> The vertical menu expanded from the top works well with relatively few
>> items (in the case of bootstrap, eight). Personally, I don't think that
>> method works well with many items (we currently show 13, and up to 26
>> when expanded). It is particularly weird when the menu takes up more
>> than the height of the screen and you loose the context of where you
>> are. Maybe I'm in the minority, what do other people think?
>
> I think we already have do many items in the menu, this would be a good opportunity to reorganize the menu a bit.

Agreed.
FWIW, dub is listed twice on Andrei's update - it's under "Get D
libraries" and "Community->Third Party Packages"

The documentation drop-down is also very cluttered.
January 19, 2015
On Monday, 19 January 2015 at 18:46:24 UTC, Andrei Alexandrescu wrote:
>
> Should we pull my stuff so the others come on top of it?
>
I'm new to git (and github) so I don't know the process. I just cloned your branch locally and have been working off that. I assume I can fork master and push my changes to that and then do a pull request. Is this correct? If that's the case you shouldn't have to pull your changes (although you may want to just for the history and to close the request, I don't know).

-Dave
January 20, 2015
On 1/20/2015 5:21 AM, DaveG wrote:
> On Monday, 19 January 2015 at 18:46:24 UTC, Andrei Alexandrescu wrote:
>>
>> Should we pull my stuff so the others come on top of it?
>>
> I'm new to git (and github) so I don't know the process. I just cloned
> your branch locally and have been working off that. I assume I can fork
> master and push my changes to that and then do a pull request. Is this
> correct? If that's the case you shouldn't have to pull your changes
> (although you may want to just for the history and to close the request,
> I don't know).
>
> -Dave

Fork first, clone your fork, create a new branch, make changes, push to your fork, create a PR from the new branch [1].

As I learned on my first PR, you'll want to create separate branches for each unrelated change. Once you submit a PR, further changes pushed to that branch will be added to it.

[1] https://help.github.com/articles/creating-a-pull-request/
January 20, 2015
On Tuesday, 20 January 2015 at 01:49:45 UTC, Mike Parker wrote:
> Fork first, clone your fork, create a new branch, make changes, push to your fork, create a PR from the new branch [1].
>
> As I learned on my first PR, you'll want to create separate branches for each unrelated change. Once you submit a PR, further changes pushed to that branch will be added to it.
Thanks Mike. Got stuck at the office, didn't get home until around 11 which didn't leave much time to work on it. Hopefully tomorrow will be better.
1 2 3 4 5 6 7 8 9 10
Next ›   Last »