Blueprint CSS Framework PSD in CMS

[Jacques Rentzke]

Joomla 1.6/1.7 includes the Blueprint CSS Framework in: template/atomic/css/

Is there a compelling reason to include the fixed-width.psd file from this framework in the Joomla CMS distribution?

Surely we could just include a text file instead, with a link to the file on that Framework author's site?

This PSD is adding 1,382 KB to the size of the CMS download.

I recall seeing a tracker thread about this somewhere.


Jacques Rentzke
New Web Consulting
http://twitter.com/JacquesRentzke

[Nick Savov]

+1 for getting rid of it. It should be put in docs.joomla.org in my opinion.

Kind regards,
Nick

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/joomla-dev-cms/-/GhQAXTR6VuoJ.
> To post to this group, send an email to joomla-...@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-cm...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>
>

[Ofer Cohen]

+1 for that

Ofer Cohen

[Rouven Weßling]

Do we even need the blueprint framework in the core? What's the benefit? Any designer who wants to use it has to add it to his own template anyways.

Rouven

On 16.12.2011, at 13:34, Ofer Cohen <ofer...@gmail.com> wrote:

[Matt Thomas]

+1 for removing it. No need for it to be included.

Best,

Matt

Sent from my phone that uses an open source operating system.

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

[Hannes Papenberg]

+1

[Nicholas K. Dionysopoulos]

+1 No need to have the PSD in the CMS distribution file (it's dead weight)

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

[Chad Windnagle]

Agree with the consensus here. PSD definitely shouldn't be included, and I personally don't care about the framework either.

-Chad

Regards,
Chad Windnagle

[Ofer Cohen]

Hey

My first pull request: https://github.com/joomla/joomla-cms/pull/43

Thanks you all

Ofer Cohen

[Ron Severdia]

The PSD should actually be zipped in the SRC folder, which makes it only 164k. This was done before, but apparently it has become unzipped. 

[Nicholas K. Dionysopoulos]

Ron,

Is there any good reason why someone wishing to build a site with Joomla! should have this PSD (ZIPped or not) on a web-accessible folder? I mean, is there a license restriction or other legally binding obligation for the Joomla! project? If not, there is no point having that in there. We could just include a README.php file (so that it cannot be directly served like if it were a .txt file) with instructions on where to get the framework. IMHO, if something's not part of the system, it should not be included.

Before you dismiss my remarks, please remember that not all people have 48MBps VDSL connections at their disposal. Some users are on 56KBps PSTN (real speed: 44KBps or lower) charged by the minute or, worse, on volume-charged 3G and satellite connections. Every single byte they have to transfer does matter for them.

Cheers,

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

On Friday, 16 December 2011 at 17:10, Ron Severdia wrote:

The PSD should actually be zipped in the SRC folder, which makes it only 164k. This was done before, but apparently it has become unzipped. 

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/LWmUtzdc-cYJ.

[Rouven Weßling]

Looking from a mile high (not a template developer) why is this even part of the core? And than in  a way that isn't easy to recyle for templates (so templates could expect to find the framework in a certain location).

As far as I know Atomic isn't a "site ready" template anyways, than why does it have to be bigger than all the other templates together?

Rouven

On 16.12.2011, at 16:10, Ron Severdia wrote:

The PSD should actually be zipped in the SRC folder, which makes it only 164k. This was done before, but apparently it has become unzipped. 

[Nick Savov]

Congrats on the first Pull Request, Ofer! :)

Kind regards,
Nick

> body p { margin-bottom: 0cm; margin-top: 0pt; }

> :
> +1 for removing it. No need for it to be
> included.
> Best,
> Matt
> Sent from my phone that uses an open
> source operating system. On Dec 16, 2011

> 8:07 AM, "Rouven We&szlig;ling"

> wrote:
>
> Do we even need the blueprint
> framework in the core? What's
> the benefit? Any designer who
> wants to use it has to add it to
> his own template anyways.
> Rouven
>
> On 16.12.2011, at 13:34, Ofer
>
> Cohen

[JM Simonet]

Why not add a link to Blueprint as proposed and include the whole Blueprint folder in the tests/ folder?

So this would let those that need it to test issues find it when dowloading the repo, and take off from the distribution.

JM

-- 

Please keep the Subject wording in your answers

This e-mail and any attachments may be confidential. You must not disclose or use the information contained in this e-mail if you are not the
intended recipient. If you have received this e-mail in error, please notify us immediately and delete the e-mail and all copies.

-----------------------------------------------------------

Jean-Marie Simonet  /  infograf768

Joomla Production Working group

Joomla! Translation Coordination Team 

[Jeremy Wilken]

