October 2005 - Development - lists.drupal.org

[drupal-devel] Forms API
by Adrian Rossouw 02 Oct '05

02 Oct '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 it's done : http://drupal.org/node/29465#comment-47340 I tried posting the patch to the list, but it's waiting for moderator approval. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDPzFbgegMqdGlkasRAo13AJ9ASWIYAWG92ML1efgYKJP29YBnQACdGjaS VS81EHVWzNaD34sjD63fQiI= =Fjq2 -----END PGP SIGNATURE-----

1 0

[drupal-devel] Forms : include files
by Adrian Rossouw 02 Oct '05

02 Oct '05

Damn. I neglected to add the new inc files to the previous email. I also neglected to thank Tobias for his help, although I definitely had him on my list to thank. No harm meant. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com

1 0

Re: [drupal-devel] css clear use
by Pat Collins 02 Oct '05

02 Oct '05

On Sat, 01 Oct 2005 16:55:17 +0200, Steven Wittens <steven(a)acko.net> wrote : > > >I'm trying to develop a theme with floating css elements and there are > >several uses of clear in misc/drupal.css that are messing up my layout. > >Is there a particular programmatic reason the use of clear is > >superordinate to themes? > > > >I seem to have been able to override it in the theme css file, but aside > >from it being temporarily annoying to fix, it doesn't seem like I should > >have to override Drupal built-in css. > > > > Css stands for Cascading Style Sheets. Making use of the cascading part is not a fix, but a feature. > > It's much better to switch to a layout model that can actually handle > clears at arbitrary locations: > http://www.positioniseverything.net/articles/sidepages/jello-piefecta-clean… > > By encasing each column in a floated div, you structurally separate > them, and they won't interfere with eachothers clears. This also has the > benefit of allowing source ordered columns. > I looked at doing this, but found the css much to complicated for the average person to understand. Here is what I have know for a theme using floating divs: http://www.linuxcolumbus.com . It is a modification of the phptemplate bluemarine theme. Goal is to just see what I can do and to make it as simple as possible. Comments welcome. Pat

3 2

[drupal-devel] Admin theme
by Bèr Kessels 01 Oct '05

01 Oct '05

Id like to pull this discussion out of the general usability improvement, because I feel this needs LOT of thought before it even close to ready. for me the admin theme has a few requirements: * it must be able to disable when someone feels he/she is not helped with it. * it must be overridable in a theme * it must be profilable (a forum site has a different concept of what pages are admin then a personal blog) Some ideas I came up with to tackle this admin theme issue are: * tackle this in the menu. Allow a flag/setting per menu entry 'IS_ADMIN' and 'ADMIN_SUGGESTED'. * tackle this in a blocks/sections alike interface, where sets of regexps define what pages are admin and what pages not. * tackle this in a separate admin-theme UI, where one can select a pre-defined profile (blog, forum site etc) then the profile will select for you what pages are admin and what not. I personally dislike the last item. it is not flexible enough, yet I still mention it, because it might be a starter for better ideas? Ber

16 24

[drupal-devel] css clear use
by David Norman 01 Oct '05

01 Oct '05

I'm trying to develop a theme with floating css elements and there are several uses of clear in misc/drupal.css that are messing up my layout. Is there a particular programmatic reason the use of clear is superordinate to themes? I seem to have been able to override it in the theme css file, but aside from it being temporarily annoying to fix, it doesn't seem like I should have to override Drupal built-in css.

5 5

[drupal-devel] what do you call a rose?
by Karoly Negyesi 01 Oct '05

01 Oct '05

Hi! Despite what Shakespeare says about the name of the rose (What’s in a name? That which we call a rose / By any other name would smell as sweet), it's still more convinient to call it a rose, simply because (lot) more people would know what are you talking of. "free tagging" has 13,300 results while folksonomy has 1,220,000 results according to googlefight. It's not that "free tagging" is bad, it's just that we are creating another barrier. Look at taxonomy vs. categories... it's still more accessible to call it "categories" while the savvy developer know that "Drupal categories" is another name for a rose called "taxonomy". I am ready to admit that "free tagging" is not folksonomy, but again, taxonomy vs. categories. You can say that taxonomy vs. categories is the camel nose in the tent. I will disagree. Regards NK

12 17

Re: [drupal-devel] what do you call a rose?
by Bèr Kessels 01 Oct '05

01 Oct '05

On Saturday 01 October 2005 15:23, Steve Dondley wrote: > > This is where preconfigured installs like CS or on Btyght come to play. > > So your view is that Drupal isn't meant to be used directly and must > be packaged into special distributions for use by end-users? Yes. that is my vision. > Why not attempt to lower the barriers as much as possible? Why not > just make things as easy as possible for her? Making Drupal as > user-friendly as possible will do more to spread the use of Drupal and > as a result increase the size of your bank account. No. I beleive that a lot of barriers can only be lowered by giving in on flexibility. Too many things in drupal are just complex, because we do not want to give in on that flexibility. the only way to make them easier is to remove that complexity. Off course there are a LOT of places where we can improve drupal without giving in on that flexibility. I am NOT talking about all those issues, for one day they will be fixed. > > If I cannot afford an engineer to fix and maintain my car, I will need to > > learn how the engine works. > > You don't have to learn how to fix a car just to use it. And a person > who has never seen a car before could probably learn in about 20 > minutes. Maintaining is not driving. > > True. But renaming 'weight' to 'ordering' will not help. The concept we > > have currently is 1) hard to grok, and 2) very hard to get right in an > > UI. Above all this -again- is an interface problem. > > I has some ideas about changing how the weight was worded. See > http://drupal.org/node/19434 Again: the issue lies in the fact that weighting has no good UI. If we could allow AJAX dragDrop lists, the whole idea of weighting can stay in existence (for we DO weighted ordering) but users need not be bothered with it. That is what I keep hammering on. Renaming weight to whatever, does not solve the issue. Improving the *total* communication does. (UI, names, explanation, help etc). Ber

1 0