search

SteveyO / Hue-Emulator

A Bridge API Emulator for the Philips Hue (Personal Wireless System)
165 stars 41 forks source link

Images of lights need to wrap. #17

Closed MrJoy closed 8 years ago

MrJoy commented 8 years ago

If one has many lights on a bridge, they simply bleed past the window boundary with no ability to scroll and no ability to use vertical space to fit them all on screen.

I'm emulating the configuration of one of my bridges which at present has 20 bulbs attached and that's proving to be a bit impractical due to this limit.

SteveyO commented 8 years ago

Yes true. I never really anticipated that people would want to use that many bulbs. On my monitor I can see about 20 with the large view, and 20 with normal emulator window, but no scrolling as you say. I will take a look at this for the next version. Steve

MrJoy commented 8 years ago

I grant you it's a bit of an obscure situation -- I'm doing a generative lighting setup for my wedding. I'm actually using four bridges -- one on each of the available channels -- with 7 bulbs per bridge for the main simulation / effect, 1 per bridge for the dance floor, 9 of the other bulb types (Go, Bloom, LightStrips) as accent lights spread across the bridges, aaaaand then 9 lux bulbs to light the food area -- but doing those on the bridge closest to that region.

It's a workflow that's quite stressful for the emulator, to say the least. Small differences in the behavior of the HTTP server caused me to have to add secondary paths for the network code, the difference in file format for the configuration snapshot -- and lack of feedback about what the parser finds unacceptable -- cost me some time figuring out what was different and working out translation code.

On the plus side, for at least some use-cases, I can test and iterate on things without preventing my fiancé from getting to sleep! (Studio apartment + 54 Hue bulbs + tendency to work late at night == not conducive to sleep!) So, thank you so much for your efforts here!

SteveyO commented 8 years ago

I had a quick look at this, and it doesn't look that easy to wrap the bulbs (in the Graphics Panel at the bottom). I could easily add some mouse scrolling facility but I guess that defeats the purpose as you wouldn't be able to see all bulbs on the screen.

Am thinking the easiest and best solution would be to create a new Frame (Similar to the Large Frame in the Views menu) but showing the smaller bulbs. Could easily fit 50 on here.

MrJoy commented 8 years ago

If making it scrollable is a viable short-term option, and making a Frame is not similarly quick, scrolling would be better than nothing.

Also, would you be interested in a whitespace-cleanup PR? It's a bit of a hassle for me to have to turn off my auto-cleaning whenever I go to make changes in order to avoid spurious diffs.

SteveyO commented 8 years ago

Ok, I just committed a new version. I have created another menu option with another Window that allows you to see smaller bulbs (in rows of 12). Here you can easily see 50+ on the same Frame/Window. I just tested it and it seems to work fine for me. Let me know if you see any issues.

What is the reasoning for a whitespeace-cleanup? Are you merging each changed source file separately? I would have thought it easier just to Pull the branch. (Or if doing each individually the 'Ignore Whitespace' option in eclipse works well for me). If I start cleaning up all my code indents I guess other people may suffer the same.

MrJoy commented 8 years ago

My editor is configured to automatically do certain whitespace cleanups on the whole file while I work -- handy for me so I avoid accidentally committing trailing whitespace and other such things. But turning it off per-project is something I haven't quite figured out. Plus I've hit a couple points where the indentation level wasn't consistent and that throws off the auto-indenting / tab-to-indent/shift-tab-to-unindent behavior.

And yeah, turning off whitespace diffs makes real changes easier to see but you can still get a higher rate of merge conflicts with spurious whitespace changes as it makes more lines part of the change / reduces the number of lines available as context.

I was thinking of just hitting the code with an automatic style-enforcer adjusted to your preferred conventions and going from there.

On Oct 6, 2015, at 9:16 AM, Steve notifications@github.com wrote:

Ok, I just committed a new version. I have created another menu option with another Window that allows you to see smaller bulbs (in rows of 12). Here you can easily see 50+ on the same Frame/Window. I just tested it and it seems to work fine for me. Let me know if you see any issues.

What is the reasoning for a whitespeace-cleanup? Are you merging each changed source file separately? I would have thought it easier just to Pull the branch. (Or if doing each individually the 'Ignore Whitespace' option in eclipse works well for me). If I start cleaning up all my code indents I guess other people may suffer the same.

— Reply to this email directly or view it on GitHub https://github.com/SteveyO/Hue-Emulator/issues/17#issuecomment-145916530.

SteveyO commented 8 years ago

I have just committed v0.6 of the emulator. This version has the little bulbs view. Can easily see up to 50+ bulbs, so am closing the issue. Sorry, I didn't look at the whitespace issue. Am reluctant to do anything here as quite a lot of developers have the code checked out. Any reformatting will be annoying for them.