The PSD is 161kb when zipped, and any download is being zipped. If you grab it from github, you'll see the 1,382 KB file unzipped. So its only 'adding' 161 kb to the download package, but 1,382 kb to the full weight of the unzipped package.

I would agree it doesn't make sense to provide the PSD. The license says we have to retain copyright info, but the PSD is not part of that. 

[Andrew Eddie]

I think there could be some confusion as to what needs to be achieved here.  There are two things to consider here:

1. What gets "stored" in the CMS (or Platform) repository.

2. What a user "downloads" as a distribution.

"Source" files, in general, need to stay in the repository but do not need to be in the user download.  The fix is *not* to remove seemingly unnecessary source files from the repository, but to remove them during the build process of the download.  Leaving the source files in the repository solves your problem of where to keep them if people need them (and sometimes they are needed for testing, for example in the case of uncompressed javascript files).

Just want to make that clear.

This topic also touches something that I would love to see happen and that is the ability to build different versions of the Joomla distribution with optionally more or less in the distribution - but that's really a topic for a new thread.

Regards,

Andrew Eddie

http://learn.theartofjoomla.com

[Matt Thomas]

Thanks for the clarification Andrew, this is easily forgotten and a good reminder. A good example of this is the "tests" directory.

+1 on the distribution topic. I look forward to discussing that and doing what I can to see that happen.

Best,

Matt

Sent from my phone that uses an open source operating system.

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/DzU22eB9hp0J.

[elin]

To me, the main question is how does anybody know it is there? If we are shipping it, I think it makes sense to include some information for users. For example  even the style description and template description for Atomic does not mention that is uses BluePrint or that the PSD is there or anywhere else. I just don't see how that is helpful to users. It seems to me that if you open up the black box a little bit, don't assume users have ESP, all of a sudden it goes from a liability to a feature.

Elin

[brian teeman]

the answer to that Elin is the same as with any feature, documentation ;)

[Rouven Weßling]

I hate to repeat myself, but I'd really like to know why Joomla even includes blueprint? I fail to see the benefit since we don't actually use it in the core, we just ship it.

Rouven

[Ofer Cohen]

@Rouven,

Totally agree with you.

Ofer Cohen

[Jeremy Wilken]

I also agree it doesn't make sense in the core, which is part of why I am working on Square One. Regardless, that PSD should be dropped out of the build for sure, and I don't even see a reason for it to be in the repo personally. I would make a pull request for removing it, but I'd like to know beforehand if it would pass or just be closed as well.

Its purpose is ambiguous, it might be a developer tool for someone to develop their own from or some other unexplained purpose, but irregardless you still have to setup a new template. Its undocumented (there are 7 hits on the docs for 'atomic', and none of them have any actual details). 

[Matt Thomas]

FYI, I was just checking out 2.5 Beta 1 and the PSD is in that build. 

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

[Jeremy Wilken]

The question I asked was if I made a pull request to remove it, would it be accepted? I'm not going to make a request thats just going to be denied, and I'm taking silence to mean yes.

[Matt Thomas]

Jeremy,

Ofer had already made a pull request to remove it, and it was denied.

Based on my understanding from what Andrew wrote, it should not be in the build and may need to be omitted by a build script.

Best,

Matt

Sent from my phone that uses an open source operating system.

On Dec 23, 2011 10:23 AM, "Jeremy Wilken" <gnom...@gnomeontherun.com> wrote:

The question I asked was if I made a pull request to remove it, would it be accepted? I'm not going to make a request thats just going to be denied, and I'm taking silence to mean yes.

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/pgSjYvVP3eEJ.

[Jeremy Wilken]

Ofer's commit had additional removals, including legal info. That information does need to stay, but it was unclear from that pull request issue if it was rejected because of the legal problem, or because it was rejected because nobody with merge access wants to remove it. 

This is really a separate topic for discussion, but the current process lacks clarity on how to handle a situation like this. Was the original pull request denied because it was a bad idea or because it removed legal info? If it was the latter, why wasn't it made clear to fix the pull request? If it was the former, why wasn't it made clear the PSD would remain?

Regardless, I'm just going to make the pull request but only remove the PSD and see if it goes through.

[Ron Severdia]

The reason the PSD is included is only for convenience in working with Atomic. No other reason. But Jacques original point was that it was adding 1,382 KB to the overall size. That's a valid issue, but zipping the file only makes it 164k, which isn't a burden at all. It was zipped at one point, but it's somehow become unzipped in the repo. 

So just because the handful of folks that have responded here don't need it, that isn't necessarily cause to remove it. Zipping it solves the original issue and whether or not to include in 3.0 can be the focus of another discussion if desired. 

[Ron Severdia]

