Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Offline
Re: Textpattern 5 UI css development
etc wrote #338320:
Thank you. I have slightly reworked the Draggable one, it should be compatible with (some) touch devices now.1
1 Nota bene: jQuery UI does not seem to support touch-drag.
Safari (and console error below)
- dragging does not work (1px then another 1px then the drag movement selects text in the dialog and in the background)
- the movable dialog is present immediately under the draggable one
Firefox:
- draggable dialog seems to work
- movable dialog is present at top left of page
TypeError: $.plot is not a function. (In '$.plot($("#flot"), [{ color: "#942C1E", data: d}], { xaxis: { mode: "time", tickLength: 0, show: false}, yaxis: { show: false }, grid: {borderWidth: 0, hoverable: true, clickable: true } })', '$.plot' is undefined)
jquery.min.js:2:31678I dont’t think a draggable dialog makes much sense on a small-screen device. On a tablet like device that could sometimes be helpful, although iPadOS is definitely not geared towards that sort of actions.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Textpattern 5 UI css development
phiw13 wrote #338322:
Safari (and console error below)
- dragging does not work (1px then another 1px then the drag movement selects text in the dialog and in the background)
- the movable dialog is present immediately under the draggable one
Yep, I see, thank you. It is related to this bug (?) and needs some refactoring.
I dont’t think a draggable dialog makes much sense on a small-screen device. On a tablet like device that could sometimes be helpful, although iPadOS is definitely not geared towards that sort of actions.
Anecdotically, it works quite well now on iOS and iPadOS I have tested, both with finger and pen.
Offline
Re: Textpattern 5 UI css development
etc wrote #338324:
Yep, I see, thank you. It is related to this bug (?) and needs some refactoring.
I see you have made some progress to have the dragging work on Safari, and Brave (Chromium). All 3 main desktop rendering engines now work.
Interesting tidbit: Safari and Firefox show the default cursor icon while dragging. Brave shows the copy cursor icon. All 3 show the move cursor icon before/after dragging when hovering over the header.
Note: could you remove that non-functional “Movable dialog” while testing? It is kinda confusing to have it there esp if you don’t plan to use it anyway
Anecdotically, it works quite well now on iOS and iPadOS I have tested, both with finger and pen.
Fine, thank you for testing those. I haven’t had time to do it. I still don’t see any point dragging the dialog around on small screen devices. On tables like devices, it certainly can be useful.
–^–
Where do you intent to use this? The preview dialog on the write panel, the tagbuider dialog on pages and forms.
For the inline help widget, the popover api (help example) might be interesting.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Textpattern 5 UI css development
phiw13 wrote #338326:
I see you have made some progress to have the dragging work on Safari, and Brave (Chromium). All 3 main desktop rendering engines now work.
Took me 3 attempts. Browsers diversity is still fun.
Interesting tidbit: Safari and Firefox show the default cursor icon while dragging. Brave shows the copy cursor icon. All 3 show the move cursor icon before/after dragging when hovering over the header.
The header cursor is set via css, but browsers default behaviour on drag is not very uniform neither. I’m fine with it, adding an extra event listener might be bad for the fluidity.
Note: could you remove that non-functional “Movable dialog” while testing? It is kinda confusing to have it there esp if you don’t plan to use it anyway
It’s hidden now.
I still don’t see any point dragging the dialog around on small screen devices. On tables like devices, it certainly can be useful.
Yes, especially if they support css resize. Safari on iOS has some time to catch up before txp5 release.
Where do you intent to use this? The preview dialog on the write panel, the tagbuider dialog on pages and forms.
For the inline help widget, the popover api (help example) might be interesting.
Stef has written a nice txp UI library, but it needs to be completed with a bit of js to enhance the user interaction. jQuery UI looks outdated, the plan is to replace it with vanilla js. Preview, certainly. As for the tagbuilder, it needs to be refactored (if we decide to keep it). The current hard-coded implementation makes it outdated on each tag/attribute addition/removal. We need to find a way to register (core or plugin) tags with their attributes to automate the construction.
Offline
Re: Textpattern 5 UI css development
etc wrote #338328:
Stef has written a nice txp UI library, but it needs to be completed with a bit of js to enhance the user interaction.
This, +100. Anything you can do to make it more complete before 4.9 drops will be a boon, but if it has to wait till Txp 5 then so be it. There are definitely some gaps in the library.
jQuery UI looks outdated, the plan is to replace it with vanilla js.
Yes yes yes.
As for the tagbuilder, it needs to be refactored (if we decide to keep it).
Yes, we should keep it. I was surprised at how many people actually use it. But it’s a royal pain to keep in sync with the real tags, so anything that can be done to reduce the load and have it grab attributes and implementation info from core code works for me.
As you say, retrofitting lAtts() (maybe?) with some kind of attribute registry (or vice versa: build a registry and have the tags and builder read from it, though that could break encapsulation and means plugins need to catch up) would mean less code repetition and less chance of the tags and builder drifting out of sync.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Textpattern 5 UI css development
etc wrote #338328:
Took me 3 attempts. Browsers diversity is still fun.
The header cursor is set via css, but browsers default behaviour on drag is not very uniform neither. I’m fine with it, adding an extra event listener might be bad for the fluidity.
cursor: grabbing would eventually be more appropriate (rather that copy); there is no dragging cursor. JQUI uses cursor:drag the whole time.
Yes, especially if they support css
resize. Safari on iOS has some time to catch up before txp5 release.
that would lovely, one day in my next life, maybe.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Textpattern 5 UI css development
Bloke wrote #338329:
This, +100. Anything you can do to make it more complete before 4.9 drops will be a boon, but if it has to wait till Txp 5 then so be it. There are definitely some gaps in the library.
At this point I think it would be better to wait for TXP 5. Unless you plan to wait another 6 month before release…
stylesheets might need updating, widget might need to testing, etc, etc, etc.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Textpattern 5 UI css development
Bloke wrote #338329:
retrofitting
lAtts()(maybe?) with some kind of attribute registry …
looks tricky, since not all plugins are loaded on the admin side, and arbitrary forcing tags execution might be hazardous. I’d rather prefer registering tags/attributes on plugin install, by introducing some ‘register’ life cycle event. No clear idea atm.
phiw13 wrote #338330:
cursor: grabbingwould eventually be more appropriate (rather thatcopy); there is nodraggingcursor. JQUI usescursor:dragthe whole time.
Browsers reset it on every pointer move (or rather I don’t know how to prevent it). We’d need to register an ondrag listener (more or less like jQUI), but it might be expensive. We do it on touch devices (they don’t seem to support drag’n‘drop API), you can compare the mouse vs touch fluidity on a laptop with a touch screen.
At this point I think it would be better to wait for TXP 5. Unless you plan to wait another 6 month before release…
Agree. I would release 4.9 asap and turn the page.
Offline
Re: Textpattern 5 UI css development
Bloke wrote #338329:
retrofitting
lAtts()(maybe?) with some kind of attribute registry (or vice versa: build a registry and have the tags and builder read from it, though that could break encapsulation and means plugins need to catch up) would mean less code repetition and less chance of the tags and builder drifting out of sync.
Well, this was too tempting, so I’ve added getAtts() function to Registry:
<txp:php>
global $production_status;
// Silence warnings
$production_status = 'live';
$registry = Txp::get('\Textpattern\Tag\Registry');
foreach($registry->getRegistered() as $tag => $f) {
echo "<h4>$tag</h4>";
dmp($registry->getAtts($tag));
}
</txp:php>Use with caution: if a (core or plugin) tag does not call lAtts() or calls it too late, its code will be executed.
Offline
Re: Textpattern 5 UI css development
etc wrote #338359:
Use with caution: if a (core or plugin) tag does not call
lAtts()or calls it too late, its code will be executed.
I can see that would be the case with your code running every tag there, but are there general implications that plugin authors need to be aware of? And if so, what would I need to check in existing plugins? I can see you’ve implemented it on GitHub.
TXP Builders – finely-crafted code, design and txp
Offline
Re: Textpattern 5 UI css development
jakob wrote #338377:
are there general implications that plugin authors need to be aware of? And if so, what would I need to check in existing plugins?
A typical tag looks like this:
function my_tag($atts, $thing = null)
{
global $pretext; //for example
extract(lAtts(array(
'name' => '',
'value' => '',
), $atts));
/* plugin code */
return $out;
}As long as lAtts() is called before something risky is executed, it should be safe, because the function exits immediately (via an Exception) after lAtts(). Most plugins adhere to this workflow, but there is no guaranty.
Offline