13
Quote:
doubtful...but fixing the base of the problem (mod templates) is better than rigging the current workaround (template overriding every module)
Quote:
depends who you ask
Quote:
huh? No, I'm saying that the problem with _themes_ are that most module _templates_ aren't coded to coincide with _themes_ and that using Morpho as a _template_ for _themes_ isn't a sensible solution. Nor is it sensible to make every _theme_ effectively a _template_ for a new _theme_ for some new designer to learn from. But changing how _themes_ are formatted and how module _templates_ are written is more sensible...just not the easy solution that everyone seems to be looking for.
In a nutshell, I understand that kris is saying Morpho should be a template for all themes so new designers can learn from them...i disagree with that. And I'm also bringing up the point that doing that will not solve the problem of modules looking horrible with pretty much any theme that is more than "your-basic-theme".
- module developpers will be agree with new rules ?
doubtful...but fixing the base of the problem (mod templates) is better than rigging the current workaround (template overriding every module)
Quote:
- design team have the right to force them ?
depends who you ask
Quote:
You are mixing themes and templates !
And that's not the same.
huh? No, I'm saying that the problem with _themes_ are that most module _templates_ aren't coded to coincide with _themes_ and that using Morpho as a _template_ for _themes_ isn't a sensible solution. Nor is it sensible to make every _theme_ effectively a _template_ for a new _theme_ for some new designer to learn from. But changing how _themes_ are formatted and how module _templates_ are written is more sensible...just not the easy solution that everyone seems to be looking for.
In a nutshell, I understand that kris is saying Morpho should be a template for all themes so new designers can learn from them...i disagree with that. And I'm also bringing up the point that doing that will not solve the problem of modules looking horrible with pretty much any theme that is more than "your-basic-theme".
14
Quote:
^^ that would be unneeded if modules were templated uniformly.
(that already exist in morphogenesis)
^^ that would be unneeded if modules were templated uniformly.
15
Quote:
Again, it's not my job or any other themer's job to teach your new designers...WRITE DOCUMENTATION...theres your solution. Not "hey guys lets make EVERY THEME a tutorial for new users"...come on, are you serious? I couldn't care less if people "understand" my code, I shouldnt have to care, I'm theming, not writing a tutorial. However, header.html, and footer.html would make sense; i've actually been doing that in my new (unreleased) themes anyway. You can break your themes down as much as you want, that's not the point, the point is you shouldn't force people to do it just so all themes can be tutorials...the only reason to do what is being done is to avoid making theme documentation.
Quote:
Yes, but if you try and standardize _all_ of the code all your doing is making different flavors of the same theme. Bad code is trying to be standardized...that's why I have a problem with it. "More code" does not equal "better code" it just equals more hassle for designers....There's so many better ways to do what kris is trying to do that don't require everyone and their brother theming with his code and his code alone. One better way being USE WRAPPERS which I have repeated over and over again.
why not split theme.html to some more html files and force every developers to follow it. then every body can understand themes.
Again, it's not my job or any other themer's job to teach your new designers...WRITE DOCUMENTATION...theres your solution. Not "hey guys lets make EVERY THEME a tutorial for new users"...come on, are you serious? I couldn't care less if people "understand" my code, I shouldnt have to care, I'm theming, not writing a tutorial. However, header.html, and footer.html would make sense; i've actually been doing that in my new (unreleased) themes anyway. You can break your themes down as much as you want, that's not the point, the point is you shouldn't force people to do it just so all themes can be tutorials...the only reason to do what is being done is to avoid making theme documentation.
Quote:
- all developers use .mainmenu and .usermenu because XOOPS Core use them in system module. so XOOPS Core force theme developers to put this codes in the css.
i think what kris trying to do is this kind of standard codes.
Yes, but if you try and standardize _all_ of the code all your doing is making different flavors of the same theme. Bad code is trying to be standardized...that's why I have a problem with it. "More code" does not equal "better code" it just equals more hassle for designers....There's so many better ways to do what kris is trying to do that don't require everyone and their brother theming with his code and his code alone. One better way being USE WRAPPERS which I have repeated over and over again.
16
Quote:
No, I think it would be a bit hypocritical of me to join a team that forces ideas I completely disagree with. I was just wondering who exactly it was, thanks for the list.
If you want to make party of the Design Team, you can make a candidature near the XOOPS council or of myself.
No, I think it would be a bit hypocritical of me to join a team that forces ideas I completely disagree with. I was just wondering who exactly it was, thanks for the list.
17
heres a little random question I've been wondering about.
Who exactly is the "Design Team" we're hearing so much about?
Who exactly is the "Design Team" we're hearing so much about?
18
Check your php/apache error logs. No one is going to be able to provide you an answer without a little bit more detail on what it's doing.
19
Quote:
Yes! Bingo! Thank you. Will_H and I were having a discussion about that a while ago...Developers can create a great theming engine and base templates...but designers have to use them every day. I think obtaining a bit more input from the actual themers would be a good idea before implementing things that largely effect them.
which should have been oriented by designers instead of developers.
Yes! Bingo! Thank you. Will_H and I were having a discussion about that a while ago...Developers can create a great theming engine and base templates...but designers have to use them every day. I think obtaining a bit more input from the actual themers would be a good idea before implementing things that largely effect them.
20
Quote:
Depends who you ask...I would do it how evo does it:
In a theme I would define OpenTable, CloseTable functions and use that as a wrapper. For example, the OpenTable function would be the top and left of my block, the CloseTable function would be the right and bottom of my block.
Then any module dev could call those functions and throw their content in the middle and format it generically with .row1 .row2 .even .odd td,tr,hr,div...etc which i would have in my style.css because every module would use those same classes. And the theme would still look how i meant it to look in any module.
@marco theres my contribution
How could it be done ?
Depends who you ask...I would do it how evo does it:
In a theme I would define OpenTable, CloseTable functions and use that as a wrapper. For example, the OpenTable function would be the top and left of my block, the CloseTable function would be the right and bottom of my block.
Then any module dev could call those functions and throw their content in the middle and format it generically with .row1 .row2 .even .odd td,tr,hr,div...etc which i would have in my style.css because every module would use those same classes. And the theme would still look how i meant it to look in any module.
@marco theres my contribution
Login
Search
Recent Posts
Who's Online
Donat-O-Meter
| Stats | |
| Goal: | $100.00 |
| Due Date: | Apr 30 |
| Gross Amount: | $0.00 |
| Net Balance: | $0.00 |
| Left to go: | $100.00 |
 |
|