Lutz Linke
now browsing by tag
Working a lot with PowerPoint I thought Color Schemes would be a great addition to LL.
(In follow-up to Josh Gray ‘s suggestion regarding color picker >> https://plus.google.com/113418323387583377848/posts/28pYQWzeQu3 )
I mean: in addition to the usual color picker, it would be possible to choose an indexed color from a color palette (of like 16 or 32 colors). Let’s say one could define color at index 0 for background, at index 1 for main text, index 2 for accent, index 3 for header background etc.
Defined at desktop’s level (no necessity for container level, just like PowerPoint or Word), it would be easy to change a whole setup’s look by simply switching the palette/scheme — as said, just like in PowerPoint. Darkness becomes Light, Lead becomes Gold etc.
Changing palettes should be possible by script also. Think of palettes for Dawn, Day, Dusk, Night — combined with a simple scheduling script = awesomenesss^3.
Palettes could be saved with a template, like Styles. Import/export in JSON-format would be great, too, but not a must.
Pierre Hébert , I know you’re little on time, but let’s hear your opinion. There’s still the open “inheritance” topic and I think Color Schemes would to a great extent be a proper exchange.
]]>Posted public instead of here, damn.
Originally shared by Lutz Linke
Pierre Hébert , I re-uploaded the Excel file to Box with the calculations for Zooper Widget scaling patch:
https://app.box.com/s/hdj5buwi3quqt89rwql9
Here’s the calculations:
Factors (based on LL’s values):
factorW = screenWidth(target) / screenWidth(orig)
factorH = screenHeight(target) / screenHeight(orig)
factorDpi = screenDensity(target) / screenDensity(orig)
Scaling Patch:
preset_widgetwidth(target) = preset_widgetwidth(orig) x factorW
preset_widgetheight(target) = preset_widgetheight(orig) x factorH
pref_widget_scale(target) = (width > height)
? pref_widget_scale(orig) x factorH/factorDpi
: pref_widget_scale(orig) x factorW/factorDpi
preset_dpiheight(target) = preset_dpiheight(orig) x factorH/factorDpi
preset_dpiwidth(target) = preset_dpiwidth(orig) x factorW/factorDpi
The factor for pref_widget_scale seems to depend on the ratio of the widgets, wether it’s narrow of wide.
]]>ZW patched templates for better rescaling, next try…
(Follow up to https://plus.google.com/u/0/106201536507820539535/posts/65Aueho1qek)
I just uploaded two new version of test templates with corrected scaling factors. Tried on tablet with various simulated resolutions and DPIs, looks like I’m on the right path now.
They’re here: https://app.box.com/s/hdj5buwi3quqt89rwql9
Difference between V2 and V3 is calculation of available vertical space (V2: approximate; V3: based on 48dp/56dp high action bar, propably closer to reality).
Requires Zooper Widgets Pro, naturally.
Would be great if you guys could test these:
– download test template for your device (just ~90kB)
– apply in LL
– take screenshot and send it to me for comparison
– optional download i.e. the original template for Nexus 4 720×1280 for comparison
Save to merge w/o wallpaper when applying, adds additional desktop that can be deleted afterwards. No scripts, styles and other stuff in template.
Templates uploaded:
1080×1920 388dpi Samsung Galaxy Note 3
1080×1920 424dpi Sony Xperia Z2
1080×1920 431dpi Samsung Galaxy S5
1080×1920 441dpi Samsung Galaxy S4, Sony Xperia Z1
1080×1920 445dpi Google Nexus 5
1200×1920 324dpi Google Nexus 7 (2013)
1440×2560 538dpi LG G3
480×800 218dpi Samsung Galaxy S2
720×1280 306dpi Samsung Galaxy S3
720×1280 Google Nexus 4 (resized)
768×1280 Google Nexus 4
800×1280 213dpi AsusPad MemoPad 7 HD
Thanks in advance!!
]]>Would it be possible to add an event “OnExport”?
Should only be raised as name suggests when exporting a template. Would allow to do some cleaning up (attaching items, clearing flags, etc) semi-automatically. Fail must however not prohibit export.
]]>If you have some spare 5 min, could you please test?
Download (just 90kB) to sd/Lightning Launcher, apply (with merge! to not harm your current setup), take a screenshot, remove desktop added.
Please send screenshot and comment.
Thanks a lot in advance.
Originally shared by Lutz Linke
Please test: demo templates for my ZW-scaling suggestion (https://plus.google.com/+LutzLinke/posts/4UVqKs9Etut).
Pierre Hébert and all others:
I created a demo page with some Zooper Widgets on 720×1280, 320dpi and exported as template (just 96kB). This template loaded on different screen will result in incorrectly scaled ZWs (see attached screens).
So I created a few patched templates that should scale correctly directly after applying for the following devices or resolutions:
720×1280 Nexus4
768×1280 Nexus4
800×1280 213dpi, i.e. AsusPad MemoPad 7 HD
800×1280 149dpi, i.e. Toshiba AT700 10″ Tablet
1080×1920 388dpi, i.e. Samsung Galaxy Note 3
1080×1920 424dpi, i.e. Sony Xperia Z2
1080×1920 431dpi, i.e. Samsung Galaxy S5
1080×1920 441dpi, i.e. Samsung Galaxy S4, Sony XperiaZ1
1080×1920 445dpi, i.e. Nexus5
1200×1920 324dpi, i.e. Nexus7(2013)
1440×2560 538dpi, i.e. LG G3
You can download them here:
https://app.box.com/s/hdj5buwi3quqt89rwql9
You can merge to test and delete that desktop afterwards.
Formulas used are a bit different (see LLTemplateScale_V2.xlsx):
preset_widgetwidth >> x Ratio Width
preset_widgetheight >> x Ratio Height
pref_widget_scale >> x 1/Ratio DPI
preset_dpiheight >> x Ratio Height/Ratio DPI
preset_dpiwidth >> x Ratio Width/Ratio DPI
If you own a device listed above (or a similar device with matching resolution and dpi), could you please test, do a screenshot and send it to me and Pierre?
Thanks for your help!!


Please test: demo templates for my ZW-scaling suggestion (https://plus.google.com/+LutzLinke/posts/4UVqKs9Etut).
Pierre Hébert and all others:
I created a demo page with some Zooper Widgets on 720×1280, 320dpi and exported as template (just 96kB). This template loaded on different screen will result in incorrectly scaled ZWs (see attached screens).
So I created a few patched templates that should scale correctly directly after applying for the following devices or resolutions:
720×1280 Nexus4
768×1280 Nexus4
800×1280 213dpi, i.e. AsusPad MemoPad 7 HD
800×1280 149dpi, i.e. Toshiba AT700 10″ Tablet
1080×1920 388dpi, i.e. Samsung Galaxy Note 3
1080×1920 424dpi, i.e. Sony Xperia Z2
1080×1920 431dpi, i.e. Samsung Galaxy S5
1080×1920 441dpi, i.e. Samsung Galaxy S4, Sony XperiaZ1
1080×1920 445dpi, i.e. Nexus5
1200×1920 324dpi, i.e. Nexus7(2013)
1440×2560 538dpi, i.e. LG G3
You can download them here:
https://app.box.com/s/hdj5buwi3quqt89rwql9
You can merge to test and delete that desktop afterwards.
Formulas used are a bit different (see LLTemplateScale_V2.xlsx):
preset_widgetwidth >> x Ratio Width
preset_widgetheight >> x Ratio Height
pref_widget_scale >> x 1/Ratio DPI
preset_dpiheight >> x Ratio Height/Ratio DPI
preset_dpiwidth >> x Ratio Width/Ratio DPI
If you own a device listed above (or a similar device with matching resolution and dpi), could you please test, do a screenshot and send it to me and Pierre?
Thanks for your help!!


Better scaling (ZW) widgets when applying templates with widgets.
Since after restoring an LL template with Zooper Widgets those in many cases need adjustments, I did some investigations how to improve this issue. If this could be applied, Pierre Hébert , LL would be REALLY the BEST (well, it already is… but anyway) template-able launcher.
I exported a template on my Nexus 4 (768×1280), imported on my tablet (800×1280), fixed some widgets, re-exported and compared.
Findings:
File “*manifest*”:
screenDensity 320 >> 213 >> Ratio 0,6656
screenWidth: 768 >> 800 >> Ratio 1,0417 >> Ratio*dpi 1,5649
screenHeight 1184 >> 1216 >> Ratio 1,0270 >> Ratio*dpi 1,5430
If those ratios would be applied to the values (verified, worked great!!) in Zooper Widgets’ preset.json (inside widgets_data settings file) as followed, the ZW widgets would look quite perfect immediatelly after the applying the template.
preset_widgetwidth >> x screenWidth ratio
preset_widgetheight >> x screenHeight ratio
pref_widget_scale >> x Max(Ratio W*dpi,Ratio DpiH*dpi)
preset_dpiwidth >> x Max(Ratio W*dpi,Ratio DpiH*dpi)
preset_dpiheight >> x Max(Ratio W*dpi,Ratio DpiH*dpi)
I’m not pretty sure about that “Max(…)” since the only difference between my devices’ screens is dpi and width (768×1280 and 800×1280), but according to calculations and tests it works.
Here’s a sheet with my calculations for those interested:
https://app.box.com/s/ed5lpo9walfry4cb088x
“addShortcut” does not work properly within folders, they are placed wrong, always at Y-position 0.
I have a folder, grid 8×12. Placed 2 shortcuts in row 1 and column 1 so the folder has a size of 8×5 when opened. Area 1/1 to 7/4 (0-based positions) is reserved for the area I want to add shortcuts dynamically.
addShortcut(“Label”, new Intent(), x*colW, y*RowH) places the shortcut at x*colW/0 (colW and rowH are calculated from container size and grid, those values are okay).
Tried dettaching and moving after adding, still the same. “Dettach by default” makes it worse, shortcut’s size is smaller than grid cell size.
It works when folder is in Edit-mode (full screen 8×12 grid shown), but not when folder is in Normal-mode.
Is this a bug, or am I just doing it wrong? Then what is the correct way?
]]>If you add a shortcut by script (to a folder in my case), you can change its properties, but these are not persisted.
var sc=fld.addShortcut(“lbl1”, null, 0, 0);
sc.setLabel(“lbl2”);
var ed=sc.getProperties().edit();
ed.{whatever}
ed.commit();
LL.save();
EDIT: I have to correct myself. Property changes ARE persisted… all except changes to “i.box”. And this happens not only for newly added shortcuts, but also for existing.
]]>
D5 Creation