The pull request was closed because it also removed legal material from Blueprint. As I posted in my earlier response, the size issue is resolved by zipping it in the repo.

It's purpose is not ambiguous and I know people that use Atomic and this PSD (I don't personally). Just because something is undocumented in Joomla doesn't mean that's cause to remove it.

[Ofer Cohen]

@Ron

164k is still big enough and I don't think is needed by most users that downloaded the Joomla package (99.9% doesn't used it). For comparison, the whole core (libraries/joomla) weight is 469k (tar.bz2). This PSD weight is third of the whole Joomla core (?!) and this is one big absurd to put it in the Joomla package.
So, IMHO, it's recommended to remove it, but this is only my 2 cent (opinion).

Best Regards,

Ofer Cohen

On 12/23/2011 11:16 PM, Ron Severdia wrote:

The reason the PSD is included is only for convenience in working with Atomic. No other reason. But Jacques original point was that it was adding 1,382 KB to the overall size. That's a valid issue, but zipping the file only makes it 164k, which isn't a burden at all. It was zipped at one point, but it's somehow become unzipped in the repo. 

So just because the handful of folks that have responded here don't need it, that isn't necessarily cause to remove it. Zipping it solves the original issue and whether or not to include in 3.0 can be the focus of another discussion if desired. 

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/I8_XlhXm548J.

[Andrew Eddie]

On 24 December 2011 08:45, Ofer Cohen <ofer...@gmail.com> wrote:
> @Ron
>
> 164k is still big enough and I don't think is needed by most users that
> downloaded the Joomla package (99.9% doesn't used it). For comparison, the
> whole core (libraries/joomla) weight is 469k (tar.bz2). This PSD weight is
> third of the whole Joomla core (?!) and this is one big absurd to put it in
> the Joomla package.
> So, IMHO, it's recommended to remove it, but this is only my 2 cent
> (opinion).

Remove it from the "download", not the repository tree.

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla 1.7 developers

[Jeremy Wilken]

Thanks Ron, you might think the purpose of Atomic is obvious and I'm not surprised you know people who have used it since you designed it. I'm simply saying the lack of any documentation or details about why its there makes it rather ambiguous to anyone who doesn't dig into code or have an intimate knowledge of Joomla. That isn't the reason to remove it, but simply a comment on if having a large PSD file (zipped or not) for an undocumented template makes sense. Joomla doesn't have to always retain everything its always had, and in this specific case this isn't code or a feature, but simply a PSD file (which if you don't have Photoshop, which isn't free) it might not be very useful).

That is a possibility Andrew, but how or who can do that? There is nothing available publicly to make changes or suggestions to the build process. This is another example of where confusion comes in, because that might be a good solution but how can anyone see that it actually happens?

We can talk until we are blue in the face about if this should be in or not, but my other question is how is the final decision made? I had asked earlier in this thread if the pull request was made again, but retaining the legal info, if it would be accepted. This thread has lots of support to remove it, and what I think is more important is how these kinds of discussions are resolved.

[Mark Dexter]

JM suggested moving it to the test folder, which keeps it available but removes it from the distro. That makes sense to me. Thoughts? Mark

[elin]

Ron,

How are users of Atomic intended to know the PSD is there?  There are a bunch of custom front end modules associated with Atomic, perhaps at least mention it there and link it? Right now the only information that is available is this sentence that I wrote "Atomic is a minimal template designed to be a skeleton for making your own template and to learn about Joomla! templating."  Perhaps you might want to write something more expansive?

Wouldn't it make sense to be able to put some useful information (such as links to documentation) in the template view not just for Atomic but for templates in general? 

Elin

[Phill Brown]

The PSD file reminds me of the example plugins scenario.  They have no use in the production code zipped or not IMHO.

Regards,

Phill Brown
M  04 2481 9754
Bathurst Software Solutions
-------------------------------------------------------------------------------------------------------------------

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/R0vOHFEZ1CsJ.

[Andrew Eddie]

It only makes sense if it's relevant to the tests, which I don't think it is. I'd suggest putting the build script on github so people can tinker with it. Jeremy sounds like he's busting at the seams to do so :)

Regards
Andrew Eddie
http://learn.theartofjoomla.com

On Saturday, December 24, 2011, Mark Dexter <dexter...@gmail.com> wrote:
> JM suggested moving it to the test folder, which keeps it available but removes it from the distro. That makes sense to me. Thoughts? Mark
>

> --
> You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

> To post to this group, send an email to joomla-...@googlegroups.com.
> To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>

--

[Nikolai Plath]

This is definitely an excellent idea. I am also eager to see something about your jenkins setup :)

[elin]

Let's keep all different kinds of users in mind. 

There are lots of people who are not even aware that there is such a thing as a separate repository---i.e. lots of webmasters with one joomla instance they are trying to make do what want--and a lot of times what they want to do is modify a template. It was really a pain for users not to have the psds available for Milky Way for example. Having that available  in context may not be that helpful for professional developers, both are helpful for the ordinary web master who has perhaps done a one click install and is of a "I can do this if I put my mind to it" cast of mind. If embedded documentation is going to be taken out, at minimum we should be looking to add it to the help screens. In fact, now that I talked myself though this I'd say wherever it is stored the link to the PSD should be embedded in the help screen for Atomic.  

I think the commenting in Atomic is excellent for the most part (I'd add a few more in the index.php) and again it is possible that it is useful to users to include a link to information about blueprint in the main css file.

Finally, in looking at this I noticed that we are not rendering the description from the XML in the templates screen. This seems to me to be a lost opportunity to provide users with valuable information such as the fact that Beez5 is designed for HTML5 or that Atomic uses BluePrint.  I'd also like to suggest that we add another optional xml item that would provide for an extended description including html to link to documention and resources such as psds and/cheatsheets (or embed a lightweight image showing the location of positions as one thought that I'm sure may users would  find helpful) that could be used on the Customise Template screen.  Finally, what if we changed the en-GB string to the customise template screen to "Customise Template" instead of TemplateName Details. To me, a link that says "Beez5 Details" doesn't imply "Here are the css and other files you are looking for that were so easy to find in 1.5."

 

Elin

[elin]

A pull request to "remove" needs to include full implementation of an alternative way for users to access that file and will need an issue in the issue tracker and full testing instructions about how that is supposed to work. 

You may want to review some of the suggestions about how that might be implemented which I made in  earlier post in this thread.

Elin

[Jeremy Wilken]

Why does this have to be so complicated? This is not a functionality, it is simply removing something that just about everyone in this thread agrees doesn't belong in the final build, a binary file that only a few people who use atomic as a base to build a template may use. It doesn't make sense in the tests, because it has nothing to do with testing. Considering I have no ability to change the build process, this is my solution.

Inside the blueprint/src folder there is a file called README, one called TUTORIAL, and I just added one called RESOURCES which contains a link to the PSD and to the cheatsheet I also removed from the repository. It is logical that if anyone is to use atomic as a base, that they will look at the source files and see the other files. 

You can see the pull request here: https://github.com/joomla/joomla-cms/pull/62 

[elin]

You can find 10 people to agree about anything with an application with 28 million downloads.  This is not only a hobby project, this is an application on which millions of people depend and just because a small group of people who happen to be active on a developer mailing list over a few week period  think that something is not useful does not mean you can break backward compatibility for millions of end users.  Refactoring means no change in functionality.. That means you must make it possible for users you don't know who are doing you don't know what to continue exactly what they were doing before hand.  Preferably making it better at the same time. If you want to refactor Atomic then I think you should do it, but it's a serious job. 

If you want to start working now on a proposal for a teaching template to replace Atomic in 3.0, which is a major release and thus allows us to break b/c in the right circumstances, you probably have about 5 months until 2.5.2 is released and 3.0 features start getting merged.

Elin

[brian teeman]

Can't we just compromise and ship the entire contents of the 

/templates/atomic/css/blueprint 

folder as an archive file

From what I can see none of the contents of that folder are used by default in atomic so there is no change in behaviour and the entire source is still present if anyone wants to unarchive it and use it. 

Note placing any of this in the css subfolder is probably not the most logical place in the first place anyway and my personal recommendation would be to name this archive file blueprintsrc.zip and place it in the /templates/atomic folder

[Ofer Cohen]

Elin,

Who use this package??

Ofer Cohen

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/QOBfhVXK_LcJ.

[Rouven Weßling]

I agree, it probably is to late to do anything before 3.0. But I still haven't seen any explanation what the benefit is of shipping all Joomla installations with the blueprint frameworks?

Rouven

[Hannes Papenberg]

We have 10 people agreeing on removing it, while just one person alone
decided to add it in the first place afaik without consulting anyone.

> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-cms/-/QOBfhVXK_LcJ.

[Hannes Papenberg]

Regarding your backwards compatibility claim: We are talking about a
file similar to a readme.txt. If your program depends on the presence of
the readme file, you are doing something ABSOLUTELY WRONG.

Hannes

Am 27.12.2011 19:21, schrieb elin:

> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-cms/-/QOBfhVXK_LcJ.

[Ofer Cohen]

Hannes

Totally agree with.

Ofer Cohen

[elin]

