Patchfile is attached with the current state of the in-place editor. This includes ripping out the render pipeline to make it totally pluggable, and a few other goodies as well. This still needs a solid chunk of work before it will be ready to be released, though it's stable enough (...or nearly, anyway) that it can be put back into dev. Here are the major holes that are currently on my radar:

  • The legacy renderer (panels_renderer_legacy) still needs retouching for full backwards-compatibility, and some more logic needs to be written around that in general.
  • On the note of backwards-compat, the standard renderer will break cache plugins (or at least, will change cache data), and potentially break style plugins that provide panel styling. merlin has suggested doing versioning of the plugins, which I was initially amenable to, but then came up with a reason I thought it wasn't such a good idea. I can't remember it offhand, but I'll post it here when I do recall.
  • There is virtually no documentation written. I really don't want to release this without documenting it well, if not thoroughly - this is a really cool new thing that I very much want people to be able to extend!
  • There's still a fair bit of hacky, or at least one-off code in place. See the changes in panel_context.inc, or the colossal and fugly panels_renderer_ipe::render().
  • The DND itself needs some work; I'm not very happy with the visual cues we provide to indicate where target areas are.
  • Empty regions still don't work with DND; this is something that needs addressing both in php- and js-land.
  • Some new AJAX responders are going to need to be written that place more control over where content being sent back is ultimately placed. Requiring that to be done in PHP is the primary reason that portions of display-edit.inc had to be copy-pasted into panels_ipe.module. We may be able to release without fully doing this, but it's gotta be done eventually.
  • AJAX refresh of panes currently isn't working because I'm in the midst of restructuring the markup to be more sane & portable.
  • The 'Add new pane' button gets mixed up in the list of sortables. This is part of the reason why I'm restructuring the markup to be more sane.
  • The 'edit' button appears for all panes, whether or not they actually have a settings form. Clicking 'edit' on panes without settings forms results in an error.
  • 'Cancel' does cancel editing (i.e., changes are not saved), but doesn't move everything back to where it was. The right-now-solution is to just trigger a full page refresh, but in the long term it would be nice to be able to just revert everything back to where it was.
  • The JS object is in a state of flux; it works, but even just the structure of its methods should indicate I have quite a bit more planned for it than is currently coded.

Just generally speaking, there's still a fair bit experimenting & tinkering code in there. In short...don't judge me!! :P

Comments

sdboyer’s picture

StatusFileSize
new71.45 KB

Aaaand the stupid patchfile didn't post. Here it is.

sdboyer’s picture

Also, I'm gonna out of commission for a couple days, but will be starting back in on this stuff in earnest by the beginning of next week (at the latest). My general gauge is that the really critical, release/reintegration-blocking stuff up there totals to about four good days of work.

sdboyer’s picture

Final addendum - I've been doing all the work in git locally, and have a github mirror: http://github.com/sdboyer/panels/tree/dr_obj <-- Note that it's the dr_obj branch!

Development will continue there until this gets reintegrated, although I'll keep this post up to date with patchfiles as well.

joshk’s picture

Summarizing some discussion with merlinofchaos in #drupal-dev just now:

  • This is a big patch, and it needs to not break things.
  • The "legacy renderer" concept is pretty scary. Could lead to a lot of confusion.
  • The way this works is if users are totally oblivious to this and never ever have to think about what renderer their panel panes are using. Avoid issue-queue/support hell.
  • Also, developers should be similarly free to be oblivious to this. If they don't know/don't care, the old way will continue to "just work." Panels aught to autodetect what kind of pane is coming and do the right thing.
  • In this way, its' more like we're adding a new "advanced/awesome" renderer, rather than a "legacy" one.
  • The vision here is to get the pattern down with this innovation, and then do it "all the way" in Drupal7/Panels4
  • Front end UI should get a lot of testing/feedback. We all want something intuitive.

I'll start in on testing shortly, and hopefully we'll soon have a demo site up and running which we can use to start soliciting feedback on the UX.

sdboyer’s picture

Just noting that the original patch posted here isn't compatible with some recent changes in ctools. i'll be updating the patch presently...

sdboyer’s picture

StatusFileSize
new71.58 KB

New patch. None of the original glaring issues addressed - just works again with the latest ctools dev.

joshk’s picture

This patch works against current -dev branch of panels, and is functional with ctools. Basic testing is functional.

We should get UX people to recommend on the drop-areas. It could be more intuitive.

panels/panels_ipe/images/dragger.png is missing (actually the whole /images directory). My guess is it'll look a bit better when that's in place.

sdboyer’s picture

StatusFileSize
new946 bytes

Yeah, the image file doesn't come through in a patch, does it...

For those who want to see it with the dragger (which itself is done fugli-ly, and needs work), i've attached that image.

yoroy’s picture

Subscribe. I will regret this :)

rupl’s picture

New patch works much better than the first! Working on some UX feedback.

mstef’s picture

Sounds interesting..haven't tried it yet.

Are there any plans in introducing something like per-user Panel settings coupled with this, to create a great drag-n-drop dashboard-like functionality?

Home Box is available but it doesn't use CTools or do anything great like Panels does. The architecture seems horrible too...

merlinofchaos’s picture

The same process used for og_panels could be set up to provide user dashboards, I think. It could be done on user/%user or it could be done elsewhere (in which case not *too* much more than just managing user displays needs to be done). It's something that's been wanted for a long time. To be fair, a lot has been held off because sdboyer really wants blueprints for it, but we can do like og panels does without blueprints. It's not as good of a solution but it can still be effective.

mstef’s picture

Updating from 3.3 to the latest dev breaks might site's old panels..Is there something that can be done?

Patch won't apply either..am I missing something?

merlinofchaos’s picture

Breaks how? (You may need to update CTools at the same time if it makes them all disappear. See the system status page)

mstef’s picture

Wasn't using the latest DEV of Ctools...then I was...then ran update.php to get things running again...

mstef’s picture

How do I try this out now? Can't find anything..

Ooh looks like I should enable the new module first..

mstef’s picture

I'm getting the save/cancel buttons duplicating a lot..

sdboyer’s picture

re: #12 - yeah, too much has been held off b/c I want the mythical blueprints to work. Probably better at this point to just start doing the one-offs. :(

@mikestefff - I know that the 'cancel' button right now doesn't appear to work (though if you hit 'cancel' then refresh the page, you'll see things back the way they were). But "duplicating a lot" sounds like something different - could you elaborate?

rupl’s picture

StatusFileSize
new72.15 KB

Here's a first run, I tried to make it a little more familiar to current Panels users. Feedback welcome!

  • Moved the drag handle to be the full gray bar across the top instead of just the drag graphic. Do we really need the graphic at all if the cursor is providing that cue?
  • Working on a less disruptive layout visually, sdboyer mentioned he doesn't want to drastically change any padding/margins in editing mode for this style of IPE
  • Solved the 'add new pane' sortable issue by absolutely positioning the button at the bottom of the pane.
mstef’s picture

Looks very nice...

I'm very interested to see where this is going. On the side, I'm completely rewriting Home Box to be built more like Panels/Context, etc, in terms of architecture, exportables, etc...Mainly because I need per-user settings and the simplicity is there for a 'regular' user.

I'd be interested to hear your feedback, once completed..

jenlampton’s picture

UI input:

We like the improved dragger bar instead of the handle.

But we don't like having multiple "add new pane" links. They seem to be confusing when placed at the "bottom" of each region, since they hover below content instead of at the true bottom of the space. When there is no content in a region they don't appear at all (which is probably fixable) but...

It might be better to place the "add new pane" link in the same div as the "save" and "cancel" buttons, either to the right or to the left, and spaced out some. This gives people one place to go when adding something new. By default, the new panes could either be placed into the top-left-most region, and the page could scroll up to the new pane. Or, my personal preference, the pane could be absolutely positioned in the very center of the browser, until the user "dropped" it into place. Then the rest of the content on the page could move out of the way to make for the new pane. :-)

