I’m not sure it’s bug or feature.
I’m not sure it’s bug or feature.
Anyway.
The folder ‘FolderX’ has horizontal RIGHT alignment.
And its right margin is set to 200px or so.
Under this condition, if I tap the area of folder’s margin, it blocks all tap event. So if I tap in upper circle area, play store app is open, but if I tap lower circle area, folder blocks tap. As a result, in the margin area of folder, we have no way to get any events.
In HTML(or other thing), in this case, only content area reacts to event. I think its bug.
]]>(Next Post) koolSTUFF »
D5 Creation
< ![CDATA[
It’s not a bug.
Margin belongs to the Folder, so tap goes to folder not through.
]]>
< ![CDATA[
gerd reuter As I said, Im not sure its bug or not. But it seems not natural(?). If you do HTML with Javascript or any other language, you will get other behavior, which I think is reasonable.
Padding belongs to contents, but margin only defines its spacing bewteen its contents and side contents.
Moreever in current LL behavior, we have no method to get event in that margin area. If you assgin “tap an empty space” event handler, you can’t get that event. Its like a blackhole.
]]>
< ![CDATA[
I wonder why use all that margin, instead of just sizing/placing the folder where you want it?
If there is no particular reason you did it that way, seems like you could easily fix your issue.
Seems like you intentionally blocked the play store icon.
]]>
< ![CDATA[
Chris Chastain Yes, ways to do some are various especially in LL. Under current LL way, I guess we can solve that fesign with no problem, let alone its simple or less simple.
I’m revising my Windows7 template. My win7 template provides both landscape/portrait modes. But as you know, LL didnt support folder’s dual position(unlike its inner items dual position). So script should adjust folder’s position whenever switching orientation. And my some folders have child folders.
In LL, child folder’s position also handled by desktop coordination, not its parent folder’s coordination.
Of course I approached its child folder’s position by way of custom arrangement option and not so simple scripting for simple purpose. No problem.
But if LL’s margin works like HTML etc, I think in this case, solution can be more simple using left or right horizontal arrangement and folder’s margin especailly if parent folder are positin in left or right. So I asked it here.
My explanations may be unclear 🙁
]]>
< ![CDATA[
Not at all. Very clear explanation.
]]>
< ![CDATA[
So, new feature of dual position folder window (landscape/portrait) would fix the particular problem?
]]>
< ![CDATA[
Chris Chastain I have no idea how many LL users design their desktop working in both modes. But I always do, because I think its one of LL’s power. In desiging that, I think biggest barrier is that LL didnt support folders/panel’s dual position.
And I saw Pierre Hébert answered before, for that features implemented, too high risks of preexisted templates disordering…
In most of simple(? or not having sub-folders) desktop , dual modes design is not difficult as you know. But in other cases, we only have to use script for that. My first question about margin is about one of solutions for tackling folder dual position.
]]>
< ![CDATA[
I used to design desktop for both orientations (tablet) but with the support for dual positions incomplete, it’s very difficult so I don’t anymore.
If older templates get broken, maybe they should be updated?
I don’t know… I just don’t see much point in having dual position layouts only partially supported. It seems logical to make it global, but what do I know! 🙂
Maybe Pierre Hébert will expand on this, or give his thoughts on the subject?
]]>
< ![CDATA[
As for myself, I believe that supporting multiple orientations with a single desktop is too difficult.
As an analogy, designing Android apps often involves creating distinct portrait and landscape variations of the same screen.
More generally, to allow a proper orientation support I think there can be two solutions in LL:
– allow each property to have two values (but this is not an option: this would be a giant mess)
– use distinct desktops and allow reuse of components, items, folders or panels, with per desktop property (a better solution, but LL is not ready for that…)
]]>