Ofer, no one knows, that is the point. Just like no one knows how many people use the wrapper module. I'll tell you what though, 7500 forum posts and 4 years managing the CMS tracker has taught me that there is not a single feature--not one parameter -- in the CMS that people are not using one way or another. And if you change it --- it's the people who work in the forums and who are day in day out in the tracker who are going to have to deal with the consequences, not a group of developers who are all perfectly capable  of zipping up their own packages structured how ever they find useful for their clients. 

Elin

[Jeremy Wilken]

Did anyone actually look at the pull request? Backwards compatibility doesn't even make sense when we talk about a PSD file, that Joomla does not use and was provided as a courtesy. 

I have simply changed the file from being actually downloaded with the package and made it available via a link. 

I'm sorry, but I'm done with this discussion. When I took the action to make the change, it just gets dragged under more discussion unrelated to the changes offered. I'm not going to spend time making pull requests that There is no sense in wasting hours on something that won't be changed, and this isn't even a change to any code or functionality. Expecting Joomla to retain all of the features of the past and always adding more will make Joomla more complex, less useful, and more difficult to maintain. A pull request is on the table, that is my final statement about what I believe.

[Don]

On Tuesday, December 27, 2011 4:02:48 PM UTC-5, Jeremy Wilken wrote:

Did anyone actually look at the pull request? Backwards compatibility doesn't even make sense when we talk about a PSD file, that Joomla does not use and was provided as a courtesy.

I have simply changed the file from being actually downloaded with the package and made it available via a link.

Good choice. If you'd like to use alternative file formats that are A) smaller, B) Open Source (because it matters), and C) identical in content... see the attached.

Happy holidays. And thanks for trying...

[Marius van Rijnsoever]

On Wed, Dec 28, 2011 at 2:21 AM, elin <elin....@gmail.com> wrote:
> You can find 10 people to agree about anything with an application with 28
> million downloads.

With that directory taking up 2.7 MB times and if the 28 million
downloads where unpacked once: it takes up 72 terabytes or 73828
gigabytes of disk space. Which is why I suggested it not be included
in the package before:

http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_id=8103&tracker_item_id=25761

Or I guess we can call this an economic stimulus feature for the hard
drive industry :P

[Sam Moffatt]

Hard drive industry definitely needs some stimulus given their recent
hard luck from floods in Thailand.

Cheers,

Sam Moffatt
http://pasamio.id.au

> --
> You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

[JM Simonet]

OK.
Could we get to a reasonable compromise?
we have 2 possible solutions:
1. zip the psd file only. This will reduce the size of the blueprint
folder from 1.9 Mb to 775KB, once joomla installed.
2. zip the whole blueprint folder. This will reduce the size to 388
KB, once joomla installed (I favour this one).

These 2 solutions do not reduce the size of the pack to download but
take off a lot of space on the host and reduce the time needed to
uncompress the pack when updating/installing.

What do you think?

JM

--
>Please keep the Subject wording in your answers
This e-mail and any attachments may be confidential. You must not
disclose or use the information contained in this e-mail if you are
not the
intended recipient. If you have received this e-mail in error, please
notify us immediately and delete the e-mail and all copies.
-----------------------------------------------------------
Jean-Marie Simonet / infograf768
Joomla Production Working group
Joomla! Translation Coordination Team

[Marius van Rijnsoever]

Option 3?
Remove files from build and put these files on the joomla wiki?

On Dec 28, 2011 2:32 PM, "JM Simonet" <infog...@gmail.com> wrote:

OK.
Could we get to a reasonable compromise?
we have 2 possible solutions:
1. zip the psd file only. This will reduce the size of the blueprint folder from 1.9 Mb to 775KB, once joomla installed.
2. zip the whole blueprint folder. This will reduce the size to 388 KB, once joomla installed (I favour this one).

These 2 solutions do not reduce the size of the pack to download but take off a lot of space on the host and reduce the time needed to uncompress the pack when updating/installing.

What do you think?

JM

Hard drive industry definitely needs some stimulus given their recent
hard luck from floods in Thailand.

Cheers,

Sam Moffatt
http://pasamio.id.au



On Tue, Dec 27, 2011 at 3:36 PM, Marius van Rijnsoever
<mari...@gmail.com> wrote:

 On Wed, Dec 28, 2011 at 2:21 AM, elin <elin....@gmail.com> wrote:

 You can find 10 people to agree about anything with an application with 28
 million downloads.

 With that directory taking up 2.7 MB times and if the 28 million
 downloads where unpacked once: it takes up 72 terabytes or 73828
 gigabytes of disk space. Which is why I suggested it not be included
 in the package before:


http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_id=8103&tracker_item_id=25761

 Or I guess we can call this an economic stimulus feature for the hard
 drive industry :P

 --
 You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

 To post to this group, send an email to joomla-dev-cms@googlegroups.com.
 To unsubscribe from this group, send email to joomla-dev-cms+unsubscribe@googlegroups.com.

 For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To post to this group, send an email to joomla-dev-cms@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cms+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

--

Please keep the Subject wording in your answers

This e-mail and any attachments may be confidential. You must not disclose or use the information contained in this e-mail if you are not the
intended recipient. If you have received this e-mail in error, please notify us immediately and delete the e-mail and all copies.
-----------------------------------------------------------
Jean-Marie Simonet  /  infograf768
Joomla Production Working group
Joomla! Translation Coordination Team

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To post to this group, send an email to joomla-dev-cms@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cms+unsubscribe@googlegroups.com.

[brian teeman]

Although I am one of the people proposing the compromise solution I still prefer option 3 and have yet to see any argument for it being kept in the distributed cms

[Phill Brown]

Option 3 is my personal preference.

I don't see the point in keeping it.  By the same logic of keeping it we should also keep example plugins, example components and any other learning code that has nothing to do with the *running* of the production website.

Regards,

Phill Brown
M  04 2481 9754
Bathurst Software Solutions
-------------------------------------------------------------------------------------------------------------------

On Wed, Dec 28, 2011 at 6:12 PM, brian teeman <joom...@googlemail.com> wrote:

Although I am one of the people proposing the compromise solution I still prefer option 3 and have yet to see any argument for it being kept in the distributed cms

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/w7VZhQKyzvAJ.

To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.

[Nikolai Plath]

+1 for option 3
Side by side with the example plugins and other stuff in a neat dedicated GitHub location at the finger tip of people interested in development.

[Ofer Cohen]

+1 for option 3

[Hannes Papenberg]

+1 for option 3

Am 28.12.2011 11:11, schrieb Ofer Cohen:
> +1 for option 3
>
> On Wed, Dec 28, 2011 at 11:50 AM, Nikolai Plath <joo...@nik-it.de
> <mailto:joo...@nik-it.de>> wrote:
>
> +1 for option 3
> Side by side with the example plugins and other stuff in a neat
> dedicated GitHub location at the finger tip of people interested
> in development.
>
>

> On 28.12.2011 02 <tel:28.12.2011%2002>:43, Phill Brown wrote:
>> Option 3 is my personal preference.
>>
>> I don't see the point in keeping it. By the same logic of
>> keeping it we should also keep example plugins, example
>> components and any other learning code that has nothing to do
>> with the *running* of the production website.
>>
>>
>> Regards,
>>
>> Phill Brown
>> M 04 2481 9754
>> Bathurst Software Solutions
>> -------------------------------------------------------------------------------------------------------------------
>>
>>
>>
>> On Wed, Dec 28, 2011 at 6:12 PM, brian teeman
>> <joom...@googlemail.com <mailto:joom...@googlemail.com>> wrote:
>>
>> Although I am one of the people proposing the compromise
>> solution I still prefer option 3 and have yet to see any
>> argument for it being kept in the distributed cms
>> --
>> You received this message because you are subscribed to the
>> Google Groups "Joomla! CMS Development" group.
>> To view this discussion on the web, visit
>> https://groups.google.com/d/msg/joomla-dev-cms/-/w7VZhQKyzvAJ.
>>
>> To post to this group, send an email to
>> joomla-...@googlegroups.com

>> <mailto:joomla-...@googlegroups.com>.

>> To unsubscribe from this group, send email to
>> joomla-dev-cm...@googlegroups.com

>> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

>> For more options, visit this group at
>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>>
>>
>> --
>> You received this message because you are subscribed to the
>> Google Groups "Joomla! CMS Development" group.
>> To post to this group, send an email to
>> joomla-...@googlegroups.com

>> <mailto:joomla-...@googlegroups.com>.

>> To unsubscribe from this group, send email to
>> joomla-dev-cm...@googlegroups.com

>> <mailto:joomla-dev-cm...@googlegroups.com>.

>> For more options, visit this group at
>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To post to this group, send an email to
> joomla-...@googlegroups.com

> <mailto:joomla-...@googlegroups.com>.

> To unsubscribe from this group, send email to
> joomla-dev-cm...@googlegroups.com

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

[Andrea Tarr at Tarr Consulting]

I'd go with option 3 as well, as long as the only place is not in github. Unlike the example plugins, the psd is of interest to non-programmers (which is why you see very few people defending it on this list). Github is not friendly to non-programmers. There should be a place in the wiki where it is available and that information should be in the description of the template, not buried in a readme file.

There are times that I would have killed for access to a psd file. Having it available in some fashion is important.

Andy

Andrea Tarr

Tarr Consulting

www.tarrconsulting.com

