- Development - lists.drupal.org

flashvideo, swftools and gpl
by sime 09 Feb '07

09 Feb '07

(Att: ajk^) Here is the email I sent to travist regarding non-GPL flashplayer in contrib http://cvs.drupal.org/viewcvs/drupal/contributions/modules/flashvideo/ Simon -------- Original Message -------- Subject: [drupal.org] flashvideo, swftools and gpl Date: Fri, 9 Feb 2007 02:37:50 +0000 (UTC) From: info(a)urbits.com Reply-To: info(a)urbits.com To: info(a)urbits.com travist, sime (http://drupal.org/user/35266) has sent you a message via your contact form (http://drupal.org/user/98581/contact) at drupal.org. If you don't want to receive such e-mails, you can change your settings at http://drupal.org/user/98581. Message: Hi Travis Just looking at your flashvideo module. The ffmpeg stuff is really great, I've been working with ffmpeg for a while and I like that you're making it more accessible. Regarding the flash player part of your module, I'd like to request that you make flashvideo run on top of the SWF Tools API module. http://drupal.org/project/swftools This module provides a couple of advantages: 1. It easy to add support for many different Flash media/video/audio players 2. You can choose from various flash replacement techniques (swfobject, jquery.flash.js, UFO). It also solves a problem for you. You have uploaded a Player.swf which I am quite certain is Jeroen Wijering's Flash player. http://www.jeroenwijering.com/?item=Flash_Media_Player This flash player is Creative Commons license, hence it cannot be stored in Drupal contrib. SWF Tools ships with a special version of this flash player that was kindly GPL'd by Jeroen. This version has a watermark and link to Jeroen's site, which is only fair - if people want to download the CC version of the player from his site, they can do this. I discussed this problem in IRC, and for this reason I'm cc'ing the developers mailing list so that a few people can follow the GPL issue to its resolution. But I really hope you like the idea of using SWF Tools API - you don't need to move your project or anything, just change some of the code. I think it's the best thing for Drupal as whole, since the community builds up it's Flash-related expertise in one spot. Cheers Simon -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.17.30/674 - Release Date: 2/7/2007 3:33 PM

1 1

5.x: menu module is semi-required?!
by Gabor Hojtsy 08 Feb '07

08 Feb '07

Hi, We are running Drupal.hu (on Drupal 5.1) with menu module turned off. We don't need those features. By looking at the code though, system.install has the menu table creation code, so menu module has no schema control of its own. Menu module is certainly not required, since sites run fine without it (we have custom primary navigation written in few lines of PHP code, which is a lot more performant then menu.module). My question is that leaving menu.module install code in system.install was just on oversight, or is menu module required after all for some more exotic reasons (not only navigation menu editing)? If the latter is the case, the next Drupal 5.x might need a fix to make menu.module required. But I doubt. Ps. I know the menu is being reworked for Drupal 6.x, so this is not applicable to HEAD. Gabor

4 3

Fwd: [General inquiry (other)] I just wanted to say how fantastic I think Drupal is
by Dries Buytaert 08 Feb '07

08 Feb '07

FYI. :-) Begin forwarded message: > Date: Thu 8 Feb 2007 12:54:33 GMT+01:00 > To: info(a)drupal.org > Subject: [General inquiry (other)] I just wanted to say how > fantastic I think Drupal is > > stevehem sent a message using the contact form at > http://drupal.org/contact. > > Drupal is astounding. It just works!! -- Dries Buytaert :: http://www.buytaert.net/

1 0

seeking module maintainers
by Knapen Dries 08 Feb '07

08 Feb '07

Dear list, It has taken some time before I was able to admit it to myself, but due to some extensive changes in my academic career I no longer have time to actively and responsibly maintain the modules I created. To be honest, I even didn't get to thoroughly study the changes in Drupal 5 from a developer's perspective, so I don't see myself upgrade these modules any time soon. I prioritized my Drupal and other activities, and I have decided that in the foreseeable future I will only continue to contribute to the Drupal project as the treasurer of the Drupal Association, and no longer as a module developer, since I believe that the Association is currently more important to support Drupal and help the project grow. Therefore, the following modules need new maintainers: Flash Gallery http://drupal.org/project/flash_gallery Graphstat http://drupal.org/node/33946 Inactive User http://drupal.org/node/10435 Simplenews http://drupal.org/project/simplenews As for Simplenews (critical for drupal.org) RobRoy (http:// drupal.org/user/22975) already has cvs access, and released a working 5.x version of the module. Furthermore, Sutharsan (http://drupal.org/ user/73854) provided a lot of great patches for simplenews lately. I'll forward this e-mail to him in case he doesn't read this list. I will unsubscribe from most public Drupal mailing lists soon, you can contact me in private through http://drupal.org/user/17892/ for cvs access and/or module ownership. Drupal.org site administrators are also free to perform these actions. I'd only like my name to be mentioned as the original author on the project page and README.txt of Flash Gallery, Graphstat and Simplenews. cheers, Dries Knapen

