Switching themes in modules
I have written a smallish module (http://drupal.org/project/manage) to provide a separate theme for administration pages. It works nicely by setting $custom_theme and providing some settings for a custom menu and selecting on which pages to apply the theme switch. I learned how to do all this by looking at the blocks.module. This is also the catch. It doesn't work nicely with blocks.module because selecting the current theme is really done through a set of global variables ($theme, $custom_theme). Once one module has overridden $custom_theme, the knowledge about the original theme (user-specific or standard) is lost. I currently solve this by excluding admin/block pages from the theme replacement. I have considered to introduce some kind of stack of overridden themes, but as this would affect at least system.module, blocks.module, theme.inc so I wanted to discuss this here first. Is anybody working on this theme selection right now? This might fall into the realm of Adrian's overhaul of the theming system. Cheers, Olav -- Dr. Olav Schettler (Geschäftsführer) contAire GmbH ___________________________________________ Arndtstr. 12 | D-50676 Köln | Germany Office: +49 221 4204757 | Mobile: +49 175 2249141 olav.s@contaire.de | Yahoo! olav ___________________________________________ Please visit our website http://www.contaire.de/
Hi, I have done a bit of work in this area for a client, and basically what happens is that you can change the $custom_theme at time time up until the first theme() is called. When the first theme() is called it will run the theme_init() which will load the theme. So it will look at $custom_theme and other places and load it. The problem that I found a lot of contrib modules during hook_menu() will call theme() to do something that is not theme related or add the css to the page, and the theme will be set. The problem is with a lot of contrib modules calling theme() far too early. Gordon. Olav Schettler wrote:
I have written a smallish module (http://drupal.org/project/manage) to provide a separate theme for administration pages. It works nicely by setting $custom_theme and providing some settings for a custom menu and selecting on which pages to apply the theme switch.
I learned how to do all this by looking at the blocks.module. This is also the catch. It doesn't work nicely with blocks.module because selecting the current theme is really done through a set of global variables ($theme, $custom_theme). Once one module has overridden $custom_theme, the knowledge about the original theme (user-specific or standard) is lost.
I currently solve this by excluding admin/block pages from the theme replacement. I have considered to introduce some kind of stack of overridden themes, but as this would affect at least system.module, blocks.module, theme.inc so I wanted to discuss this here first.
Is anybody working on this theme selection right now? This might fall into the realm of Adrian's overhaul of the theming system.
Cheers, Olav
On 20 Jun 2006, at 8:30 AM, Gordon Heydon wrote:
I have done a bit of work in this area for a client, and basically what happens is that you can change the $custom_theme at time time up until the first theme() is called.
maybe during 4.6. Not many modules actually call theme() during _init, which is where most of the theme switching happens (hell, even in config files) Multi theme switching is just plain broken in 4.7 due to the blocks/ region configuration. Which is the reason the sections module hasn't been updated (for instance). Hence, my suggested changes to the theme/block configuration (implementing a new grouped configuration for theme/region/theme settings and switching between those instead) -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Gordon Heydon wrote:
Hi,
I have done a bit of work in this area for a client, and basically what happens is that you can change the $custom_theme at time time up until the first theme() is called.
When the first theme() is called it will run the theme_init() which will load the theme. So it will look at $custom_theme and other places and load it.
The problem that I found a lot of contrib modules during hook_menu() will call theme() to do something that is not theme related or add the css to the page, and the theme will be set.
The problem is with a lot of contrib modules calling theme() far too early.
right. i wish it were not possible mistakenly initialize the theme. we should fix this in the theme api. a good start would be to rename all functions that begin with theme_ that *aren't* intended to be themeable functions. theme_add_style(), theme_blocks(), ... @all - the right way to add a custom stylesheet from a module is theme_add_style().
@all - the right way to add a custom stylesheet from a module is theme_add_style().
TDobes offers convincing arguments that we should instead use <?php // Modules should do: drupal_set_html_head(theme('stylesheet_import', base_path() . drupal_get_path('module', 'mymodule') .'/mymodule.css')); ?> see http://drupal.org/node/52508#comment-79259
Nedjo Rogers wrote:
@all - the right way to add a custom stylesheet from a module is theme_add_style().
TDobes offers convincing arguments that we should instead use
<?php // Modules should do: drupal_set_html_head(theme('stylesheet_import', base_path() . drupal_get_path('module', 'mymodule') .'/mymodule.css')); ?>
I'm not sure -- someone can check -- but since TDobes wrote that, I think the output of theme_get_style was reversed. I believe this is the case since at one point I'd hacked my template.php on a site to do just that because modules using theme_add_style screwed things up. After an updated, I had to remove that hack; turned out the module was still using theme_add_style.
Nedjo Rogers wrote:
@all - the right way to add a custom stylesheet from a module is theme_add_style().
TDobes offers convincing arguments that we should instead use
<?php // Modules should do: drupal_set_html_head(theme('stylesheet_import', base_path() . drupal_get_path('module', 'mymodule') .'/mymodule.css')); ?>
well, i have two minor objections to this - theme_stylesheet_import is not intended as a themeable function. you should call it directly, not indirectly through theme(). the problem with calling through theme() is that you initialize the theme layer which should be done at the latest possible stage. doing it in hook_menu() hurts theme switching based on organic group., sections, path, taxonomy, etc. - it is wordy compared to just theme_add_style(). presumably that could be fixed with another theme function or reworking existing ones
Hi, Nedjo Rogers wrote:
@all - the right way to add a custom stylesheet from a module is theme_add_style().
TDobes offers convincing arguments that we should instead use
<?php // Modules should do: drupal_set_html_head(theme('stylesheet_import', base_path() . drupal_get_path('module', 'mymodule') .'/mymodule.css')); ?>
If you are using this from hook_menu() do not use the theme() as it will initialise the theme, and you will not be able to change it. Gordon.
see http://drupal.org/node/52508#comment-79259
!DSPAM:1000,44997ed5176845696618876!
Op dinsdag 20 juni 2006 08:14, schreef Olav Schettler:
I have written a smallish module (http://drupal.org/project/manage) to provide a separate theme for administration pages. It works nicely by setting $custom_theme and providing some settings for a custom menu and selecting on which pages to apply the theme switch.
May I ask why you did not use sections.module? you have developed a duplicate of that module. Bèr
Bèr Kessels wrote:
Op dinsdag 20 juni 2006 08:14, schreef Olav Schettler:
I have written a smallish module (http://drupal.org/project/manage) to provide a separate theme for administration pages. It works nicely by setting $custom_theme and providing some settings for a custom menu and selecting on which pages to apply the theme switch.
May I ask why you did not use sections.module? you have developed a duplicate of that module.
Bèr
In the link above, he already answers that question: "This module can provide a lightweight solution to taxonomy_theme.module or sections.module if you only want to switch to a single different theme based on URL paths."
Op woensdag 21 juni 2006 14:32, schreef Moshe Weitzman:
In the link above, he already answers that question: "This module can provide a lightweight solution to taxonomy_theme.module or sections.module if you only want to switch to a single different theme based on URL paths."
I read that. Still I see no difference. Sections is very small. The amount of code in both modules is not much different. Don't get me wrong: I am all for choice. But two modules that do almost exactly the same, in almost exactly the same way, with almost the exact same code are IMO a waste of time. But the reason why I wrote this in the first place is because If someone would've mailed me with a plan, or a question, or a comment that sections is "too big", or "too complex" for his or her needs, I would love to look into a concept to make it smaller, simpler, easier, or more usefull for more people. It makes me wonder if I am such a stubborn person, that people don't want to work on a module bearing my name. Or that it is so crappy that I should rather consider removing it. It is hard enough to find any modules as it is, let alone if for all modules there are two, three four alternatives that have the EXACT same problems and appear to do the exact same. The lightweight module, moreover, has the same issue as sections module, why it cannot be released, namely the fact that 4.7's per-theme blocks are a PIAS when switching. If that person wouldve spent time on a solution for that instead, we would have had one module that actually works by now. Instead of two that are useless because of some critical issue. Bèr
On 22 Jun 2006, at 21:38, Bèr Kessels wrote:
In the link above, he already answers that question: "This module can provide a lightweight solution to taxonomy_theme.module or sections.module if you only want to switch to a single different theme based on URL paths."
I read that. Still I see no difference. Sections is very small. The amount of code in both modules is not much different.
Don't get me wrong: I am all for choice. But two modules that do almost exactly the same, in almost exactly the same way, with almost the exact same code are IMO a waste of time.
Is that why you forked core's upload.module ? ;-)
It is hard enough to find any modules as it is, let alone if for all modules there are two, three four alternatives that have the EXACT same problems and appear to do the exact same. The lightweight module, moreover, has the same issue as sections module, why it cannot be released, namely the fact that 4.7's per-theme blocks are a PIAS when switching. If that person wouldve spent time on a solution for that instead, we would have had one module that actually works by now. Instead of two that are useless because of some critical issue.
-- Dries Buytaert :: http://www.buytaert.net/
On Thu, 2006-06-22 at 23:59 +0200, Dries Buytaert wrote:
On 22 Jun 2006, at 21:38, Bèr Kessels wrote:
In the link above, he already answers that question: "This module can provide a lightweight solution to taxonomy_theme.module or sections.module if you only want to switch to a single different theme based on URL paths."
I read that. Still I see no difference. Sections is very small. The amount of code in both modules is not much different.
Don't get me wrong: I am all for choice. But two modules that do almost exactly the same, in almost exactly the same way, with almost the exact same code are IMO a waste of time.
Is that why you forked core's upload.module ? ;-)
No that would be stubborn, and core's upload.module being a pita. :) Same reason I started rewriting the file handling from the ground up. I can't think of a graceful upgrade path. I can think of a migration path to something new though. RFC: http://darrelopry.com/docs/filesystem
On 23 Jun 2006, at 00:14, Darrel O'Pry wrote:
No that would be stubborn, and core's upload.module being a pita. :) Same reason I started rewriting the file handling from the ground up. I can't think of a graceful upgrade path. I can think of a migration path to something new though.
Is that potential core material? -- Dries Buytaert :: http://www.buytaert.net/
On 6/22/06, Dries Buytaert <dries.buytaert@gmail.com> wrote:
On 23 Jun 2006, at 00:14, Darrel O'Pry wrote:
No that would be stubborn, and core's upload.module being a pita. :) Same reason I started rewriting the file handling from the ground up. I can't think of a graceful upgrade path. I can think of a migration path to something new though.
Is that potential core material?
Yes, IMHO. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com
Dear SoC mentors: important information below! All others: sorry for the cross posting and noise, but it is urgent that this information gets read by the right people and some are not responding to their SoC emails. Hi, folks! If you haven't heard the message yet, the mid-term evaluations are now up on Google. You should be able to find them here: http:// code.google.com/soc/mentor.html - the "primary" mentor for each student should be filling these out. The goal of this is not to say whether or not the student is "half- way" through their project but whether they're making sufficient progress that you believe they will reasonably be able to finish (and if you feel the opposite, Robert and myself should already know about this!) Please note that these surveys have a direct impact on whether or not students get paid and are able to continue participating in the program.. **make sure you fill out your surveys** because no survey == student gets dropped and does not get paid for their efforts. The full spiel is available here: http://groups.google.com/group/ Summer-Administrators-2006/browse_thread/thread/357d2d6a615372be Once you have filled out your survey, please either post to the groups site or let Robert/I know so that we can check you off the list. If you feel comfortable, also post your status report to the group (though remember to mark the post "Private"). http:// groups.drupal.org/google-summer-of-code-2006 Thanks, everyone... Angie (and Robert)
On Fri, 2006-06-23 at 07:44 +0200, Dries Buytaert wrote:
On 23 Jun 2006, at 00:14, Darrel O'Pry wrote:
No that would be stubborn, and core's upload.module being a pita. :) Same reason I started rewriting the file handling from the ground up. I can't think of a graceful upgrade path. I can think of a migration path to something new though.
Is that potential core material?
That would be my aim. I want to develop it in contrib and get feedback on the API's and their usefulness first, but I'm building it with an upgrade path for the data from the current file api. Anyways I'm running with it for myself at this point, so if you have any opinions or requirements speak now or forever hold your peace. I'm not going to be to willing to re think it after I've starting getting the storage driver part finished up. I've already roughed in large chunks of it.
Hello Dries, Pleeease next time save charts to PNG (or, at least, GIF) instead of JPG, 'cause then images will be approx. TEN TIMES smaller in KB-size. Don't take offence, it's just a minor note. Best regards, Dmitry mailto:dgukov@gmail.com
Op vrijdag 23 juni 2006 00:14, schreef Darrel O'Pry:
Same reason I started rewriting the file handling from the ground up. I can't think of a graceful upgrade path. I can think of a migration path to something new though.
FWIW: I am talking to Darrel over mail, and investigating how to merge some of my work into his, so that we can continue on one module/project. Bèr
Op donderdag 22 juni 2006 23:59, schreef Dries Buytaert:
Is that why you forked core's upload.module ?
It was not a fork. It was a complete rewrite ground up. But I started off with upload.module. A diff will show you that only five tiny chunks remain intact and that all the other stuff was changed. Not only large clean ups (really: upload.module has "functions" that are like 200 lines big!!), but also removing lots of stuff from upload into file.inc where it belongs. Not only a complete overhaul of the file.inc and the upload.module, but also introducing a FAR more modular and flexible file system! Besides, And that is the main reason for chiming back in, I *did* work on upload.module. I maintained a patch for months that allowed SIMPLE inline file handling. That patch got loads of "heavyweight" positive votes. Yet somehow you (Dries) did not want it. What am I supposed to do then? I am not a fan of sending bribes, nor of sending horse heads, when a (badly needed) patch is refused. That made me decide that a) pulling something out of core to develop on in in a "free", pragmatic way (as in: not maintaining broken patches for ages, but working on it over/with CVS), and b) rewriting stuff from ground up, is the way to go. Not fixing tiny pieces of old code line by line, patch per patch. I think the amount of cruft and inconsistencies in core show us that the iterative way of working does not work well enough. I hoped that pulling something out of core, and deconstructing (aka rewriting) it completely did work. Because by the time it is stable and finished, it most probably is far better then the stuff in core will ever be. In far less time, with far less patch-rewritings, etc. I know people disagree with me. I know a lot of people think "well then: fix it". I know that even more people think "sigh, there he goes again". But tell me: why the ## do we have so much stuff in core, from which everyone agrees that it should not be there, or that it badly needs a rewrite? Yet I hardly ever see patches/issues like "Complete clean up of hook_user", or "removed archive.module from core", or "complete clean up of the upload.module code", get trough, or being made at all? The only answer I can give is: "Drupal is too large, for the way it works now". I don't have a ready made solution either, but the fact that we have so much cruft in core, so much good patches in the queues collecting dust, and the fact that we still don't have a proper media handling system shows that this is somehow right! In any case, this very patch, the reason for this "fork", which was never a fork, made me loose a lot of confidence in Drupal and its way of working. Bèr
I'm a newcomer to the drupal culture here, and it looks to me also that in some ways Drupal is too large for the way it works now (and presumably that's part of the motivation for Dries' road trip). Kind of a no-brainer in a way, all successful organizations of people have to go through painful changes in how they work as they grow. My only input into this particular thread is that big email lists aren't a very productive forum for this kind of conversation and I hope that the core people who are responsible for the next steps can be given the support to do whatever they need to ('cause someone's not going to be happy, but it's inevitable), and that they let the rest of us know in good time... - Alan On 6/24/06, Bèr Kessels <ber@webschuur.com> wrote:
I know people disagree with me. I know a lot of people think "well then: fix it". I know that even more people think "sigh, there he goes again". But tell me: why the ## do we have so much stuff in core, from which everyone agrees that it should not be there, or that it badly needs a rewrite? Yet I hardly ever see patches/issues like "Complete clean up of hook_user", or "removed archive.module from core", or "complete clean up of the upload.module code", get trough, or being made at all? The only answer I can give is: "Drupal is too large, for the way it works now". I don't have a ready made solution either, but the fact that we have so much cruft in core, so much good patches in the queues collecting dust, and the fact that we still don't have a proper media handling system shows that this is somehow right!
In any case, this very patch, the reason for this "fork", which was never a fork, made me loose a lot of confidence in Drupal and its way of working.
Bèr
-- Alan Dixon, Web Developer http://alan.g.dixon.googlepages.com/
A slightly different approach to this kind of problem is to let your theme do all the work - i.e., don't switch themes, just make your existing theme a little more expansive. In fact, the civicspace theme does exactly this - it provides a different look for it's admin pages. You can do this by just some tweaks of your theme, checking what arg(0) is for example, or you can be more aggressively different and use the _phptemplate_variables to make use of a different page template. I think that the complexity of the discussion that this posting generated is an indicator that modules should avoid trying to fiddle with themes. My understanding of the drupal code is that modules are supposed to create and modify the content in a structured model, and let the theme render it. If modules want to enable sites to provide different looks for pages within their purvue, I think it makes more sense for them to offer some useful themeing functions. I think that makes more sense both from a code point of view, as well as a useability perspective - switching themes on a user could be extremely disorienting, whereas if you're just working within a single theme, the theme can be more consistent (obviously, it doesn't have to, but at least the responsibility is clearer). As an example of the risks of theme switching, look here: http://drupal.org/node/65801 - Alan On 6/20/06, Olav Schettler <olav.schettler@contaire.de> wrote:
I have written a smallish module (http://drupal.org/project/manage) to provide a separate theme for administration pages. It works nicely by setting $custom_theme and providing some settings for a custom menu and selecting on which pages to apply the theme switch.
I learned how to do all this by looking at the blocks.module. This is also the catch. It doesn't work nicely with blocks.module because selecting the current theme is really done through a set of global variables ($theme, $custom_theme). Once one module has overridden $custom_theme, the knowledge about the original theme (user-specific or standard) is lost.
I currently solve this by excluding admin/block pages from the theme replacement. I have considered to introduce some kind of stack of overridden themes, but as this would affect at least system.module, blocks.module, theme.inc so I wanted to discuss this here first.
Is anybody working on this theme selection right now? This might fall into the realm of Adrian's overhaul of the theming system.
Cheers, Olav
-- Dr. Olav Schettler (Geschäftsführer) contAire GmbH ___________________________________________ Arndtstr. 12 | D-50676 Köln | Germany Office: +49 221 4204757 | Mobile: +49 175 2249141 olav.s@contaire.de | Yahoo! olav ___________________________________________ Please visit our website http://www.contaire.de/
-- Alan Dixon, Web Developer http://alan.g.dixon.googlepages.com/
I think you've hit the nail on the head here. This is stuff I personally feel should be relegated to the theme engine or the theme itself. I do a lot of hacks within the theme for a particular site. When you really get down to it we're discussing how to handle presentation, which isn't intregral to the content management process, but is integral to the user experience. A theme switch module which allowed you to choose theme engines/themes based on the view being generated may be fun, but how often on a site do you really need this level of abstraction in the presentation layer? On Thu, 2006-06-22 at 11:13 -0400, Alan Dixon wrote:
A slightly different approach to this kind of problem is to let your theme do all the work - i.e., don't switch themes, just make your existing theme a little more expansive. In fact, the civicspace theme does exactly this - it provides a different look for it's admin pages. You can do this by just some tweaks of your theme, checking what arg(0) is for example, or you can be more aggressively different and use the _phptemplate_variables to make use of a different page template.
I think that the complexity of the discussion that this posting generated is an indicator that modules should avoid trying to fiddle with themes. My understanding of the drupal code is that modules are supposed to create and modify the content in a structured model, and let the theme render it. If modules want to enable sites to provide different looks for pages within their purvue, I think it makes more sense for them to offer some useful themeing functions.
I think that makes more sense both from a code point of view, as well as a useability perspective - switching themes on a user could be extremely disorienting, whereas if you're just working within a single theme, the theme can be more consistent (obviously, it doesn't have to, but at least the responsibility is clearer).
As an example of the risks of theme switching, look here: http://drupal.org/node/65801
- Alan
On 6/20/06, Olav Schettler <olav.schettler@contaire.de> wrote:
I have written a smallish module (http://drupal.org/project/manage) to provide a separate theme for administration pages. It works nicely by setting $custom_theme and providing some settings for a custom menu and selecting on which pages to apply the theme switch.
I learned how to do all this by looking at the blocks.module. This is also the catch. It doesn't work nicely with blocks.module because selecting the current theme is really done through a set of global variables ($theme, $custom_theme). Once one module has overridden $custom_theme, the knowledge about the original theme (user-specific or standard) is lost.
I currently solve this by excluding admin/block pages from the theme replacement. I have considered to introduce some kind of stack of overridden themes, but as this would affect at least system.module, blocks.module, theme.inc so I wanted to discuss this here first.
Is anybody working on this theme selection right now? This might fall into the realm of Adrian's overhaul of the theming system.
Cheers, Olav
-- Dr. Olav Schettler (Geschäftsführer) contAire GmbH ___________________________________________ Arndtstr. 12 | D-50676 Köln | Germany Office: +49 221 4204757 | Mobile: +49 175 2249141 olav.s@contaire.de | Yahoo! olav ___________________________________________ Please visit our website http://www.contaire.de/
A theme switch module which allowed you to choose theme engines/themes based on the view being generated may be fun, but how often on a site do you really need this level of abstraction in the presentation layer?
lets get pragmatic here. sometimes users want a different look for their "space". "different look" might meen customized blocks and customized colors. for example, the Brazil organic group might want the Soccer News feed on top and the yellow color scheme. their organic group. is that a valid requirement. if so, how should it be implemented? it is fine to say that most sites/modules not switch the theme. thats accurate. but sometimes it is a valid system requirement IMO. alan's link points to a bootstrap bug thats been fixed. i don't think it strengthens anyone's argument unless you believe in folklore like "bad things happen when you switch themes" -moshe
Moshe Weitzman wrote:
A theme switch module which allowed you to choose theme engines/themes based on the view being generated may be fun, but how often on a site do you really need this level of abstraction in the presentation layer?
alan's link points to a bootstrap bug thats been fixed. i don't think it strengthens anyone's argument unless you believe in folklore like "bad things happen when you switch themes" -moshe
There are, I agree, some applications for which theme switching can be very important. Generally it's best to use sub-themes so they all share a template.php file, but some sites may be simple enough that they don't do much theme overriding.
On 6/22/06, Moshe Weitzman <weitzman@tejasa.com> wrote:
A theme switch module which allowed you to choose theme engines/themes based on the view being generated may be fun, but how often on a site do you really need this level of abstraction in the presentation layer?
lets get pragmatic here. sometimes users want a different look for their "space". "different look" might meen customized blocks and customized colors. for example, the Brazil organic group might want the Soccer News feed on top and the yellow color scheme. their organic group. is that a valid requirement. if so, how should it be implemented?
Yes, that's a good question. We've had some discussion in og's case here: http://drupal.org/node/66155. I've also been irritating you here http://drupal.org/node/67787 with a different approach to a slightly different version of the problem. I hope we can find some good answers. I suspect part of the challenge is that we're working on different sets of unwritten requirements (along with the usual pressure to deliver results).
it is fine to say that most sites/modules not switch the theme. thats accurate. but sometimes it is a valid system requirement IMO.
This is semantics, but I would call "modules/sites switching the theme" an implementation decision - the "requirements" would describe the user's experience rather than how that would be achieved. On the other hand, I think your concept behind og is that each organic group behaves like it's own site, and that includes a custom theme that could be separately chosen and maintained by each group. And that would be pretty ugly to implement with a single theme.
alan's link points to a bootstrap bug thats been fixed. i don't think it strengthens anyone's argument unless you believe in folklore like "bad things happen when you switch themes"
Okay, sorry - I should have provided more narrative. The thread was resolved by moshe's excellent patch to the bootstrap process, and it was og's use of theme functions in og_init that made the problem with the bootstrap apparent. So this is good - og pushed the boundaries of the code (in conjunction with 18n) and a problem was discovered and resolved. Another narrative in there is that hook_init is dangerous and that modules have to think carefully about what code in there might do. But my point of including the example was the observation that the reason you were using og_init was because you wanted to set the theme early enough in the process, which (as I understand it - but you'd know better) isn't part of the basic drupal code assumption. So my conclusion is - it's worthwhile to step back and rethink the requirements and see if it can be implemented without modules having to switch themes. If (as you've concluded) it can't, then I'd guess that the bootstrap problem might not be the only consequence, and some core support for this idea would be important (e.g. what happens when two modules are trying to both set different themes?). -- Alan Dixon, Web Developer http://alan.g.dixon.googlepages.com/
participants (13)
-
Adrian Rossouw -
Alan Dixon -
Boris Mann -
Bèr Kessels -
Darrel O'Pry -
Dmitry Gukov -
Dries Buytaert -
Earl Miles -
Gordon Heydon -
Moshe Weitzman -
Nedjo Rogers -
Olav Schettler -
Robert Douglass