[TJ Baker]

+1 for option 3.

[Mindaugas Girdvainis]

+1 for option 3

> >> For more options, visit this group athttp://groups.google.com/group/joomla-dev-cms?hl=en-GB.

[Gerlof]

+1 option 3

On Dec 28, 7:32 am, JM Simonet <infograf...@gmail.com> wrote:
> OK.
> Could we get to a reasonable compromise?
> we have 2 possible solutions:
> 1. zip the psd file only. This will reduce the size of theblueprint
> folder from 1.9 Mb to 775KB, once joomla installed.

> 2. zip the wholeblueprintfolder. This will reduce the size to 388

> KB, once joomla installed (I favour this one).
>
> These 2 solutions do not reduce the size of the pack to download but
> take off a lot of space on the host and reduce the time needed to
> uncompress the pack when updating/installing.
>
> What do you think?
>
> JM
>
>
>
>
>
>
>
>
>
> >Hard drive industry definitely needs some stimulus given their recent
> >hard luck from floods in Thailand.
>
> >Cheers,
>
> >Sam Moffatt
> >http://pasamio.id.au
>
> >On Tue, Dec 27, 2011 at 3:36 PM, Marius van Rijnsoever

> ><mariu...@gmail.com> wrote:

> >>  On Wed, Dec 28, 2011 at 2:21 AM, elin <elin.war...@gmail.com> wrote:
> >>>  You can find 10 people to agree about anything with an application with 28
> >>>  million downloads.
>
> >>  With that directory taking up 2.7 MB times and if the 28 million
> >>  downloads where unpacked once: it takes up 72 terabytes or 73828
> >>  gigabytes of disk space. Which is why I suggested it not be included
> >>  in the package before:
>

> >>http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEd...

[TobsBobs]

+1 option 3

[elin]

This would be my proposal for how to handle (see the template screen for Atomic).

http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=27577

As for Jeremy's question of why things are complicated, they are complicated because we try to do them in a thorough way that involves thinking about the whole picture and prepares for the future rather than take the quick and easy.

Elin

[Hannes Papenberg]

How does that change the issue at hand that we have a large file in our
downloadpackage that is useless and that every newbie uploads that
unnecessary file?

And why are we linking to a PSD in our Subversion, considering that we
are thinking about dropping subversion in favour of git? BTW: Our
Blueprint (1.0) is outdated, the current version is 1.0.1 and I'm also
questionening why we have the complete blueprint framework unzipped in
our source tree. If you want to keep it, zip it and if someone needs it,
he can unzip it, but considering the issues that quite a few people have
with uploading large amounts of small files, we should try our best to
reduce the number of files and not unnecessarily increase it.

Hannes

> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.

> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-cms/-/KtpjQsm6_kkJ.

[elin]

Please hannes, it's a POC, in case you aren't aware, changing a string is very very simple and we are continuing to maintain a copy of our  repo anyway because I can't upload a psd to the docs site. Obviously if this solution works for people we can take the file out. 

I'm not sure whether you are just acting out on some long running hostility to the PLT or Ron or you are just in a crummy mood but that is not a helpful post when I'm the first person  to actually offer a solution that would work for all template defvelopers who wish to provide access to additional files  instead of just talk.  

Elin

[Hannes Papenberg]

Elin,
I'm neither crumpy nor am I acting out my hostility towards the PLT or
Ron. I'm annoyed by a discussion that has been going on for way to long
with (according to my android) now 67 messages where none of them gave a
good reason to keep blueprint at all. (besides "Someone put it in, so we
need to keep it". With the same reasoning I could demand that the
advanced routing mode for core component routers be put back in that
someone broke in 1.7.)

There were messages proposing to remove the PSD or at least zip it and I
proposed to zip the complete framework. I don't understand why we have
to ship an unzipped version of a framework that is not maintained by us
and is also not used by us and which is freely available for everybody
to download on the original developers website. (in an updated version even)

I'm all for backwards compatibility and I encourage everyone to create
backwards compatible improvements to the code, but the CMS maintainers
have been absolute paranoid about backwards compatibility, often enough
in a way that made me wonder if they even looked at the proposed code.
This in the end means that we have very little innovation in x.1 and x.5
versions and the only real change can be done in x.0 releases, which
makes me wonder why we have a 6 months release cycle in the first place.

But regardless of that last paragraph, we are talking about a graphics
file here. No extension will break if we remove it from the build and
repository. The worst that could happen is a small box with a red X on a
website where someone included the file as an image. The most reasonable
thing to do would be to remove the PSD (or even the whole src folder)
and instead place a link to the blueprint framework in the description
with a hint that there is more on the developers website. Putting the
PSD on our server isn't really helpfull either, since it means that we
have to keep that file up to date.

Someone could also ask why we are endorsing a CSS framework that we are
not using ourselfs. Either we provide real help how to use it and put a
bunch of documentation into our wiki or we point to a list of CSS
frameworks or we remove it completely.

Written way to much, gonne shut up now.

Hannes

tl;dr: Opinions by people were very clear, proposed solution is not
satisfactory.

> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-cms/-/wwCU4c1L9xQJ.

[Chad Windnagle]

I haven't sensed any hostility coming from Hannes.

In any case, I too am totally mystified as to why the framework was included. Could someone point to a patch or previous discussion that can be considered the 'decision point' when it was decided to include these files? I'd just like to read up on when this change was introduced. Thanks. 

-Chad

Regards,
Chad Windnagle

[brian teeman]

You wont find one Chad so dont try looking. This code was arbitrarily committed by a single member of the PLT - it should be noted that this is the same person who is the only one who has commented that this should remain.

[Jennifer Marriott]

Just a thought to consider.  Using Blueprint as a css framework in a teaching template for 1.6 goes back two years because I think it was committed sometime in Dec of 2009?  Everyone can go around and around on their opinions of it now, but surely it is much easier to be hyper critical of the decision with 2 years of hindsight on it.

Just like many bits of code I think at one time there was an idea to build a template framework for the CMS using Blueprint.   It was a great idea that most likely just fell by the wayside as a lot of great ideas do.  I remember the discussions around that from the time not only on the J lists but also on the Blueprint lists.

It is a great teaching example of a css framework and how to use one to build a Joomla template.  It was a great idea at the time, and what is great is people took the time and did their best to implement it.  I think it is still a great idea. (fair disclosure Blueprint is my personal favorite for css frameworks, so I am biased in that regard.)

Surely in the big scope of the 2.5 release there are more important issues facing the road to stability than a giant conversation on how a PSD takes up space and what should and should not be compressed or included. 

Elin has come up with one solution for people to be able to remove the PSD after installation if people so choose and it is a good idea.  I think Ron said that originally the source folder was zipped up and most likely should be zipped up again which is also good.  Another good idea floated is to inform in the sample data, and in the template description itself (if no sample data installed) to link to the PSD on an outside source.   All are good ideas.

The only thing that has be seriously considered is that current users of the Atomic template aren't adversely affected, and that current and future users of Atomic have all the available information that they need to utilize the template fully and learn.

I hope to see the same enthusiasm for commenting shown in this thread on some of the more pressing issues that affect functionality, bugs or issues and getting 2.5 to be the best release it can be.

Happy New Year everyone - be safe and best wishes!  Thanks for being a great community! 

[Chad Windnagle]

Hi Jennifer, thanks for that back story info! 

You explain that it was once thought that it might be used more extensively, but that apparently hasn't happened. Well as you say, great ideas sometimes just come at the wrong time. But that doesn't mean we should subject ourselves to 'living with it' because a decision was made in the past. We can change our minds for the better. No rule dictates that we're unable to change our minds, particularly when on the same topic we seem to have done so already.

I don't believe this is a case of 'hind-sight being 20/20', since in this case (I believe) we're at a point where we can make a good change that helps everyone.

Cheers all, happy new year. 

Regards,
Chad Windnagle

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/cCYckPXznjgJ.

[Jennifer Marriott]

Hey Chad,

It can be totally removed in 3.0 if that is what people want/decide that it is a decision for the better.  :)

The fair and well thought out  thing to do right now is to try to do what people want (make it smaller in footprint and take up less space, which seems to be the only complaint I can see) while making sure those that currently use it aren't affected adversely and that those that may chose to use it during the life of 2.5 have the information they need to effectively utilize it. 

There is nothing stopping anyone from coming up with an idea that serves the best of both worlds (smaller yet still effective as a teaching/learning template).  Numerous suggestions have already been made.  It will be great to see one or any combination of them implemented.  Then people can hopefully move on to bugs, stability and usability :) and lay this issue to rest until decision start happening for 3.0.

[Steve]

Fortunately, for those mentioning a lack of stats to help make this decison, there are some indirect ways to gauge the interest in Atomic:

• Topics in the Atomic forum: 31
• Total number of posts mentioning Atomic in the 1.6 / 1.7 template forum: 59
  
• Number of blog posts on the web about Atomic: 1 by Hagen Graf, a second by the template's author and a pretty negative write-up by OpenSourceCMSPro.
• The Atomic page on the Docs site: http://docs.joomla.org/Atomic
• Other mentions of Atomic on the Docs site: 0
• Mentions in the Joomla books on my shelf: One sentence in each book (except mine which gave it six sentences and a screenshot)