9 15

create patch form
by sime 08 Feb '07

08 Feb '07

Has anyone meddled with a patch creation form? Eg: 1) select the file of interest 2) paste your variation code 3) submit to create a patch Seems simple, judging from the few times I'm brave enough to use the command line (yes, I'm GUI user who would struggle to code this). In my wanderings through contrib, I've seen many users submit code which solves a problem, but which is not in expected patch format. For example, a zip file of whole modules! This happens more in the contrib modules where patches are less critisized and users are sharing solutions with each other that "just work". Some might question whether we should cater for these developers. I say yes, because they are solving problems but cannot communication the answer very well. If a developer installs a module on a site, and then fixes a bug, then they have a solution - however to then submit that answer in legible form is quite an effort for many. Further more, we then expect users to be able to generate function-contextual patches from root. This is a hard to grapple and I'm sure the effort is too much for some, and they never submit a patch at all. Interested in any thoughts. Simon (sime)

13 17

Re: [development] CCK in Drupal 6
by Karen Stevenson 08 Feb '07

08 Feb '07

There are so many good ideas flying here I thought I would try to get them organized in a place where we can do something with them so I started a wiki page on g.d.o at http://groups.drupal.org/node/2717. Unfortunately, only the first page ended up as a wiki page. The pages created automatically from the wiki links ended up as story pages that cannot be edited. Can someone with admin rights straighten it out for me? There are only 3 pages. I could create new wiki pages, but can't delete the story pages, so I just stopped because I was messing things up. http://groups.drupal.org/node/2719 http://groups.drupal.org/node/2720 http://groups.drupal.org/node/2718 It's not complete, I just tried to get some of the big ideas documented. On a couple of the pages I just pasted parts of this thread as a starting point. Once the story pages get changed to the wiki pages they were supposed to be, they can be cleaned up and fleshed out by anyone who is interested. Anyway, it's a beginning... Karen ----- Original Message ---- From: Darrel O'Pry <dopry(a)thing.net> To: development(a)drupal.org Sent: Wednesday, February 7, 2007 3:19:09 PM Subject: Re: [development] CCK in Drupal 6 On Wed, 2007-02-07 at 14:28 -0600, Larry Garfield wrote: > On Wed, 7 Feb 2007 22:11:11 +0200, adrian rossouw <adrian(a)bryght.com> wrote: > > > > On 07 Feb 2007, at 8:56 PM, Darrel O'Pry wrote: > > > >> > >> This can be overcome with a few simple #validate functions on form > >> elements correct? > >> > > > > There are definitely 2 steps involved here. > > > > widgets do processing on the input, to change it into the right data > > type. (this is how i felt checkboxes/ select lists should have been > > handled, not by being hardcoded in form_builder) > > fields validate the data that they have been given, whether by code > > or by the widgets. > > > > I don't believe we should include the #validate functions for the > > field types / widgets into the form structure thought, > > because if we do it right,. every single field will have validation > > rules, > > and all that information will not often be modified (fields can still > > have additional validation rules of course). > > > > We don't want to bloat the data structure unnecessarily. > > Potentially naive question from someone who has not used FAPI to its fullest extent > yet: What does hook_widget offer that hook_elements does not? Would it be feasible > to simply beef up hook_elements to fill in any missing functionality that hook_widgets > has that it doesn't, then deprecate hook_widget? The widget callbacks in CCK, hook_widget_info, hook_widget_settings, and hook_widget provide a few things above and beyond form elements. 1) hook_widget_info, A way to specify which widgets work with which fields. 2) hook_widget_settings, provides a form and setting so users can configure widgets through the browser when creating field instances. 3) hook_widget, the only unique addition that can't be handled through the current FormAPI is the prepare op. > That would give us the bonus of CCK-added fields and form_alter value-add fields > both being able to support "rich fields". Instead of a CCK field called "node > reference", you'd have a FAPI element called node_reference: > > $form['other_node'] = array( > '#type' => 'node_reference', > '#default_value' => $node->other_node ? $node->other_node : 0, > '#required' => TRUE, > ); I think we're kind of headin in this direction but you would call $form['other_node'] = drupal_field('nodereference'); > And then you could do the same with arbitrarily complex elements/fields which can then be > value-added or CCK-added via the admin. The problem is these kinds of constructs are currently only valid on nodes, since CCK in its present form is about decorating nodes with custom fields. I've been playing with the idea of field instances and their values as their own data silos, much like Ber's idea of microcontent I think, and similar normalized lookup or attribute tables in databases. I don't think this is within the scope of getting CCK into core. I think we should avoid new features at all costs, until we get the integration done right for our existing feature set. Then start planning how to expand on it. > > Or am I completely misunderstanding hook_elements entirely (which is entirely possible)? hook_elements basically defines a set of defaults for a '#type'. Its nice to have simple dumb elements. I'm not sure you need a widget all the time and widgets use elements themselves. With #process they're nicely nestable.

