Textpattern Support Forum

thebombsite wrote:

Is that image meant to link somewhere Stef?

Remember that depending the forum theme you use, the image might not fit the column well and it might get cut if it exceeds the width. If that is the case, remember to Rclick / View Image.

thebombsite wrote:

So does the display of the main image on the edit screen have a width or max-width setting or does it always display at full-size?

Ah, sorry I misinterpreted your earlier comment! Yes, the image links to its full size counterpart. Nothing fancy at the moment — just shows the raw image in your browser window.

The main image is max-width limited to, ummm, can’t remember. Think it’s 450px at the moment. That’s so it all fits comfortably within 1024 × 768. We tried elastic so it could take advantage of wide screen monitors but it doesn’t work given the fact that the admin side’s container isn’t elastic.

At the moment the 450px is hard-coded so that the <img width> attribute is never greater than 450px. I don’t like this approach and would prefer to allow themes to set it, but for some reason the CSS max-width wasn’t responding to my advances. I put it down to the fact my CSS coding is rather rubbish. If anybody would like to propose some cross-browser style rules that would work to limit the image’s dimensions to a maximum width while allowing smaller images to remain at their native resolution, please let me know how it might be done. I can offer a login to a dev space so someone could have a fiddle with Firebug / the web dev toolbar if required.

Gocom wrote:

The max-width should work. There’s nothing else to that, just the img {max-width:450px;}.

I’ll try it again. Perhaps I was just being dim.

Usually scaling looks awful

Yes it does. I don’t know how it handles it if it uses CSS — probably the same!

But I had a bunch of fairly large 2048px-width pictures uploaded and it didn’t look so bad.

if the image is just a raw link, it will either force a new tab/window or causes duhs and dohs.

Yes. The raw link will have to go. It was just a placeholder so I could quickly see how badly the browser scaled :-)

I would like to see on-fly resizing with JavaScript.

Got a script in mind? I could check it out.

Other option to scaling is hiding

Yes, using overflow:hidden would also work with a hyperlink above the picture “View full size image” or something. The link would solve another problem: as it stands EBL_Image_Edit will not work if the image itself is hyperlinked because as you drag over the picture to crop/zoom/resize/whatever, you sometimes trigger the anchor. So I would prefer not to have the picture hyperlinked at all. The only problem with a truncated picture is that you can’t use EBL_Image_Edit (or equivalent) because you can’t see the entire picture at once.

When they are on the side, it just means that my wide photo won’t fit the screen.

True. I hadn’t considered widescreen photos much. Figured they’d just get squatter. But giant pictures at the top of the screen force you to scroll down to get to the meta information area, which is the whole point of the Image Edit page. So I figured that a scaled-down image — sort of a larger version of the thumbnail — was enough to give you:

1. an overview of the picture; enough that you can make informed choices about what meta data to type in ;-)
2. the ability to use 3rd party tools to crop/resize/create thumbs from it
3. minimal / no scrolling to reach the meta & manipulation section

And If my thumbnail is huge, I would still have to scroll down

Another good point. I’ve never used huge thumbnails but theoretically it’s possible so you’re right it needs to cater for this somehow. I guess it’d have to be yucky scaling again with a link to the full size thumb! Incidentally, large thumbs would also impact the grid view — the thumbnails are currently scaled there too. But some kind of per-user pref to control grid cell size might make things more flexible for site authors.

The uploading and creating thumbnails looks bit confusing

Good point. Newbies might not like it. But newbies and veterans alike don’t care for it the way it is now either becuase it’s also not exactly logical!

There are buttons everywhere

Yep. Those are the existing buttons from the existing site layout, just squished over on the right. The markup and position of that will have to change because you’re right, it’s terrible. As for the layout of the buttons — I don’t kow why the Upload buttons are floated right like that. I think it’s because the markup is so bad — tables inside tables inside tables — that it wasn’t possible to get at them easily. Since this mockup was done, the markup has changed dramatically so it may well be easier to figure out a better layout and alter the workflow completely.

