New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ticket/unstable/263 new layout ready #114

Merged
merged 66 commits into from Nov 7, 2011

Conversation

Projects
None yet
7 participants
@edavis10
Member

edavis10 commented Oct 28, 2011

edavis10 and others added some commits Jul 31, 2011

Merge remote-tracking branch 'tomzx/b551_hardcoded_french_string'
Conflicts:
	app/views/wiki/annotate.rhtml
	app/views/wiki/diff.rhtml
	app/views/wiki/show.rhtml
Merge remote-tracking branch 'tomzx/b552_hardcoded_english_string'
Conflicts:
	app/helpers/repositories_helper.rb
Adding check all links to new project form.
Makes bulk changes that much faster...
[#577] Avoid validating users when creating watcher relation
Taken from Redmine r5880
Committed by Jean Philippe Lang
Merge pull request #97 from finnlabs/pulls/577/invalid-watcher-user-fix
Invalid watcher user error when adding an invalid user as watcher #577
Fix issue pdf export #561
The pdf export tried to export the initial journal, which it shouldn't.
Merge pull request #96 from finnlabs/pulls/573/fix_aas_in_wiki_content
[#573] acts_as_searchable definition in WikiPage may be insufficient and cause SQL errors
Merge pull request #100 from thegcat/feature/517-put_faster_csv_in_th…
…e_gemfile

Rip faster_csv out of lib into the Gemfile. #517
This should fix it once and for all… #517
(Sorry for the commit-noise)

thegcat and others added some commits Oct 3, 2011

Merge pull request #93 from peelman/form-attribute-changes
Adding Check All / Uncheck All on New Project form. #644
[#633] WikiPages may have no author - but should have
Chili 1.x did not enforce the presence of an author for wiki pages, but Chili 2.x does. This migrations fails, if there are WikiPages or Versions without author. By updating the migration, we may ensure, that the erroneous pages are correctly updated.

Signed-off-by: Holger Just <h.just@finn.de>
[#619] Restrict anonymous read access with Redmine.pm
Redmine.pm now also checks for public projects whether the anonymous
user has the browse_repository right for a read operation.
Moving query related models into separate files
This should enable easier overwriting/reloading in plugins, since now the autoloader is able to find the models.
<%= link_to_if_authorized l(:button_log_time), {:controller => 'timelog', :action => 'new', :issue_id => @issue}, :class => 'icon icon-time-add' %>
<%= watcher_link(@issue, User.current, {:class => 'watcher_link', :replace => ['#watchers', '.watcher_link']}) %>
<%= link_to_if_authorized l(:button_duplicate), {:controller => 'issues', :action => 'new', :project_id => @project, :copy_from => @issue }, :class => 'icon icon-duplicate' %>
<%= link_to_if_authorized l(:button_copy), {:controller => 'issue_moves', :action => 'new', :id => @issue, :copy_options => {:copy => 't'}}, :class => 'icon icon-copy' %>
<%= link_to_if_authorized l(:button_move), {:controller => 'issue_moves', :action => 'new', :id => @issue}, :class => 'icon icon-move' %>
<%= link_to_if_authorized l(:button_delete), {:controller => 'issues', :action => 'destroy', :id => @issue}, :confirm => (@issue.leaf? ? l(:text_are_you_sure) : l(:text_are_you_sure_with_children)), :method => :post, :class => 'icon icon-del' %>
<div class="update button-large">

This comment has been minimized.

@thegcat

thegcat Nov 3, 2011

Member

.button-large is not a semantic but a "design" class, shouldn't be solved like this.

@thegcat

thegcat Nov 3, 2011

Member

.button-large is not a semantic but a "design" class, shouldn't be solved like this.

This comment has been minimized.

@edavis10

edavis10 Nov 3, 2011

Member

I'll change it.

@edavis10

edavis10 Nov 3, 2011

Member

I'll change it.

This comment has been minimized.

@edavis10

edavis10 Nov 6, 2011

Member

After thinking about it, 'button large' still sounds like the best fit. The HTML is saying there should be a large button here but isn't saying what that design should be.

I'm leaving this alone for now. If you have a better name we can change it later.

@edavis10

edavis10 Nov 6, 2011

Member

After thinking about it, 'button large' still sounds like the best fit. The HTML is saying there should be a large button here but isn't saying what that design should be.

I'm leaving this alone for now. If you have a better name we can change it later.

<!--[if lte IE 7]><%= stylesheet_link_tag 'ie7', :media => 'all' %><![endif]-->
<!--[if gte IE 8]><![endif]-->
<%= javascript_include_tag 'jquery.1.3.2.min.js' %>

This comment has been minimized.

@thegcat

thegcat Nov 3, 2011

Member

Any reason preventing us from using a current jquery?

@thegcat

thegcat Nov 3, 2011

Member

Any reason preventing us from using a current jquery?

This comment has been minimized.

@edavis10

edavis10 Nov 3, 2011

Member

The design has been tested with this version only. I have an issue to upgrade to a newer version that I'll work on after this is merged.

@edavis10

edavis10 Nov 3, 2011

Member

The design has been tested with this version only. I have an issue to upgrade to a newer version that I'll work on after this is merged.

<%= stylesheet_link_tag 'rtl', :media => 'all' if l(:direction) == 'rtl' %>
<!--[if lte IE 6]><%= stylesheet_link_tag 'ie6', :media => 'all' %><![endif]-->
<!--[if lte IE 7]><%= stylesheet_link_tag 'ie7', :media => 'all' %><![endif]-->
<!--[if gte IE 8]><![endif]-->

This comment has been minimized.

@thegcat

thegcat Nov 3, 2011

Member

Would it be OK for you change those to selectors on the body (body.ie6, body.ie7 for the css and something like <!--[if lte IE 6]><body class="ie ie6"><![endif]--> in the page? That way plugins could add specific ie rules in their css, and the extra (core) css files can be merged to the theme too.

@thegcat

thegcat Nov 3, 2011

Member

Would it be OK for you change those to selectors on the body (body.ie6, body.ie7 for the css and something like <!--[if lte IE 6]><body class="ie ie6"><![endif]--> in the page? That way plugins could add specific ie rules in their css, and the extra (core) css files can be merged to the theme too.

This comment has been minimized.

@edavis10

edavis10 Nov 3, 2011

Member

That doesn't make sense to me. These are done so each version of IE gets only the files it needs. What you're proposing wouldn't work because:

  • the body element becomes a case statement (case when ie7 <body.ie7>; when ie6 <body.ie6>; else <body>)
  • non-IE browsers would skip over if-comments, so they wouldn't have a body at all
  • you can't put a default body outside of the if-comments because then ie would get two bodies

I'll have to see the code you are proposing if this isn't what you meant.

@edavis10

edavis10 Nov 3, 2011

Member

That doesn't make sense to me. These are done so each version of IE gets only the files it needs. What you're proposing wouldn't work because:

  • the body element becomes a case statement (case when ie7 <body.ie7>; when ie6 <body.ie6>; else <body>)
  • non-IE browsers would skip over if-comments, so they wouldn't have a body at all
  • you can't put a default body outside of the if-comments because then ie would get two bodies

I'll have to see the code you are proposing if this isn't what you meant.

This comment has been minimized.

@meineerde

meineerde Nov 3, 2011

Member

This is how I use it on http://meine-er.de which produces correct syntax for all browsers:

<!--[if lt IE 7 ]> <body class="ie ie6"> <![endif]-->
<!--[if IE 7 ]> <body class="ie ie7"> <![endif]-->
<!--[if IE 8 ]> <body class="ie ie8"> <![endif]-->
<!--[if IE 9 ]> <body class="ie ie9"> <![endif]-->
<!--[if (gt IE 9)|!(IE)]><!--> <body class='non-ie'> <!--<![endif]-->
@meineerde

meineerde Nov 3, 2011

Member

This is how I use it on http://meine-er.de which produces correct syntax for all browsers:

<!--[if lt IE 7 ]> <body class="ie ie6"> <![endif]-->
<!--[if IE 7 ]> <body class="ie ie7"> <![endif]-->
<!--[if IE 8 ]> <body class="ie ie8"> <![endif]-->
<!--[if IE 9 ]> <body class="ie ie9"> <![endif]-->
<!--[if (gt IE 9)|!(IE)]><!--> <body class='non-ie'> <!--<![endif]-->

This comment has been minimized.

@edavis10

edavis10 Nov 3, 2011

Member

No offensive but that looks horrible, especially the last case. And each of these needs to run through erb because our body looks like <body class="<%=h body_css_classes %>">.

@edavis10

edavis10 Nov 3, 2011

Member

No offensive but that looks horrible, especially the last case. And each of these needs to run through erb because our body looks like <body class="<%=h body_css_classes %>">.

This comment has been minimized.

@meineerde

meineerde Nov 3, 2011

Member

The text is inserted verbatim into the layout. The body_base_classes can be inserted into each of the optional body tags. So ERB has no additional overhead.

The upside is that it don't require to load an additional stylesheet which has to be maintained separately and thus looses locality. It would also break once we use the assets pipeline in Rails 3.1.

This exact approach is also taken by the HTML5 Boilerplate which I consider best practice. (Well, they updated it to set the classes on the <html> tag, but still...)

@meineerde

meineerde Nov 3, 2011

Member

The text is inserted verbatim into the layout. The body_base_classes can be inserted into each of the optional body tags. So ERB has no additional overhead.

The upside is that it don't require to load an additional stylesheet which has to be maintained separately and thus looses locality. It would also break once we use the assets pipeline in Rails 3.1.

This exact approach is also taken by the HTML5 Boilerplate which I consider best practice. (Well, they updated it to set the classes on the <html> tag, but still...)

This comment has been minimized.

@edavis10

edavis10 Nov 3, 2011

Member

The text is inserted verbatim into the layout. The body_base_classes can be inserted into each of the optional body tags. So ERB has no additional overhead.

There is an overhead because erb would run 5 times and before it's sent to the browser. And then we would have to make sure to change the body tag 5 times if it changes.

<!--[if lt IE 7 ]> <body class="ie ie6 <%=h body_css_classes %>"> <![endif]-->
<!--[if IE 7 ]> <body class="ie ie7 <%=h body_css_classes %>"> <![endif]-->
<!--[if IE 8 ]> <body class="ie ie8 <%=h body_css_classes %>"> <![endif]-->
<!--[if IE 9 ]> <body class="ie ie9 <%=h body_css_classes %>"> <![endif]-->
<!--[if (gt IE 9)|!(IE)]><!--> <body class='non-ie <%=h body_css_classes %>'> <!--<![endif]-->

The upside is that it don't require to load an additional stylesheet which has to be maintained separately and thus looses locality.

Loading an additional stylesheet isn't that much, especially once they are cached in the client cache.

It would also break once we use the assets pipeline in Rails 3.1.

That discussion should wait until we are on Rails 3.1 and using the assets pipeline.

This exact approach is also taken by the HTML5 Boilerplate which I consider best practice. (Well, they updated it to set the classes on the tag, but still...)

I don't consider that best practice yet. Including IE specific stylesheets has been the "best practice" for years now. If you look at our current layout that is what is done for IE6 support right now (using an inline stylesheet).

@edavis10

edavis10 Nov 3, 2011

Member

The text is inserted verbatim into the layout. The body_base_classes can be inserted into each of the optional body tags. So ERB has no additional overhead.

There is an overhead because erb would run 5 times and before it's sent to the browser. And then we would have to make sure to change the body tag 5 times if it changes.

<!--[if lt IE 7 ]> <body class="ie ie6 <%=h body_css_classes %>"> <![endif]-->
<!--[if IE 7 ]> <body class="ie ie7 <%=h body_css_classes %>"> <![endif]-->
<!--[if IE 8 ]> <body class="ie ie8 <%=h body_css_classes %>"> <![endif]-->
<!--[if IE 9 ]> <body class="ie ie9 <%=h body_css_classes %>"> <![endif]-->
<!--[if (gt IE 9)|!(IE)]><!--> <body class='non-ie <%=h body_css_classes %>'> <!--<![endif]-->

The upside is that it don't require to load an additional stylesheet which has to be maintained separately and thus looses locality.

Loading an additional stylesheet isn't that much, especially once they are cached in the client cache.

It would also break once we use the assets pipeline in Rails 3.1.

That discussion should wait until we are on Rails 3.1 and using the assets pipeline.

This exact approach is also taken by the HTML5 Boilerplate which I consider best practice. (Well, they updated it to set the classes on the tag, but still...)

I don't consider that best practice yet. Including IE specific stylesheets has been the "best practice" for years now. If you look at our current layout that is what is done for IE6 support right now (using an inline stylesheet).

<% display_sidebar = true %>
<% else %>
<% display_sidebar = false %>
<% end %>

This comment has been minimized.

@thegcat

thegcat Nov 3, 2011

Member

This should probably go in a helper, it at all.

@thegcat

thegcat Nov 3, 2011

Member

This should probably go in a helper, it at all.

This comment has been minimized.

@edavis10

edavis10 Nov 3, 2011

Member

I was waiting to refactor this.

@edavis10

edavis10 Nov 3, 2011

Member

I was waiting to refactor this.

@@ -0,0 +1,5 @@
<% if @project %>
<div class="new-issue button-large">

This comment has been minimized.

@thegcat

thegcat Nov 3, 2011

Member

(see above comment about .button-large)

@thegcat

thegcat Nov 3, 2011

Member

(see above comment about .button-large)

@thegcat

This comment has been minimized.

Show comment
Hide comment
@thegcat

thegcat Nov 3, 2011

Member

public/images/pencil.png.oxygen is probably a source file that shouldn't still be there.

Member

thegcat commented Nov 3, 2011

public/images/pencil.png.oxygen is probably a source file that shouldn't still be there.

else
params[:controller]
end

This comment has been minimized.

@thegcat

thegcat Nov 3, 2011

Member

That should definitely not be here. The cleanest current way to achieve "exceptions" for which menu item to open/highlight probably is an extension of the Redmine::MenuManager::MenuController.menu_item.

@thegcat

thegcat Nov 3, 2011

Member

That should definitely not be here. The cleanest current way to achieve "exceptions" for which menu item to open/highlight probably is an extension of the Redmine::MenuManager::MenuController.menu_item.

This comment has been minimized.

@edavis10

edavis10 Nov 3, 2011

Member

Maybe but that is left in until we figure out submenus: https://www.chiliproject.org/issues/559#note-4.

@edavis10

edavis10 Nov 3, 2011

Member

Maybe but that is left in until we figure out submenus: https://www.chiliproject.org/issues/559#note-4.

@@ -26,24 +26,29 @@ module JournalsHelper
def render_journal(model, journal, options = {})
return "" if journal.initial?
journal_content = render_journal_details(journal, :label_updated_time_by)
journal_content += render_notes(model, journal, options) unless journal.notes.blank?
journal_content = render_journal_details(journal, :label_updated_time_by, model, options)

This comment has been minimized.

@thegcat

thegcat Nov 3, 2011

Member

We lose flexibility by including render_notes into render_journal_details. What about extracting the header string without the call to render_notes into a render_journal_header method, so that render_journal is render_journal_header; render_notes; render_jounral_details?

@thegcat

thegcat Nov 3, 2011

Member

We lose flexibility by including render_notes into render_journal_details. What about extracting the header string without the call to render_notes into a render_journal_header method, so that render_journal is render_journal_header; render_notes; render_jounral_details?

This comment has been minimized.

@edavis10

edavis10 Nov 3, 2011

Member

Maybe, see my global note below about refactoring.

@edavis10

edavis10 Nov 3, 2011

Member

Maybe, see my global note below about refactoring.

@edavis10

This comment has been minimized.

Show comment
Hide comment
@edavis10

edavis10 Nov 3, 2011

Member

I'm not sure if I made this clear yet.

This pull request is to get the first version of the redesign in place. Yes there might be visual bugs, yes there are places where we can refactor things to be cleaner. But if we block this pull request and wait until it's "perfect" then we might as well wait 12 months before the redesign is done.

Having something "good" now is 100x better than waiting months until it's "perfect". Especially since the next stage is already blocked and waiting (finn-design).

Member

edavis10 commented Nov 3, 2011

I'm not sure if I made this clear yet.

This pull request is to get the first version of the redesign in place. Yes there might be visual bugs, yes there are places where we can refactor things to be cleaner. But if we block this pull request and wait until it's "perfect" then we might as well wait 12 months before the redesign is done.

Having something "good" now is 100x better than waiting months until it's "perfect". Especially since the next stage is already blocked and waiting (finn-design).

@edavis10 edavis10 merged commit 7bc11f8 into chiliproject:unstable Nov 7, 2011

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment