18:58:26 -!- darix [darix@darix.staff.irssi] has joined #drupal-phptemplate
18:58:26 -!- Irssi: Join to #drupal-phptemplate was synced in 0 secs
19:00:29 -!- mode/#drupal-phptemplate [+o berkes] by JonBob
19:00:46 -!- killes [~killes@helios.physik.uni-freiburg.de] has joined #drupal-phptemplate
19:00:52 <@berkes> anyone know if Dries was coming?
19:00:54 <@berkes> hello killes
19:00:55 -!- adrinux [~adrinux@cpc1-cowc1-3-0-cust116.renf.cable.ntl.com] has joined #drupal-phptemplate
19:00:59 < killes> Hi berkes!
19:01:07 < factory_allnight> hi guys!
19:01:11 < adrinux> 'lo
19:01:16 < adrinux> thought I'd lurk
19:02:17 < factory_allnight> glad to have you
19:02:22 <@berkes> factory_allnight: any idea if neil will be here too?
19:02:33 < Vertice> dries is coming afaik
19:02:41 <@berkes> 'cause he did some coding on this too.
19:02:44 < Vertice> joshk should be coming 
19:02:51 <@JonBob> josh_k just logged into #drupal
19:03:06 <@JonBob> UnConeD was on the invite to
19:03:08 <@JonBob> too
19:03:12 -!- grohk [~Brady@user-0cev5cn.cable.mindspring.com] has joined #drupal-phptemplate
19:03:15 < factory_allnight> um, berkes, neil just went to sleep somewhere
19:03:22 < factory_allnight> on the floor or something
19:03:58 <@berkes> feed him some coffee, will ya?
19:04:18 -!- josh_k [~joshk@68-174-139-56.nyc.rr.com] has joined #drupal-phptemplate
19:04:27 < Vertice> lessee if dries is on msn
19:04:36 -!- UnConeD [~Pioneer@kotnet-146.kulnet.kuleuven.be] has joined #drupal-phptemplate
19:04:56 < Vertice> did anyone invite gordon ?
19:05:09 <@berkes> Not that I know. 
19:05:17 < factory_allnight> berkes: intravenously?
19:05:19 < Vertice> mmm. 
19:05:22 <@berkes> has anyone got gordons IM?
19:05:26 < Vertice> nope
19:05:32 < factory_allnight> he was having a hard time spelling his name
19:05:40 < factory_allnight> probably better that he sleep
19:06:43 < Vertice> cool. 
19:06:45 < Vertice> so shall we start ?
19:07:22 <@berkes> not waiting for grandmasterDries?
19:08:01 < UnConeD> (i'm just going to hang back and follow the talk)
19:08:18 < Vertice> we can wait another couple of minutes. 
19:08:33 < UnConeD> dries is not on IM
19:08:37 < UnConeD> he's probably having dinner
19:08:40 <@berkes> then lets start:
19:08:55 < killes> UnConeD: Same here. I just want it to work. Oh, and I want to have different links for different roles. ;)
19:09:03 < josh_k> oooooh
19:09:09 <@berkes> allright. The issue is easy: we want the menu system to take care of PRim/Secondary links, 
19:09:30 <@berkes> I have the code for this, it works, but can use some optimisation.
19:10:09 <@berkes> We can adminstrate this trough the menu system allright.
19:10:12 <@berkes> But....
19:10:35 <@berkes> In order to make this all work nice, we must be able to define a "menu_container".
19:10:54 <@berkes> or, in other words,  a new menu block.
19:11:08 <@berkes> We can do this via the admin. but we really need to:
19:11:37 <@berkes> 1) have a default container for the links, pre-filled with some nice links,
19:11:57 <@berkes> 2) have this also work without menu.module turned on.
19:12:24 <@berkes> ad 1) we need to discuss what links will go in here.
19:12:40 <@berkes> ad 2) we need to find out how we can define a default container.
19:12:42 < Vertice> basically. we are now at a clean slate
19:12:48 <@JonBob> berkes: May I propose the simple solution?
19:12:55 <@berkes> i like those
19:13:12 < Vertice> because previously we wanted to port all the hook_link('page') items to the menu system
19:13:14 <@JonBob> This is only complicated once hook_menu() gets involved.
19:13:55 <@JonBob> If we are content to have the primary menu items not depend on the presence/absence of modules, things are easy
19:14:14 <@JonBob> because then we can just define the menus/menu items in database.mysql
19:14:33 <@berkes> JonBob: that is an easy solution indeed.
19:14:56 <@JonBob> And done.
19:14:58 <@berkes> but: as you point out, we will not be able to have things like /blog /forum etc in there.
19:15:13 < factory_allnight> is there also a larger question here about what to prepopulate drupal with?
19:15:36 <@berkes> factory_allnight: naah,. lets leave that out of the discussion atm.
19:15:37 < factory_allnight> i kind of assume that these are "what do you get out of the box" questions, yes?
19:15:42 < factory_allnight> sure sure
19:15:53 <@berkes> factory_allnight: not really.
19:15:59 < factory_allnight> hmm ok
19:16:00 < Vertice> also
19:16:12 < Vertice> contrib modules might want to add items to the default list
19:16:22 <@berkes> we were always able to present a dynamic set of links, based on a) permissions b) enabled modules.
19:16:33 <@berkes> we will loose that with JonBobs suggestion. 
19:16:53 < Vertice> this has been removed for 4.6
19:17:19 < Vertice> the menu hook is the ideal way to handle this. (imo)
19:17:26 <@berkes> but, what about adding a default primary container (without links) to .sql files?
19:17:28 < Vertice> and it's how dries would like to see it done.
19:17:40 < Vertice> the problem is with thhe _menu hook. 
19:17:51 < Vertice> we can't add links to a specific container
19:17:56 <@berkes> and let modules use the _menu hook to add links in there?
19:18:09 <@berkes> oh, no, indeed, that was the key of the problem :)
19:18:24 <@JonBob> Vertice: It has little/nothing to do with containers.
19:18:33 <@JonBob> Let me paste what I wrote to Dries:
19:18:36 <@JonBob> The problem is how the menu tree is built. Menu items defined by modules get added to the tree based on their path. This means that the menu structure *must* reflect the URLs, which is good for consistency but bad for flexibility. It's not a problem to define a new "root" for the primary items, but no menu items would end up there because they would all have parents in the main "navigation" menu anyway!
19:19:06 <@JonBob> Also, complicating matters, it's quite possible and even likely that a menu item in the primary nav may also appear in the navigation menu. This is possible to do using the menu admin interface (a "shortcut" is created) but not using hook_menu(), as only one item can be created for each path.
19:19:28 < Vertice>  yeah. 
19:19:50 < josh_k> for what it's worth, from my experience the navigation menu quickly becomes crowded beyond reason by module-added items
19:20:05 < josh_k> I'd like to see something that offers admins more control
19:20:10 < josh_k> to better serve their users
19:20:13 < factory_allnight> can i say quickly...
19:20:16 <@JonBob> josh_k: I personally agree
19:20:25 < Vertice> josh_k: we could have the modules create suggested menu items
19:20:29 < factory_allnight> that focussing so heavily on a tree structure is actually very distracting
19:20:30 < Vertice> that can be easily enabled
19:20:47 < factory_allnight> i don't intend to derail the conversation
19:20:57 <@berkes> well, i would really like to keep the menu system out of scope as far as possible.
19:20:59 < factory_allnight> but one of the most universal complaints i get about drupal is the dirth of menu items
19:21:13 -!- Steef [~Stefan@g222158.upc-g.chello.nl] has joined #drupal-phptemplate
19:21:22 <@berkes> it being crowded and all should not be adreessed here and now IMO. 
19:21:26 < factory_allnight> and i would argue that a great deal of those menu items should not be seen by 98% of users
19:21:30 <@JonBob> factory_allnight: What you're suggesting is... a flatter structure? More shortcuts?
19:21:52 <@berkes> factory_allnight: allright but can we please not discuss that now?
19:22:05 < factory_allnight> i'm suggesting that one answer to the menu overpopulation issue is better integrating modules' "surfaces" into drupal
19:22:18 < Vertice> surfaces ?
19:22:20 < factory_allnight> berkes: ok, but i do think that it's important
19:22:40 <@berkes> factory_allnight: yes it is, but not now, IMO,
19:22:55 <@berkes> or how would you see that solving the primary/secondary issue?
19:22:56 < factory_allnight> berkes: fair rnough...
19:23:07 < factory_allnight> well, if we had good guidelines
19:23:16 < factory_allnight> like *strong* guidelines
19:23:37 < factory_allnight> because that would help some of these issues
19:23:48 < factory_allnight> of having modules appending links to the menu structure
19:23:54  * Steef loves to hea that word... 'Good guidelines' sounds like music in my ears...
19:24:26 <@berkes> how, and where would that help us, more precise, factory_allnight?
19:24:26 < factory_allnight> i mean, yeah, i've had 3hrs sleep in the last 48, but cutting down on "drupal clutter" i think is AS important as this menu system question
19:24:47 <@JonBob> factory_allnight: Yep
19:24:49 < factory_allnight> well, from what i hear so far, there are issues w/ jonbob's solution b/c of module integration
19:24:52 <@berkes> I cannot see how this will solve this issue, factory_allnight.
19:25:07 < factory_allnight> if the menu system is specifically controlled by admins
19:25:21 < Vertice> i think modules should load suggested, but disabled menu items
19:25:23 < factory_allnight> and *not* by modules -- i.e. they can't directly append themselves to the menus
19:25:26 < factory_allnight> does that help?
19:25:34 < Vertice> so the administrator can just enable them
19:25:39 < factory_allnight> yeah, like modules could "queue" their menu items
19:25:45 < factory_allnight> or get added to a pool of options
19:25:59 <@JonBob> Yes, this policy would make my proposal work
19:25:59 < factory_allnight> but ultimately, the admin should have an outliner-like ability to organize his/her menus
19:26:01 < Vertice> so the items show up in the menu admin, but not in the site itself, automatically.
19:26:08 < factory_allnight> exactly
19:26:21 < factory_allnight> no one but admins should be enabling modules anyway
19:26:23 <@berkes> indeed. options, queues, but can we please focus on the primary and secondary links?
19:26:26 <@JonBob> but would mean the primary/secondary would be initially almost empty
19:26:38 < josh_k> I think that's a good thing
19:26:43 < factory_allnight> well that's open for discussion right now
19:26:51 < factory_allnight> my whole point is: less is more w/ menus
19:26:58 < factory_allnight> let's make it HARD to add items
19:27:04 < factory_allnight> on a whim
19:27:13 < Vertice> factory_allnight: i am not sure i agree with that.
19:27:15 < factory_allnight> but easier to organize and move menu items around
19:27:36 < josh_k> I think if someone sets up a new site, it's totally logical for part of that setup to be some degree of initial configuration
19:27:50 < factory_allnight> that's also what i was saying about prepopulation
19:27:52 <@berkes> everyone,  can someone please tell me what this has to do with primary and secondary links? 
19:27:52 < josh_k> and going and selecting what he/she wants in the primary/secondary links makes a lot of sense
19:28:01 < darix> hmm why not make primary/secondary just other menu blocks. primary, secondary, navigation. so the primary/secondary can do hierarchical menus too?
19:28:10 <@berkes> if we have less items, we still do not have them in primary or secondary links!
19:28:12 < Vertice> but when a user adds a new module, it shouldn't be too hard for a user to enable / add menu items to that.
19:28:14 <@JonBob> darix: That is what's being proposed.
19:28:29 < darix> +1 for it.
19:28:39 < Vertice> berkes: we are discussing how the primary links should be defaulted.
19:28:48 < factory_allnight> so the current paradigm, btw, relies on these hierarchical link systems
19:28:54 <@berkes> darix: but we cannot create blocks, nor add links to the blocks atm.
19:28:56 < factory_allnight> but we're only really supporting two levels
19:29:09 <@berkes> factory_allnight: nope, we have infinte levels
19:29:11 <@JonBob> berkes: correction: only the admin can
19:29:19 < darix> berkes: you can put them into the default sql file. as already said.
19:29:27 -!- adrinux [~adrinux@cpc1-cowc1-3-0-cust116.renf.cable.ntl.com] has left #drupal-phptemplate []
19:29:29 < factory_allnight> about "primary" and "secondary"
19:29:35 <@berkes> darix: the blocks, yes. 
19:29:36 < factory_allnight> well, to berkes point though
19:29:36 < factory_allnight> is that a false dichotomy?
19:29:56 <@JonBob> factory_allnight: It is.
19:30:01 < josh_k> [info] for an example of what "infinite levels" might mean, see: http://www.outlandishjosh.com/civicspace/life/places
19:30:08 < factory_allnight> ok, just thought i'd make sure we were aware of that
19:30:26 <@JonBob> berkes: May I try to focus the discussion a bit?
19:30:28 < josh_k> [info] the same meny powers the tab and top block on right, as well as being fully displayed below on right
19:30:36 < josh_k> JonBob ++
19:30:42 < factory_allnight> jonbob ++
19:30:51 < Steef> jonbob++
19:30:52 <@JonBob> The question at hand is:
19:30:58 < Vertice> the actual code mechanism 
19:30:59 < Vertice> the actual code mechanism 
19:31:02 <@berkes> JonBob: please, my attempts were no good :)
19:31:02 < Vertice> bah
19:31:28 <@JonBob> "If the default set of menu items is not dependent on installed modules, can we come up with a useful set of links still?"
19:31:35 <@JonBob> If not, my approach is pointless.
19:31:42 < Vertice> what about modules which don't have .sql 
19:32:05 <@JonBob> Vertice: Modules would not add items to the primary links.
19:32:06 <@JonBob> Ever.
19:32:11 <@JonBob> Admins could.
19:32:22 < josh_k> JonBob: I think putting the onus on admins to enable suggestions from modules in primary links is good
19:32:32 < Vertice> yeah. 
19:32:47 < josh_k> default could be a link to the menu conf page: "enable menu items"
19:32:50 < Steef> Can't simply have a menu item called MENU_NAVIGATION_PRIMARY && MENU_NAVIGATION_SECUNDARY
19:32:50 < Vertice> it means you could build a _menu hook for say, galleries.
19:32:53 <@berkes> I have an idea: make the solution two fold: long term and short term.
19:33:01 < josh_k> much like "edit primary links" today
19:33:02 <@berkes> short term: sql files, 
19:33:27 < Vertice> and have the _menu hook prepopulated with available galleries
19:33:30 <@berkes> long term: introduce a possibility in the menu to force/suggest a parent.
19:33:53 <@berkes> Steef_Away: no. We cannot. 
19:34:13 < darix> imho the primary/secondary link stuff should be moved out of the theme options. 
19:34:15 < Steef> berkes: just another proposal... :-$
19:34:24 < Vertice> darix: that's what we want to do
19:34:32 < Vertice> darix: that's what all this is about
19:34:34 < Steef> darix: i totally agree with you
19:34:41 <@berkes> no problem Steef_Away.
19:34:45 < darix> Vertice: ok than i really missed the beginning.
19:34:47 < darix> :)
19:34:59 <@JonBob> berkes: Explain?
19:35:02 < Vertice> essentially, we want to make menu.module handle the link configuration
19:35:03 <@JonBob> long term: introduce a possibility in the menu to force/suggest a parent. -v
19:35:17 < josh_k> berkes: I understand the problem w/secondary links (suggeting parents), but why can't modules suggest an addition to primary links w/a new meny type?
19:35:20 < josh_k> *menu type
19:35:26 < Vertice> JonBob: could we add a new menu type ?
19:35:31 <@berkes> Ill anser Jonbob first:
19:35:34 < Vertice> that it counts in a seperate tree ?
19:36:09 <@berkes> long term: if we are able to provide aparent MID, we can build trees depending on those too.
19:36:40 <@berkes> lets assume: foo/ and /foo/bar, now /foo/bar is always a child of /foo
19:37:09 <@berkes> but in the menu admin we can change that and make /foo a child of /foo/bar, for example.
19:37:43 -!- Steef [~Stefan@g222158.upc-g.chello.nl] has left #drupal-phptemplate []
19:37:52 <@berkes> if we would be able to do that in the _menu hook too, this whole issue will be solved too IMO.
19:38:06 <@JonBob> Most of it, yes.
19:38:20 <@berkes> for example by adding the param 'suggested_pid'='$pid' 
19:38:43 <@berkes> if $pid is not found, or else incorrect, fall back onto the patch.
19:38:52 <@berkes> ~path.
19:38:53 < Vertice> the problem is
19:39:01 < Vertice> we can't be sure of what the $Pid is going to bne
19:39:08 <@JonBob> Yes, exactly.
19:39:15 < Vertice> since the $pid changes depending on the path of things above it.
19:39:31 < josh_k> but if we start out simple
19:39:39 < josh_k> by just allowing suggestions for primary links
19:39:47 < josh_k> and we define that container in .sql
19:40:00 < Vertice> josh_k: we can't place the definitions in the container
19:40:04 <@JonBob> I want to clarify something:
19:40:13 <@berkes> go ahead JonBob.
19:40:20 < Vertice> josh_k: the menu items will fall wherever they are in the tree
19:40:25 <@JonBob> The proposal at hand is not to suggest "primary links"
19:40:29 <@JonBob> yes, what Vertice said
19:40:36 <@JonBob> the admin can move them up there.
19:41:00 < josh_k> why do it that way? more work for admins...
19:41:29 < darix> josh_k: more flexibilty and control for admins
19:41:29 <@JonBob> Well, it doesn't involve a two-month ground-up rewrite of the menu system. :-)
19:41:42 <@berkes> which IMO is not an option
19:41:49 < Vertice> JonBob: what about implementing a new menu_type
19:41:57 < Vertice> that works like a menu 'realm'
19:41:58 <@JonBob> Vertice: That is possible
19:42:08 <@JonBob> It leaves a very bitter taste in my mouth though
19:42:08 < josh_k> that's what I'm suggesting
19:42:13 < josh_k> it seems simple enough
19:42:21 <@JonBob> because we'd be hardcoding the "primary link" area
19:42:22 <@berkes> to clarify something: 
19:42:26 <@JonBob> and I really dislike that.
19:42:31 <@JonBob> Go berkes 
19:42:51 <@berkes> that menu type would have to be a "container", not an "item".
19:43:00 < Vertice> how about we add a 'container' => MENU_PRIMARY ?
19:43:12 <@berkes> yea. 
19:43:26 < factory_allnight> i have a question
19:43:28 < Vertice> that automatically adds it to the tree of the xth container.
19:43:31 < factory_allnight> or point of clarification
19:43:34 <@JonBob> factory_allnight: go
19:43:48 < factory_allnight> with this false dichotomy thing (i can define if necessary)
19:44:04 < factory_allnight> i wonder about what is intended by having a container of primary or secondary
19:44:28 < factory_allnight> whereas it seems to me, we're looking to define semantic relationships between both modules, drupal and the menu items that relate the two
19:44:57 < factory_allnight> so to me, the parent/child hierarchy or even the "leaf"/"branch" idea is more general than primary/secondary
19:45:06 < factory_allnight> and leaves open the ability to drill down
19:45:16 < Vertice> factory_allnight: we are intending that.
19:45:16 < factory_allnight> and also have the menu system "inform" the breadcrumbs, for example
19:45:39 < factory_allnight> ok, then i'm just getting hung up on terminology, sorry!
19:45:43 <@JonBob> factory_allnight: You're right; the primary/secondary labels are just names for two blocks
19:45:49 <@JonBob> that happen to be called that now.
19:45:52 < factory_allnight> ah ok
19:45:59 < factory_allnight> just "blocks" but not menu relationships?
19:46:11 < Vertice> we essentially want to replace the 2 seperate menus , with one menu.. 
19:46:13 <@berkes> JonBob: another thing to clarify:
19:46:21 < factory_allnight> it's like you move between backend and screen display so quickly i miss the transition!
19:46:25 < factory_allnight> :)
19:46:29 < Vertice> like in : http://www.outlandishjosh.com/civicspace/politics
19:46:30 <@berkes> secondary links are not a block.
19:46:50 <@berkes> they are simply children of all the primary items
19:46:58 < Vertice> yeah
19:47:03 < josh_k> yes
19:47:17 < Vertice> so /blog, /image and /whatever are the top level
19:47:36 < Vertice> or whatever. 
19:47:56 <@berkes> and /image/foo is a secondary item
19:48:02 < Vertice> and secondary links change to whatever.
19:48:11 < josh_k> right
19:48:17 < josh_k> and it would be uber-cool if we could also define ways of dealing w/their children (tertiary and beyond)
19:48:32 < Vertice> josh_k: it would be =)
19:48:37 <@berkes> but, to get back: will a MENU_FLAG for primary container help us?
19:48:40 <@JonBob> So, what are the problems with the 'container' => MENU_PRIMARY idea?
19:48:46 <@JonBob> I thought you'd never ask!
19:48:55 <@berkes> josh_k: its all possible already :0
19:49:57 <@JonBob> It hardcodes the existence of these blocks in the menu system, which I dislike
19:50:00 <@JonBob> It means more work for menu generation (maintaining multiple trees)
19:50:00 <@berkes> JonBob: i do not see how we can add children to the item with the flag MENU_PRIMARY though.
19:50:24 <@JonBob> berkes: The suggestion is that every item with that flag is put into a separate tree.
19:50:29 < Vertice> JonBob: yeah. it's not clean.
19:50:37 <@JonBob> That tree would have the same path-based rules for hierarchy.
19:50:50 <@berkes> oh, no, i do not really like that road. 
19:50:58 <@berkes> because of the same reasons. 
19:51:17 < Vertice> wait. 
19:51:18 < Vertice> a second.
19:51:24 <@JonBob> Vertice: go
19:51:25 <@berkes> IMO, we should be able to use the same menu, otherwise we do not really solve anythig
19:51:26 < darix> how about multiple ul/ol groups in one block
19:51:32 < darix> which are differed by id/class?
19:52:17 < Vertice> there are two approaches i have mentioned
19:52:31 < Vertice> 1) type= MENU_PRIMARY
19:52:39 < Vertice> which would involve a seperate tree. 
19:54:41 < Vertice> 2) container = CONTAINER_PRIMARY
19:54:57 <@JonBob> or...
19:55:17 < Vertice> where the pid assigning code automatically assigns it to a pid underneath the value of container_primary
19:55:21 < Vertice> which is defined in sql/ code
19:55:37  * Vertice is looking at the code to see if this could work. 
19:55:59 <@JonBob> Vertice: How would we have a hierarchy in that case?
19:56:32 < josh_k> I think there would be one pid within the navigation menu
19:56:33 < Vertice> not sure. 
19:56:40 < josh_k> that would collect all the proposed links
19:56:55 <@berkes> another solution less technical:
19:56:55 < Vertice> the problem with assigning pid at the moment
19:57:07 < Vertice> is we never know which pid to assign it underneath.
19:57:17 < Vertice> but the value is stored in the db.
19:57:33 <@berkes> /admin is an admin block, / is the navigation block. 
19:57:50 <@berkes> navigation block is by default used for primary links. 
19:58:06 <@berkes> all none navigational stuff must go into /admin block
19:58:30 < josh_k> berkes: ++
19:58:41 < josh_k> this is good
19:58:46 < factory_allnight> does that risk drowning the admin in links?
19:58:54 <@berkes> that would require quirte some restructureing of the paths, but it will work. 
19:58:58 < Vertice> that makes it impossible to get to some functionality without enabling menu items specifically.
19:59:10 < josh_k> because from the user perspective it separates the user functions of "finding stuff" and "doing stuff"
19:59:20 <@berkes> factory_allnight: no, we should even introduce two more next to /admin
19:59:35 <@berkes> but the exact syntax is not to be discussed here.
19:59:35 < factory_allnight> i like the approach generally
19:59:42 < factory_allnight> introduce two more?
19:59:50 <@JonBob> Is "create content" admin?
19:59:53 <@berkes> Vertice: how do you mean?
19:59:57 < Vertice> without enabling menu items by default, it means hiding vast swaths of functionality
19:59:59 <@JonBob> "log out"?
20:00:03 < josh_k> JonBob: in this sense I think it would be
20:00:12 <@berkes> JonBob: re: syntax for other discussion.
20:00:23 < Vertice> so if the user enables the image module.
20:00:35 < factory_allnight> hiding functionality and exposing incrementally and by decision is good
20:00:41 <@berkes> all: I have been experimenting with this restructurin a long time. and found some good defaults, but we should not discuss those details here
20:00:54 < Vertice> factory_allnight: isn't enabling the module decision enough ?
20:01:09 <@berkes> Vertice: if the user installs the image module a link (with children),
20:01:21 <@berkes> will be added to navigation, and thus to the primary links. 
20:01:27 < Vertice> yeah
20:01:33 < Vertice> and then we drown in menu items again 
20:01:52 <@berkes> in a nutshell: my proposal is to strip down navigation to actual "navigation" and make that primary links. 
20:01:53 < factory_allnight> which is what we want to avoid
20:02:06 < factory_allnight> i like the sound of that
20:02:10 < Vertice> i wish dries was here.
20:02:13 < factory_allnight> (though i'm not sure what it means in practice)
20:02:31 < Vertice> i think it makes it harder to find things. 
20:02:51 < factory_allnight> would it be possible to see a demo of this new design?
20:03:00 < factory_allnight> or would that involve a lot of coding for little benefit?
20:03:07 <@berkes> consistent.drupaldevs.org for the restructure. Log in.
20:03:12 < factory_allnight> even just a workflow comparison would be nice
20:03:34 < Vertice> UnConeD: could you sms dries ?
20:04:00 <@berkes> http://www.threesanna.com/nl/node/782 for a working prim-links-from-menu. 
20:04:23 <@berkes> look at the DOM, notice the left menu is aware of the top menu-items. 
20:04:39 <@berkes> But examples do not help us :)
20:05:04 < factory_allnight> oh well... ok
20:05:23 < Vertice> i don't see how theesanna is anywhere close to what we are talking about
20:05:23 < factory_allnight> code only gets me so far before i need to see something
20:05:29 < factory_allnight> i don't either
20:05:32 < Vertice> ditto the consistent one.
20:05:40 < Vertice> which has 3 seperate menu's
20:05:43 < Vertice> and no primary links.
20:05:51 <@berkes> wowow: slow down!
20:06:00 <@berkes> lemme explain:
20:06:01 < Vertice> which, fyi: i find far more confusing
20:06:40 < factory_allnight> lol
20:06:40 <@berkes> consistent shows us (log in first) that "navigation"really only needs to contain less then five items,.
20:06:55 <@JonBob> The Navigate menu would *be* the primary links
20:07:07 <@berkes> do *not* look at the other blocks yet.
20:07:08 < factory_allnight> fyi, in the redesign of civicspace, i'm not using any navigation menus really
20:07:26 < factory_allnight> i'm moving to "fuzzy" navigation
20:07:37 < factory_allnight> or "situational discovery"
20:07:47 < factory_allnight> i don't mean to get off topic
20:07:58 <@berkes> so, if we simply restructure the menus, "navigation", being the default menu container, will be primary links
20:08:11 < Vertice> -1
20:08:21 < Vertice> i don't think 3 blocks is better than 1
20:08:29 <@berkes> Vertice: [20:07:47] <berkes>do *not* look at the other blocks yet.
20:08:33 < Vertice> yeah
20:08:40 < Vertice> but where do the moderate items go ?
20:08:41 <@berkes> that is OT here.
20:08:44 < factory_allnight> but these huge menu systems have very little value when they're dumped full of stuff -- so +1 for reducing the number of menu items, -1 for randomly generated navigation blocks
20:09:00 < josh_k> berkes: where do secondary links come from in the consistent scenario?
20:09:03 < Vertice> and the my account entry ?
20:09:20 <@berkes> please people, do *not* look at those other blocks, for petes sake!
20:09:34 < Vertice> just looking at the first block
20:09:37 < Vertice> it's missing another 4 links
20:09:40 < Vertice> right off the bat.
20:09:46 < Vertice> that don't belong in admin
20:09:57 <@JonBob> berkes: You're asking a lot.
20:10:00 <@JonBob> berkes: You're saying "navigate only needs four links"
20:10:24 <@JonBob> but asking us to trust that the other links have a good home once removed
20:11:20 <@berkes> allright, lets drop this then.
20:11:20 < factory_allnight> yeah, i feel like were working around some pretty specific use cases
20:11:34 < Vertice> yeah. 
20:11:42 < factory_allnight> without solving the larger "how do we let menu items relate to parents/child?"
20:11:48 <@JonBob> berkes: I like the general idea
20:12:03 < josh_k> maybe we can back up a bit
20:12:08 <@berkes> on a sidenote, chances are quite big this restructuring will go into core some moment. 
20:12:20 <@berkes> but lets get back to the topic.
20:12:29 < josh_k> and focus on how we're going to try and allow the primary/secondary links to be powered by the menu system
20:12:48 <@JonBob> berkes: "some moment" > 4.6?
20:13:01 <@berkes> JonBob: maybe...
20:13:06 <@JonBob> berkes: Because I can see how your proposal would work
20:13:08 < josh_k> rather than how the meny system is laid out
20:13:22 <@JonBob> but if it doesn't get in to 4.6, we need a different short-term solution
20:13:27 <@berkes> JonBob: good, you seem to be able to see though the cruft. :)
20:14:33 <@berkes> But, I want to get thsi meeting to an end, so maybe we should summarise it?
20:14:53 <@berkes> we have several solutions:
20:14:56 <@JonBob> I'm still liking the idea of having SQL populate primary links on install
20:15:00 <@JonBob> as a short-term solution
20:15:01 <@berkes> SQL files, static.
20:15:20 <@berkes> introducing a new tree.
20:15:30 <@berkes> introducing some form of parent PID relation.
20:15:58 <@berkes> use the navigation/defaulkt container for primary lins.
20:16:10 <@berkes> did I miss any?
20:16:19 < josh_k> I think the key is to make it easy for admins to set it up how they want
20:16:49 < josh_k> and I think from the admin perspective a new tree is the most easy to understand
20:17:01 < josh_k> unless the menu interface has changed quite a lot
20:17:07 <@JonBob> As menu maintainer, this is how I see each one from a 4.6 perspective
20:17:23 <@JonBob> 1) Static SQL-population
20:17:51 <@JonBob> - No code to write, but requires a good set of defaults not dependent on modules installed
20:17:58 <@JonBob> 2) new tree
20:18:37 <@JonBob> - feels like a kludge, and would have to rewrite a chunk of menu generation algorithms, but wouldn't be too bad to do.
20:18:53 <@JonBob> 3) menu items define PIDs
20:19:07 <@JonBob> - I think this is far out of scope for what could be coded for 4.6.
20:19:52 <@berkes> JonBob: how would skipping 2) be?
20:19:57 <@JonBob> 4) use "navigation" as primary menu
20:20:00 <@JonBob> - Requires massive menu restructuring; seems unlikely since we're already in RC, but if it happens the menu code is not too bad
20:20:01 <@berkes> for 3) can improve lots of other parts in Drupal too
20:20:31 <@JonBob> These are not steps
20:20:38 <@JonBob> they are numbered alternatives
20:21:02 <@berkes> JonBob: sorry for confusion: menu restructurin will never get in 4.6, prolly not even 4.7. for alread yall developers are putterig 
20:21:08 <@berkes> Aah :)
20:22:03 < UnConeD> (just read the backlog... any reason we can't use the MENU_SUGGEST mechanism for menu pre-population?)
20:22:21 <@JonBob> UnConeD: We can use it to suggest items for the main menu
20:22:29 < josh_k> JonBob: for #2, we're talking about having a separate menu defined by default in addition to "Drupal Navigation" which would somehow pick up useful defaults but be configurable by admins?
20:22:39 <@JonBob> but item *location* cannot be suggested; that is determined solely by path
20:22:41 < UnConeD> yes, but why not have a 'menu' => 'primary' or 'primary' => TRUE or whatever to go along with it?
20:22:57 <@JonBob> That is option 2) above.
20:22:57 < Vertice> UnConeD: that's what i'm thinking.
20:23:11 < UnConeD> it's just that we already have suggested menu items, SQL prepopulation sounds like a step backwards
20:23:19 < Vertice> yeah.
20:23:22 <@JonBob> josh_k: Yes.
20:23:36 < UnConeD> well then, 2) +1
20:23:45 < josh_k> #2 ++
20:23:52 <@JonBob> 2 --
20:23:54 < Vertice> #2 ++
20:24:26 < Vertice> although i'd like to experiment with the code a bit. 
20:24:32 < Vertice> i think #3 would be cleaner
20:24:37 < UnConeD> true
20:24:41 < Vertice> because (and this is going to be unpopular) 
20:25:00 <@berkes> and if ever #4 gets going we can still see how it will jhelp us :)
20:25:00 < Vertice> i have completely given up on menu integration in 4.6
20:25:25 < Vertice> i believe it is better for us to do it properly. 
20:25:34 < Vertice> and do it with the integration of phptemplate into core.
20:25:35 < UnConeD> #3) PID -> menus say who their parent is?
20:25:43 <@JonBob> UnConeD: Yes.
20:25:46 < Vertice> yeah. but have it do it dynamically.
20:25:52 < Vertice> so you don't declare a number
20:25:57 < Vertice> you declare a container id
20:26:04 < UnConeD> fwiw, that also sounds like a step backwards as the current path system has an elegant way of declaring and handling hierarchies
20:26:04 < Vertice> which gets populated from the db. 
20:26:29 <@berkes> UnConeD: the path will remain.
20:26:36 < Vertice> so the same way you can split off a different block
20:26:43 < Vertice> and add menu items to it. 
20:26:50 <@berkes> you can /also/ define a parent, above the path system. 
20:27:01 <@JonBob> I strongly dislike having both the path system and explicit parents
20:27:13 < Vertice> JonBob: yeah. it
20:27:16 < Vertice> s troublesome.
20:27:22 <@berkes> okai. fair enough
20:27:22 <@JonBob> I think the menu system is already almost too complicated for me to understand, and I wrote it
20:27:39 <@JonBob> adding even more ways to generate trees sounds like a nightmare.
20:27:42 < josh_k> is there a way to solve this thorugh simplification?
20:27:46 < Vertice> JonBob: you mentioned that it is more complex than it needs to be.
20:27:48 < Vertice> yeah.
20:27:53 <@berkes> pid will also get us close to the way other tree systems in Drupal work, actually.
20:28:04 <@berkes> ~closer.
20:28:21 <@berkes> i.e. books and taxonomy. 
20:28:34 <@JonBob> I can talk for a day (in another meeting) about general menu system rewrites
20:29:07 < Vertice> wouldn't this allow us to get closer to building book trees aswell ?
20:29:20 <@berkes> so, to close this seesion, we all seem to agree on the PId approach, but this needs to be investigated a bit more?
20:29:28 <@berkes> Vertice: yes.
20:29:38 < Vertice> the problem with multiple trees , is you can't copy links between them ?
20:29:50 <@JonBob> Vertice: bingo.
20:29:57 < josh_k> ah
20:29:58 <@JonBob> for some loose definition of "the pid approach" yes
20:30:00 < factory_allnight> ouch
20:30:05 <@JonBob> hook_menu() can only define one link for each path
20:30:11 <@berkes> the book-menu-block issue would be solved too, and taxonomy_menu would become much smaller too, as would my directory.module :)
20:30:22 <@JonBob> the menu admin is able to define additional shortcuts for each path.
20:31:13 <@JonBob> Anyone who is interested in menu system rewrite stuff is free to stay on
20:31:15 < josh_k> so this seems to mean that the "official" drupal solution is going to be a 4.7 thing
20:31:28 <@JonBob> but let's wrap up the primary/secondary discussion
20:31:44 <@JonBob> I thought the point of this meeting was getting a 4.6 solution?
20:31:50 < josh_k> yes
20:31:57 < josh_k> but if we're talking about the PID solution
20:32:08 < Vertice> like i said. 
20:32:11 < josh_k> and that it's 1) more complex and 2) needs more investigation
20:32:15 < josh_k> and we already have 4.6 RC
20:32:17 < josh_k> ...
20:32:26 < josh_k> better to do it right than to do it now?
20:32:31 < Vertice> yeah.
20:32:41 < Vertice> imo
20:32:52 < Vertice> but i am still interested in your patch
20:33:22 <@JonBob> Does anyone have more to add on the primary/secondary issue?
20:33:24 <@berkes> JonBob: personally I never meant it a s4.6 issue.
20:33:30  * JonBob looks for hands
20:33:34 <@berkes> but rather as a "good one".
20:33:56  * josh_k would like to clarify this 4.6/4.7 issue
20:34:12 < josh_k> just so I know how to proceed with some work I'm doing now
20:34:27 <@berkes> josh_k: did you try my patch?
20:34:58 < josh_k> I read it, but didn't apply it; i haven't started working with 4.6 yet
20:35:31 <@berkes> josh_k: it works on 4.5 only ;)
20:35:35 < josh_k> ah
20:35:38 < josh_k> then I should apply it
20:36:21 < josh_k> but in any event, it seems to me that there are several possible short term solutions for people who want this functionality, but that a "drupal way" solution needs more thought and might be part of a wider effort to make the menu system work better
20:36:23 < Vertice> perhaps.. 
20:36:31 <@berkes> what is the URL, so that other can look too?
20:36:52 < Vertice> if we can integrate the navigation menu stuff , into a different module
20:37:06 < Vertice> and move it out of the theme_ for now.
20:37:23 <@berkes> Vertice: good idea
20:37:26 < Vertice> and then make both xtemplate and phptemplate use the $links retrieved from the module.
20:37:39 < Vertice> the module could be a simple 'use this menu'
20:37:43 < josh_k> Vertice: ++ short term solution
20:37:45 < Vertice> hell it could be a simple tab 
20:37:52 <@berkes> Vertice: i see only one caveat there. 
20:37:58 <@berkes> the UI, would need a new page. 
20:38:10 < Vertice> yes.
20:38:30 <@berkes> is that a problem, anyone (and factory_allnight in particular) 
20:38:32 <@berkes> ?
20:38:42 < factory_allnight> lemme read back a sec
20:38:58 < josh_k> I can commit to working on that UI page in the next few weeks
20:39:00 < factory_allnight> ah ok
20:39:01 < Vertice> or have a setting in admin/settings somewhere.
20:39:20 < Vertice> i've given up on giving phptemplate an array of links 
20:39:23 < factory_allnight> yeah, i mean moving menu stuff out of the theme needs to be done like yesterday
20:39:29 < Vertice> i am happy to pass them a $variable 
20:39:35 < factory_allnight> however
20:39:42 < factory_allnight> we need to make themers lives manageable
20:39:54 < factory_allnight> and give them something that they can work with and is manageable
20:39:58 < Vertice> yeah.
20:40:01 < Vertice> which is where you come in
20:40:02 < factory_allnight> and infinitely deep UL is not good
20:40:17 < Vertice> factory_allnight: me and ber went over this
20:40:25 < Vertice> berkes: tell them about the css =)
20:40:28 < UnConeD> nested ULs sounds like something that is nice to have but will only make themers do more work
20:40:41 < Vertice> we actually split it out into 2 ul's
20:40:42 < factory_allnight> lol ok ok
20:40:45 < factory_allnight> i know
20:40:48 < factory_allnight> but it should be optional
20:40:51 < UnConeD> unless we have a simple, pluggable set of css that works with anything, fine, but i don' think we have
20:40:52 < Vertice> that can be placed seperately.
20:40:56 < factory_allnight> whether it's overriding it or whatever
20:41:09 < factory_allnight> those of us who are semantic zealots need to be appeased!
20:41:12 < factory_allnight> :)
20:41:32 < Vertice> yeah. which is why we want the menu xhtml/classes/id's to be well thought out.
20:41:33 < UnConeD> More definition lists in rupal
20:41:36 < UnConeD> More definition lists in Drupal ;)
20:41:50 <@berkes> NEsted ULs --
20:41:59 < UnConeD> was just being silly
20:42:11 <@berkes> I read myself into it, and it limits the posibilities a lot
20:42:17 < UnConeD> in any case, the menu is output recursively
20:42:33 < UnConeD> switching between recursive ULs or not should be easy, just move the nest in / out the parent
20:42:50 <@berkes> thats is why i posted the url of http://www.threesanna.com/nl/node/782
20:42:50 < UnConeD> so i'd say go for non-nested in drupal, let the themer override it into nested if he/she wants
20:42:50 < factory_allnight> yeah
20:42:52 <@berkes> look at the DOM.
20:43:06 < factory_allnight> sure that's fine
20:43:12 < josh_k> could this module have a function for themers to pull either two uls or one nested set?
20:43:12 < factory_allnight> since we can't assume tabs
20:43:20 < factory_allnight> i would REALLY like that
20:43:30 < factory_allnight> (but that's a major themer-geek tool)
20:43:30 < josh_k> because that would be pretty easily done
20:43:39 < factory_allnight> i already wrote the code (so did josh i think)
20:43:41 <@berkes> josh_k: yes.
20:43:50 <@berkes> already implemented
20:44:13 <@berkes> josh_k: please read the comments in the patch :)
20:44:24 <@berkes> (which I cannot find)
20:44:25 < UnConeD> that threes anna site is odd
20:44:32 < josh_k> yeah, i don't get it
20:44:43 <@berkes> tell me?
20:45:17 < josh_k> there are no secondary links
20:45:22 <@berkes> what is odd, what do not you get?
20:45:22 <@JonBob> UnConeD, josh_k: I think it's going for this interface:
20:45:24 <@JonBob> http://adachristian.org/
20:45:34 <@berkes> josh_k: there are seconday links, the left menu is.
20:45:38 <@JonBob> The tabs with the left nav attached
20:45:41 < josh_k> maybe it's because I don't speak dutch, but I don't see the connection between theater and methode
20:46:03 <@berkes> josh_k: the left menu depends on the primary items
20:46:05 < UnConeD> i don't see anything that relates to what we're talking about?
20:46:10 < Vertice> josh_k: we could pass two variables
20:46:15 < UnConeD> ah k
20:46:20 <@berkes> UnConeD: the top row is primary menu items,
20:46:20 < josh_k> ah
20:46:28 <@berkes> the left menu seconday-till-infinite
20:46:29 < josh_k> berkes: this is not obvious unless you click around
20:46:41 < UnConeD> ber: because of the way the page is layed out, this relation is not at all obvious
20:46:41 < josh_k> but I get it now
20:46:45 <@JonBob> UnConeD: We stopped talking about anything in particular like 15 minutes ago
20:46:50 < UnConeD> the top nav is aligned with the main page content
20:46:54 <@berkes> UnConeD: i did not do the theme :)
20:46:59 < josh_k> much like
20:47:00 < UnConeD> while the sidebar is separte from that
20:47:00 < josh_k> http://www.outlandishjosh.com/civicspace/life/places/nyc
20:47:06 < UnConeD> but that aside ;)
20:47:50 <@berkes> UnConeD: tell me. I changed some things, but the designer weant mad and nearly got me "fired", becuase I "touched"his design ;)
20:48:07 <@berkes> josh_k: no, not really.
20:48:17 < josh_k> how do they differ?
20:48:27 <@JonBob> berkes: Not really? Looks like "exactly" to me
20:48:27 < UnConeD> well the page design looks like:
20:48:27 < UnConeD> [ |_]
20:48:27 < UnConeD> [ | ]
20:48:27 < UnConeD> instead of
20:48:27 < UnConeD> [___]
20:48:29 < UnConeD> | | ]
20:48:30 < josh_k> other than that I'm putting the secondary links on top
20:48:59 < josh_k> and tertiary - nth-degree links appear in a block
20:49:10 <@berkes> josh_k: I have no time, actully to discuss this anymore. Sorry.
20:49:32 < josh_k> allright, well I'll install yr patch and send an email
20:49:50 <@berkes> josh_k: then we do have the same. It was just theat "places" was not active. when in the right menu it was.
20:50:40 < josh_k> true; bad output on my part
20:50:42 <@berkes> http://www.outlandishjosh.com/civicspace/life/places/nyc/greenpoint << in the second tabs row, the active is forgotton, that confused me. 
20:51:00 <@berkes> but other than that, we seem to have the same. 
20:51:01 < josh_k> indeed, this seems to be a reason why your patch is better than mine ;)
20:51:27 <@berkes> now: whats also possible with my patch, is have tertiary links somewhere else, etc.
20:51:31 <@JonBob> Is it safe to adjourn this meeting then?
20:51:36 < Vertice> getting the default .sql in for core would make this patch better too.
20:51:50 <@berkes> JonBob: It is. 
20:51:53 <@berkes> I will post the logs on drupal.org later. 
20:52:05 <@JonBob> Okay.
20:52:09 <@berkes> and our conclusion, but now i badly need food.
20:52:16 < Vertice> night guys
20:52:20 <@berkes> starving.
20:52:22 <@JonBob> I will bore you all with menu system ideas later.
20:52:24 < josh_k> thanks all
20:52:31 -!- Vertice [~adrian@rrba-146-95-221.telkomadsl.co.za] has quit []
20:52:38 -!- josh_k [~joshk@68-174-139-56.nyc.rr.com] has left #drupal-phptemplate []
20:53:20 -!- factory_allnight [~cmessina@h-67-100-116-146.snvacaid.covad.net] has left #drupal-phptemplate []
20:53:33 -!- JonBob changed the topic of #drupal-phptemplate to: Everybody out of the pool.
20:53:43 -!- JonBob [~jchaffer@206.67.165.200] has left #drupal-phptemplate []
21:07:58 -!- UnConeD [~Pioneer@kotnet-146.kulnet.kuleuven.be] has left #drupal-phptemplate []
21:46:07 -!- grohk [~Brady@user-0cev5cn.cable.mindspring.com] has quit [Remote closed the connection]
23:30:43 -!- factory_allnight [~cmessina@h-67-100-116-146.snvacaid.covad.net] has joined #drupal-phptemplate
23:30:51 -!- Irssi: #drupal-phptemplate: Total of 4 nicks [1 ops, 0 halfops, 0 voices, 3 normal]
23:31:03 < darix> berkes: should i post the log file somewhere?
23:40:17 <@berkes> aah darix, yes please, 
23:40:31 <@berkes> darix, there is an issue on this somewhere on drupal.org. 
23:40:38 <@berkes> bu I could not find it :)
23:40:41 -!- factory_allnight [~cmessina@h-67-100-116-146.snvacaid.covad.net] has quit []
23:41:13 <@berkes> darix: if you can post it there, that would be brilliant, otherwise just mail it to me.
23:42:42 < darix> http://monsters.rsn.uni-rostock.de./~darix/site/filebrowser/drupal