btw, I originally had the Replace Image above or below the main image (because it’s related to the main picture) but it looked crap. And also it separated even further the fact that caption/alt might not ‘belong’ to the main image.

For newcomer or non-techie it might look that you can actually use the uploading and cropping at same time, when that is not the case.

Yes. It’s the same now. Yuk!

Maybe collapsing and expanding panels could do.

That would be my preference as well; to group related things together, perhaps using legend boxes like on the right-hand side of the Write tab? But making them collapsible.

Ummm. Well as far as employing an image-resizing script is concerned that would be a nice, welcome jump to make. At the moment a lot of the sites and theme ports I’m doing are using several size variants of each image, depending on whether they appear in an article_list or individual_article view, maybe in the sidebar, maybe in a “tags” listing or category listing or wherever. At the moment I am using timthumb.php to generate all the images on-the-fly so the only image that needs uploading to Txp is the largest version the user wants you to see.

Now that is all on my side of course, however if Txp had it’s own resizing script (as a separate script rather than within the base code), maybe sitting alongside jquery, not only would someone like me simply be able to point at it when I needed it, the possibilities for it’s use within Txp admin and Txp tags seems endless.

Sticking to the Image Edit screen for now, you wouldn’t need all the thumbnail fields nor a thumbnail. Just the main image, centred, maybe resized to a max-width and the main image fields underneath. I know that pretty much retains the current page layout but it will be a shorter page and less confusing as it only deals with the main image. A small thumbnail could be auto-generated for the Image listing pages. Even now, when I don’t need a thumbnail I begrudge the space it occupies but on the other hand I find that the Image listing pages are lot easier to negotiate if they have thumbs in them.

But then I’m thinking it could also be used within tags (though you are the coder not me but if there are no thumbs in the Txp image base this would be a definite requirement) so that I could go <txp:thumbnail id="14" link="1" link_rel="prettyPhoto" width="200" class="alignright" /> and end up with an auto-generated thumbnail with a width of 200px and whatever the relative height is, floated right, linked to the original image and using prettyPhoto for a lightbox. Have you any idea how much easier my life would suddenly become? Not to mention the same for the <txp:article_image /> and <txp:image /> tags.

jameslomax wrote:

the Images tab also sucks. That single column display is appalling use of white space

cf. Suffice to say it’s grid-based :-)

txp uses some kind of locked grid structure to organise the thumbs in that tab

Yup. It’s awful markup. That’s another reason why it’s taken so long to sort this out; the tab needs a complete rethink. And rethinking one tab means rethinking a lot of the way TXP’s markup looks. Hence it’s a job for TXP 5.

I should clarify that the image I posted above (of the edit screen) was primarily intended to be my attempt at a simple shuffle around to ease image editing in the next version of TXP. Whether it sees the light of day remains to be seen. To do it properly, as you say, requires new markup and deletion of the tables that litter the tab. I don’t think any image plugins aside from lam_browse_by et al, and EBL_Upload/Image_Edit et al would be affected by such a massive back-end reshuffle on this tab. But to commit to doing it now in time for 4.3.0 would mean it would need to be done again in TXP 5 when the rest of the admin side changes (unless I somehow knew what TXP 5 will look like via my crystal ball!)

with the various plug ins that change the Admin interface quite drastically, something similar could be done with the Image tab design…..

Sadly not. It really is a mess in terms of markup. Any mods would be restricted to CSS as there are no plugin hooks on that tab (just one on the Image Edit screen).

It is a huge undertaking to unpick it all and build it up again from — almost from scratch. I’m not averse to huge undertakings, as you may have noticed(!), but I’m not a designer, nor am I a hardcore image editor. So the best I can do is take as many different viewpoints as possible — and this thread is a great place for that — split them into “yes, makes sense for core” and “no, this is better as a plugin/theme” and then proceed accordingly to build a framework for the tab that can benefit as many Image-minded folk as possible while keeping TXP’s options open in terms of future markup and plugin rejiggerisation.

I’ve begun the process of releasing us from the shackles of tables by refactoring the classes and IDs. I’m going to revisit this tonight now I’ve thought about it a little harder to see if I can do more to help this tab be more easily alterable.