sdboyer’s picture

Yeah, I've been working on the placement of the 'Add New Pane' button. Well, working on creating a better framework so it can be better placed, anyway. I do agree that they feel out of place without something that visually indicates the boundaries of the panel region itself.

Absolute-positioning-until-drop is...interesting. Feels like something difficult to do well, though - I'd like some more thoughts from other folks on that idea before I seriously investigate it :)

sdboyer’s picture

@merlinofchaos: somewhere in the backscroll on IRC, I recall you saying something like "whaddaya think about making the 'Customize this page' button into a toolbar?" YES. Actually, that was the original goal, but I shied away from it because it wasn't strictly necessary to get working right away, and it was sucking up too much time. Ideally, though, that will be the place where we can stick all meta-operations, and it will happily accommodate them. So, if the IPE allows it, things like changing layouts, managing locks, facilitating blueprints interaction maybe...whatever. We tuck all of it into that toolbar.

That said, internally all those options should be a layer abstracted, so that an IPE plugin can easily choose to relocate all those things into a separate control area if it does so desire.

sdboyer’s picture

StatusFileSize
new77.58 KB

Got nearly done with the work that would handle empty regions and put the 'add new pane' button in more intelligently, then realized that I'd forgotten about the fairly standard & expected practice of putting pane separators into style plugins. Ugh. So the patch that's attached is a bit in the middle of a cycle, but since I'm going out of town and don't know how much time I'll have before Tuesday, I wanted to get this latest round of work up. At the very least, the patch will apply cleanly to the Panels 3 branch tip :)

squiggy’s picture

subscribing

crea’s picture

Subscribing

sdboyer’s picture

StatusFileSize
new77.72 KB

Wow, I left a big, fugly bug in there. New patch, this one should apply cleanly against the DRUPAL-6--3 branch tip and won't cause all your panes to disappear :)

Remon’s picture

+1

Remon’s picture

The patch in #27 applied properly on panels 6.x-3.5 with ctools 6.x-1.6 and cleared all cache but some panels has all panes dissapeared and clicking on "Customize this page" shows an alert that contains "An error occurred at /panels_ipe/ajax/edit/1. Error Description: 404: Not Found"!

dawehner’s picture

"An error occurred at /panels_ipe/ajax/edit/1. Error Description: 404: Not Found"!

Then you have to clear the menu cache first.

Remon’s picture

I did but it didn't help :(

summit’s picture

Subscribing, greetings, Martijn

sdboyer’s picture

StatusFileSize
new91.65 KB

Yeah, some people have been reporting problems with that latest version on clicking that link. I can't replicate it locally, unfortunately.

I'm posting another version primarily as a last-minute debugging attempt, I'm seeing some weirdness on my laptop that wasn't happening on my server last night.

sdboyer’s picture

Component: Display rendering » In-Place Editor (IPE)
Status: Needs work » Fixed

Marking this fixed, as the IPE has been committed (which was the basic goal I had when posting this issue). I've added an IPE component to this queue, so we can open other issues under that as needed - and it will be needed, as there's a lot still to be done :)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

merlinofchaos’s picture

Hey rupl if you see this -- do you still have the work you did to get that picture above? I'd love to get your CSS so I can clean up the visuals on the IPE now that it's in.

rupl’s picture

Status: Closed (fixed) » Needs review
StatusFileSize
new4.47 KB

No problem!

merlinofchaos’s picture

Status: Needs review » Fixed

I've taken part of the CSS you've done (particularly the cleanup to the !important and proper spacing on some CSS elements that were not properly spaced).

I didn't like the look of some of the changes (particularly the background changes on the links made them hard to see) so I left that part out. There are some smaller changes that taken individually I maybe should have kept. If you want to continue tweaking this, let's do that in another issue.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.