2 1

Re: [development] CCK in Drupal 6
by Larry Garfield 07 Feb '07

07 Feb '07

On Wed, 7 Feb 2007 22:11:11 +0200, adrian rossouw <adrian(a)bryght.com> wrote: > > On 07 Feb 2007, at 8:56 PM, Darrel O'Pry wrote: > >> >> This can be overcome with a few simple #validate functions on form >> elements correct? >> > > There are definitely 2 steps involved here. > > widgets do processing on the input, to change it into the right data > type. (this is how i felt checkboxes/ select lists should have been > handled, not by being hardcoded in form_builder) > fields validate the data that they have been given, whether by code > or by the widgets. > > I don't believe we should include the #validate functions for the > field types / widgets into the form structure thought, > because if we do it right,. every single field will have validation > rules, > and all that information will not often be modified (fields can still > have additional validation rules of course). > > We don't want to bloat the data structure unnecessarily. Potentially naive question from someone who has not used FAPI to its fullest extent yet: What does hook_widget offer that hook_elements does not? Would it be feasible to simply beef up hook_elements to fill in any missing functionality that hook_widgets has that it doesn't, then deprecate hook_widget? That would give us the bonus of CCK-added fields and form_alter value-add fields both being able to support "rich fields". Instead of a CCK field called "node reference", you'd have a FAPI element called node_reference: $form['other_node'] = array( '#type' => 'node_reference', '#default_value' => $node->other_node ? $node->other_node : 0, '#required' => TRUE, ); And then you could do the same with arbitrarily complex elements/fields which can then be value-added or CCK-added via the admin. Or am I completely misunderstanding hook_elements entirely (which is entirely possible)? --Larry Garfield

5 4

should tinymce get a new maintainer tinymce
by Alaa Abd El Fattah 07 Feb '07

07 Feb '07

Hi, I don't know how many of you are following tinymce module development, so I thought I'd bring up this issue on the mailing list. recently user drupal-id.com took over the project and immediately started on a rewrite for drupal 5 discarding all old code. the problem is drupal-id.com's new redesign lacks features that many existing tinymce users find crucial (like customizing the button set and having different buttonsets per role). but the problem is not limited to differing goals, I don't think drupal-id.com is a good maintainer, he does not respond to issues in the issue queue (the issue queue is not 10 pages long and growing rapidly). at the moment the only way to get tinymce to work as before is to patch the DRUPAL-4-7 branch using a patch attached to this issue http://drupal.org/node/100864 check the discussion around this issue to soo how many are complaining about current state of tinymce.module drupal-id.com responded only once to this issue. IMO tinymce needs a new maintainer. cheers, Alaa -- Alaa: Husband of the Grand Waragi Master http://www.manalaa.net

22 42

Community tagging (Was Re: Content Type - wiki)
by Boris Mann 07 Feb '07

07 Feb '07

On 2/1/07, Julian <julian(a)tschannen.net> wrote: > On Thursday 01 February 2007 09:25, Morbus Iff wrote: > > > http://test.tschannen.net ? > > > > What handles the "Add tagging" block on the right? > > A custom module which allows flickr-like tagging. > It is similar to 'community_tags' or 'taxonomy_user' but both of them are not > yet available for drupal 5 and they didn't provide all the functionality I > needed. > > But the module is not yet in a state that it is usable by others. Can we collaborate on community_tags? We've been in touch with taxonomy_user author but gotten no response. We plan on updating community_tags to Drupal 5...it would be great to have you as co-maintainer and merge directions here rather than yet-another-module. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com

3 3

Drupal 5 performance
by Dries Buytaert 07 Feb '07

07 Feb '07

Hello, as I promised a while ago on this mailing list, I would do a performance comparison of Drupal 4.7 vs Drupal 5. Well, it's up at: http://buytaert.net/drupal-5-performance. -- Dries Buytaert :: http://www.buytaert.net/

2 1