Notices
Page 15 of 25 « First 51314 15 1617 Last »
Reply
Thread Tools
Copernicus's Avatar
Copernicus is offline Copernicus
2013-06-11 , 14:30
Posts: 1,986 | Thanked: 7,698 times | Joined on Dec 2010 @ Dayton, Ohio
#141
Originally Posted by sixwheeledbeast View Post
If you really feel the need for a cut down version of Lanterne you could call it Torchio
I will keep that in mind! (I do still want to try creating a widget / status menu entry at some point, for some pasta, since all I've ever done as yet is apps...)

If you feel it's useful you could add an option to lock the screen too on lens close/application close
I'll give it a shot...

The only final comment I have is your preferences windows (all pasta shapes) seems to be a few pixels too big for portrait operation.
Yeah, I've been pushing options into the preferences panel too quickly, and without really thinking about the UI implications. For now, I've just been wanting to get functionality out there asap, but all the pastas could do with a bit of UI touchups. Thanks!

I like pasta, hopefully we will see many more varieties.
I am sure there are many more simple but much needed applications.
Hey, as I may have mentioned earlier, my own radar as to what is "much needed" seems to be missing a lot of things. Orecchiette is consuming my available time at the moment, but I'm always open to suggestions...
 

The Following 7 Users Say Thank You to Copernicus For This Useful Post:
Estel's Avatar
Estel is offline Estel
2013-06-11 , 20:55
Posts: 5,028 | Thanked: 8,613 times | Joined on Mar 2011
#142
Hehe, if you would like to put your hands into widgets, and at the same time do something simple, that is not going to get much feature requests (due to being feature complete at first release, probably), You could give FM transmitter control widget a shot (name is just a mockup). Generally, everything related to transmitting FM works out of the box (especially, using jacekowski's modified - and reverse-enginered, as vanilla was closed source - fmtx binary).

BUT, we have one unused (properly) feature - ability to transmit RDS alongside audio stream. Most of the times, it just transmit silly placeholder "Nokia N900" as RDS string. There is widget that should allow to dynamically modify RDS string, using TAGs from audio file (song name, artist, etc) - look for FM RDS Notify widget's source, if interested.

Just be aware that, as usual, this widget is bugged as hell, works only half the time, and is poorly written (consume CPU power even if not in use, eats huge ammount of RAM for no apparent reason, etc).

Not to mention, that some small application, that would enable/disable sending tags as RDS info globally (and, most likely, just like with Orecch's file naming scheme, would allow to define custom strings of tags and separators to use), without needing to run all the time, would be much better (due to "memory in use" savings - after all, N900 biggest bottleneck is RAM) - but it's the case most of the times. Who needs widgets, anyway, if we can have nice small program for same purpose? (with exception to weather prediction widgets, maybe).

Just suggesting

/Estel
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
Last edited by Estel; 2013-06-11 at 21:01.
 

The Following 5 Users Say Thank You to Estel For This Useful Post:
Estel's Avatar
Estel is offline Estel
2013-06-12 , 08:12
Posts: 5,028 | Thanked: 8,613 times | Joined on Mar 2011
#143
On-topic for Lanterne...

I've tested it thoroughly (latest version from OP), and noticed few things:

1. Sadly, "exit on camera cover close" options doesn't work. I've tried restarting Lanterne after enabling it, to no avail. It seems, that this option is just ignored.

2. In morse code tab, text imput field is missbehaving, if one hits "return" after writing sentence to send (I did it intuitively, wanting to check if it will be same as hitting "Start transmitting" button). It seems to open new line, but there is no way to write anything in it, or delete it and get back to our string - imput field just becomes practically disabled.

Still, my text from 1st line *is* there - if I start transmitting, it goes on (that's why I think it opens new line, then goes sepuku).

3. In strobe flash experimented, input field for duty cycle time is strange, too. Using hardware keyboard, I can write max 999 ms there (three digits), but via software buttons, I can set as much as 5000 ms.

Furthermore, there is something wrong with that duty settings. On 5000 ms and 25% duty cycle, leds remain ON for same ammount of time, as with 3000 ms. Increasing it above certain level seems to only affect pause time.

BTW, UI design observation here. "new" settings, utilizing duty cycle time and duty cycle percentage are in line with wikipedia's definition, but, in real life usage, "old" way of setting ON time and pause time was *much* more convenient and intuitive. I don't know for others, but I opt for reverting it.

4. UI design suggestion - please, split "torch ON/OFF" button into two, wide in half. Then, let first one remaine "torch ON/OFF", and make another "Indicator ON/OFF". Due to buttons size, even replacing one of them with two still keeps them finger-friendly, in both landscape and portrait.

OTOH, it allow us to enable either regular or nightvision-friendly torch modes from main menu, without side trips to prefferences. Speaking about the latter, it would also allow to get rid of "use indicator led as torch" checkbox from prefferences, leaving only mA settings there. I don't see any down-sides for such solution, only gains

Speaking about details - I thinked about it carefully, including situation, when one of torch modes is already enabled, and user click "ON/OFF" button assigned to another torch mode. IMO, this should result in disabling previous torch instantly, and activating last one "clicked" (literally, toggling between normal and indicator torch).
---

Thanks for already making it almost feature-complete and UI-ideal!
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
Last edited by Estel; 2013-06-12 at 08:25.
 

The Following 7 Users Say Thank You to Estel For This Useful Post:
pichlo's Avatar
pichlo is offline pichlo
2013-06-12 , 09:27
Posts: 6,453 | Thanked: 20,983 times | Joined on Sep 2012 @ UK
#144
Originally Posted by Estel View Post
Speaking about details - I thinked about it carefully, including situation, when one of torch modes is already enabled, and user click "ON/OFF" button assigned to another torch mode. IMO, this should result in disabling previous torch instantly, and activating last one "clicked" (literally, toggling between normal and indicator torch).
Alternatively, replace the now superfluous "use indicator led as torch" checkbox with "allow using both LEDs simultaneously". I am thinking hard to come up with a situation when one would want to have both the white and the red LED on at the same time though.
 

The Following User Says Thank You to pichlo For This Useful Post:
Copernicus's Avatar
Copernicus is offline Copernicus
2013-06-12 , 12:10
Posts: 1,986 | Thanked: 7,698 times | Joined on Dec 2010 @ Dayton, Ohio
#145
Originally Posted by Estel View Post
1. Sadly, "exit on camera cover close" options doesn't work. I've tried restarting Lanterne after enabling it, to no avail. It seems, that this option is just ignored.
Question: do you have the "Ignore camera cover status" option checked? If so, Lanterne will ignore the camera cover. This includes not closing the app when the camera cover is closed...

2. In morse code tab, text imput field is missbehaving, if one hits "return" after writing sentence to send (I did it intuitively, wanting to check if it will be same as hitting "Start transmitting" button).
Ah, this is a UI problem. In order to load large files, I switched from using a "line entry" widget to a "text entry" widget in the GUI. Unfortunately, when in landscape mode, you can only see one line of text at a time. If you switch to portrait orientation, you'll be able to see more lines of text.

I'll try to figure out a better way to manage the text screen...

3. In strobe flash experimented, input field for duty cycle time is strange, too. Using hardware keyboard, I can write max 999 ms there (three digits), but via software buttons, I can set as much as 5000 ms.
I set the maximum at 5000 ms without really thinking about it. You can, in fact, type in a number up to 5000 if you want; try typing in "4999" for example. Apparently, if you try typing "9999", it sees that the number is greater than 5000, and stops you.

But yeah, I really need to think a bit harder about the strobe UI...

Furthermore, there is something wrong with that duty settings. On 5000 ms and 25% duty cycle, leds remain ON for same ammount of time, as with 3000 ms. Increasing it above certain level seems to only affect pause time.
Yeah, another failure of mine here. The actual V4L2 max time allowed to keep the flash LEDs lit at high power is (if I recall correctly) 500 ms. Thus, once you set the period above 2000 ms, the duty cycle starts going below 25%.

I need to find a better way of showing this limitation in the UI...

UI design observation here. "new" settings, utilizing duty cycle time and duty cycle percentage are in line with wikipedia's definition, but, in real life usage, "old" way of setting ON time and pause time was *much* more convenient and intuitive.
Yes, and it was much more flexible as well. Dangerously flexible. The advantage of the "duty cycle" mechanism is that it shows you exactly where the danger is -- the higher the duty cycle, the greater the chance of damage to the LEDs. I'll look at providing other UI options, but I at least want to keep the duty cycle value somewhere, to let you know if you're in dangerous territory.

UI design suggestion - please, split "torch ON/OFF" button into two, wide in half.
Ah, yeah, I've been trying to work out how best to do something like that. The big issue here is how to make it work in both landscape and portrait mode. The way I've got it now, Qt automagically resizes all the buttons for me; but splitting the buttons horizontally works better in landscape, and splitting them vertically works better in portrait. I'm still trying to find a way to customize landscape and portrait modes without being too cumbersome.

Then, let first one remaine "torch ON/OFF", and make another "Indicator ON/OFF".
Actually, I'd prefer to have a generic White/Red switch somewhere, so that all the choices (Torch/Pulse/SOS/Morse) pick up the color switch once, rather than forcing each button to be split... But yeah, having to go to the preferences screen to switch is a pain. Let me work on it.

Speaking about details - I thinked about it carefully, including situation, when one of torch modes is already enabled, and user click "ON/OFF" button assigned to another torch mode. IMO, this should result in disabling previous torch instantly, and activating last one "clicked" (literally, toggling between normal and indicator torch).
Yeah, that does make sense; I really only implemented it the way I've got it now because it was easier to code quickly. I'll take a look...
 

The Following 7 Users Say Thank You to Copernicus For This Useful Post:
pichlo's Avatar
pichlo is offline pichlo
2013-06-12 , 12:57
Posts: 6,453 | Thanked: 20,983 times | Joined on Sep 2012 @ UK
#146
Originally Posted by Copernicus View Post
Originally Posted by Estel View Post
BTW, UI design observation here. "new" settings, utilizing duty cycle time and duty cycle percentage are in line with wikipedia's definition, but, in real life usage, "old" way of setting ON time and pause time was *much* more convenient and intuitive. I don't know for others, but I opt for reverting it.
Yes, and it was much more flexible as well. Dangerously flexible. The advantage of the "duty cycle" mechanism is that it shows you exactly where the danger is -- the higher the duty cycle, the greater the chance of damage to the LEDs. I'll look at providing other UI options, but I at least want to keep the duty cycle value somewhere, to let you know if you're in dangerous territory.
How about keeping the duty cycle but providing a dynamic info line showing what it translates to in absolute terms.
 

The Following 3 Users Say Thank You to pichlo For This Useful Post:
Estel's Avatar
Estel is offline Estel
2013-06-12 , 15:24
Posts: 5,028 | Thanked: 8,613 times | Joined on Mar 2011
#147
Originally Posted by pichlo View Post
Alternatively, replace the now superfluous "use indicator led as torch" checkbox with "allow using both LEDs simultaneously". I am thinking hard to come up with a situation when one would want to have both the white and the red LED on at the same time though.
I wonder, if it is even possible from hardware? I thought chip can drive *either* both white leds, or red one... But, in any case, difference between light levels are so extreme, that there would be 0 chance to even notice, that red led is ON, if white leds would be enabled (even at lowest, "torch" settings).

Originally Posted by Copernicus View Post
Question: do you have the "Ignore camera cover status" option checked? If so, Lanterne will ignore the camera cover. This includes not closing the app when the camera cover is closed...
Ough, my fault - of course I have it set. I wonder, couldn't Lanterne ignore camera cover state for purpose of turning LEDs off, but respect it for closing whole application at change from open to close (this and only this) state?

I know, it's funniest feature request I ever made, and I can certainly live without it, if it's too cumbersome to write (or basically, require wasting more than few minutes, to write such nonsense :P ).

Originally Posted by Copernicus View Post
Yes, and it was much more flexible as well. Dangerously flexible. The advantage of the "duty cycle" mechanism is that it shows you exactly where the danger is -- the higher the duty cycle, the greater the chance of damage to the LEDs. I'll look at providing other UI options, but I at least want to keep the duty cycle value somewhere, to let you know if you're in dangerous territory.
Originally Posted by pichlo View Post
How about keeping the duty cycle but providing a dynamic info line showing what it translates to in absolute terms.
Why not keeping more flexible ms - ms settings, and showing dynamically adjusted field with resulting duty cycle% (as non-imputable field, just a "calculated result", based on what we put into ms values)?

Originally Posted by Copernicus View Post
Ah, yeah, I've been trying to work out how best to do something like that. The big issue here is how to make it work in both landscape and portrait mode. The way I've got it now, Qt automagically resizes all the buttons for me; but splitting the buttons horizontally works better in landscape, and splitting them vertically works better in portrait. I'm still trying to find a way to customize landscape and portrait modes without being too cumbersome.

(...)

Actually, I'd prefer to have a generic White/Red switch somewhere, so that all the choices (Torch/Pulse/SOS/Morse) pick up the color switch once, rather than forcing each button to be split...
Hey, your idea with generic white/red switch is very good, it should be there instead of my proposed "indicator ON/OFF" button. As for landscape/portrait dillema, I would just split last button horizontally (ala landscape) - as said, even in portrait, they're going to be big enough for being comfortable. Other way around, it looks much worse.

/Estel
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
 

The Following User Says Thank You to Estel For This Useful Post:
Copernicus's Avatar
Copernicus is offline Copernicus
2013-06-12 , 15:40
Posts: 1,986 | Thanked: 7,698 times | Joined on Dec 2010 @ Dayton, Ohio
#148
Originally Posted by Estel View Post
I wonder, couldn't Lanterne ignore camera cover state for purpose of turning LEDs off, but respect it for closing whole application at change from open to close (this and only this) state?
Ah, well, that's kind of a conundrum; if you want to control the LEDs while the cover is closed, then really, the app should remain running while the cover is closed, right? I'm really not sure exactly how to both ignore the cover state and use the cover state at the same time. I could, for example, use the rule "If I'm ignoring the cover, but at some point the state goes from open to closed, I'll quit the app", it might work for your use case, but wouldn't it be kind of confusing behavior?

Why not keeping more flexible ms - ms settings, and showing dynamically adjusted field with resulting duty cycle% (as non-imputable field, just a "calculated result", based on what we put into ms values)?
Yeah, that does sound like the sweet spot. Let me see how much work it would take to put something like that together... Thanks!
 

The Following 3 Users Say Thank You to Copernicus For This Useful Post:
pichlo's Avatar
pichlo is offline pichlo
2013-06-12 , 15:50
Posts: 6,453 | Thanked: 20,983 times | Joined on Sep 2012 @ UK
#149
Originally Posted by Estel View Post
Why not keeping more flexible ms - ms settings, and showing dynamically adjusted field with resulting duty cycle% (as non-imputable field, just a "calculated result", based on what we put into ms values)?
I was envisaging a single slider like the volume control in status menu with % value next to it (or even across it) and Xms on - Yms off under it as calculated values.

Not only would it look cool but it would also allow for dynamic limiting of the duty cycle and/or longest on timer depending on the brightness (which I incidentally also envision as a slider).

But I will let Copernicus decide that
 

The Following 3 Users Say Thank You to pichlo For This Useful Post:
sixwheeledbeast is offline sixwheeledbeast
2013-06-12 , 16:36
Posts: 2,292 | Thanked: 4,135 times | Joined on Apr 2010 @ UK
#150
Originally Posted by Estel View Post
Hey, your idea with generic white/red switch is very good, it should be there instead of my proposed "indicator ON/OFF" button. As for landscape/portrait dillema, I would just split last button horizontally (ala landscape) - as said, even in portrait, they're going to be big enough for being comfortable.
It's not that simple. I am no Qt guru so bear with me.
It's the way that Qt auto-resizes the buttons. Hard to explain unless you have played with Qt.

Currently Lanterne is stacked horizontally and the buttons are set to resize this is the simplest method of catering for rotation.

Another (more in depth way) of doing it is setting fixed positions for everything in both orientations. This requires code and general messing about IME.

Personally I'd go for the easy option add a thin QPushButton "Night (Red) Mode" above the current four QpB's that stays highlighted when toggled on.
__________________

Wiki Admin
sixwheeledbeast's wiki
Testing Squad Subscriber
- mcallerx - tenminutecore - FlopSwap - Qnotted - zzztop - Bander - Fight2048 -


Before posting or starting a thread please try this.
 

The Following 5 Users Say Thank You to sixwheeledbeast For This Useful Post:
Reply
Page 15 of 25 « First 51314 15 1617 Last »

Tags
flashlight, lanterne, morse code, nokia n900, strobe light, torch

« Previous Thread | Next Thread »

 
Forum Jump


All times are GMT. The time now is 07:28.

Contact Us - Home - Archive - Top