|
Yes.. I was concerned about people losing email..
But I have yet to work on the website.. where I want the people to be able to login with Oauth (I'll use all .NET Oauth provider?!) to update / recover their details!
|
|
|
|
|
At minimum, your key needs to be tied to the machine.
User needs to contact you (company) with encrypted info from his/her computer and you generate a key based on that.
Email back the key to the user.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
Yeah.. I guess I was wondering whether it was too much of a bother for the user...
But since the application can be used while all of this is happening, I guess it's fine...
|
|
|
|
|
What does everyone think about the Halo Infinite gameplay we have seen so far? Asking since it COMES OUT WEDNESDAY!!!
|
|
|
|
|
I don't.
Too busy playing GTA V ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
A Homeless Guy, Looking Ragged And Dirty, Came To Apply. He Persuaded The Manager To Give Him A Try.
The guy was given a glass of wine. He swirled, smelled, sipped and spit. “It's a red wine, Merlot, three years old, grown on the South Slope and matured in oak barrels." He said. "Impressive," said the manager.
The man is given another. "Still a red wine, Cabernet, eight years old, from the Northeast slope, stored in a steel vats.”
The manager was amazed. He winked at his secretary. The secretary understood and brought out a glass of urine. The drunkard tasted it and said. "It's a blond, 27 years old, three months pregnant, and if I don't get this job, I'll tell who the father is!"
Real programmers use butterflies
|
|
|
|
|
First time ever I threw away coffee.
You're evil.
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
This one is cute...
__________________
Lord, grant me the serenity to accept that there are some things I just can’t keep up with, the determination to keep up with the things I must keep up with, and the wisdom to find a good RSS feed from someone who keeps up with what I’d like to, but just don’t have the damn bandwidth to handle right now.
© 2009, Rex Hammock
|
|
|
|
|
Okay, you don't need to get your coat!
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
I unboxed my fancy new ESP32-S3 yesterday. I intended to connect it to a parallel display and start banging on it until I realized that no toolchains are really ready for developing against it yet except for the ESP-IDF's which can limp along and do it if you're willing to devote your life to driving python scripts from the command line. So back in the box it goes.
I unboxed my ILI9341 display driver with an 8-bit parallel interface. Usually they come with a serial (SPI) interface.
I need to write a driver for it, and the ESP32 does not have hardware support for a parallel bus, meaning I have to bang the bits myself by controlling the individual pins.
And the trick is getting the timing right.
This is the part where I hate GCC (which I usually adore), because it doesn't respect "inline" very well. That means code like this:
#define HTCW_RS_C GPIO.out_w1tc = (1 << pin_rs)
#define HTCW_RS_D GPIO.out_w1ts = (1 << pin_rs)
#define HTCW_CS_L if(pin_cs>31) { GPIO.out1_w1tc.val = (1 << pin_cs-32); } else { GPIO.out_w1tc.val = (1 << pin_cs); }
#define HTCW_CS_H if(pin_cs>31) { GPIO.out1_w1ts.val = (1 << pin_cs-32); } else { GPIO.out_w1ts.val = (1 << pin_cs); }
#define HTCW_WR_L if(pin_wr>31) { GPIO.out1_w1tc.val = (1 << pin_wr-32); } else { GPIO.out_w1tc.val = (1 << pin_wr); }
#define HTCW_WR_H if(pin_wr>31) { GPIO.out1_w1ts.val = (1 << pin_wr-32); } else { GPIO.out_w1ts.val = (1 << pin_wr); }
#define HTCW_RD_L if(pin_wr>31) { GPIO.out1_w1tc.val = (1 << pin_rd-32); } else { GPIO.out_w1tc.val = (1 << pin_rd); }
#define HTCW_RD_H if(pin_wr>31) { GPIO.out1_w1ts.val = (1 << pin_rd-32); } else { GPIO.out_w1ts.val = (1 << pin_rd); }
#define HTCW_WRITE8(C) GPIO.out_w1tc = HTCW_CLR_MASK; GPIO.out_w1ts = HTCW_SET_MASK((uint8_t)(C)); HTCW_WR_H
#define HTCW_WRITE16(C) GPIO.out_w1tc = HTCW_CLR_MASK; GPIO.out_w1ts = HTCW_SET_MASK((uint8_t) ((C) >> 0)); HTCW_WR_H
#define HTCW_WRITE32(C) GPIO.out_w1tc = HTCW_CLR_MASK; GPIO.out_w1ts = HTCW_SET_MASK((uint8_t) ((C) >> 24)); HTCW_WR_H; \
GPIO.out_w1tc = HTCW_CLR_MASK; GPIO.out_w1ts = HTCW_SET_MASK((uint8_t) ((C) >> 16)); HTCW_WR_H; \
GPIO.out_w1tc = HTCW_CLR_MASK; GPIO.out_w1ts = HTCW_SET_MASK((uint8_t) ((C) >> 8)); HTCW_WR_H; \
GPIO.out_w1tc = HTCW_CLR_MASK; GPIO.out_w1ts = HTCW_SET_MASK((uint8_t) ((C) >> 0)); HTCW_WR_H
Forgive the formatting. There I'm using a combination of the preprocessor and constexpr charged if s to get them to resolve at compile time based on the pin assignments. It's a mess that should have been able to be done without the preprocessor at all.
That mess is to get it as fast as possible, so that when I do insert delays, they are minimal and controlled - I'm not blowing overhead on branch prediction misses from function calls and the like.
Anyway, at least the bit banging is fun, even if what I have to do to the C++ language isn't.
I love coding the metal. I love writing hardware interfaces. It dovetails with my love of circuit building, right there where the rubber meets the road. Turn this pin on in software, send that bit to the 8080 parallel interface connected to the display. Woo.
Something about it just feels pure.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: I love coding the metal. I love writing hardware interfaces. It dovetails with my love of circuit building, right there where the rubber meets the road. I had the pleasure of spending half of my career straddling the hardware/software design boundary.
I'd be designing some chunk of programmable hardware in one hand, and writing snippets to run on it in the other. In those days we built things out of SSI/MSI in DIPs, a hundred or two on a 15" square circuit board.
It was a great way to avoid shooting myself in the foot with the kind of hardware quirks you often describe here.
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Well, my process is going to have to adapt when I start doing some industrial automation-like controllers, which it looks like I might be diving into. Wago PLC specifically, which seems pretty simple.
Right now, I'm often dealing with stuff that's thrown together, or sourced from chinese manufacturers with documentation to match, or just dealing with cheapo chipsets that themselves are quirky.
That's kind of the hobbyist IoT realm, which is a pie I have some fingers in because of the IoT dev I do. I prototype at home using stuff I buy on amazon, and then I have someone I work with fritz it and make the boards with parts sourced from a reliable supplier like digikey. I'm not the only one who touches the circuits though. I'm one of three, and the least skilled at it. The other two people are electrical engineers. I'm software, but on the other hand, I know more hardware details about the particular MCUs we're using right now than anyone I work with. So we kind of lean on each other where we need to. It works.
Another reason I run into the quirks a lot is performance. I have to rip the wires from the walls sometimes to get the thing to perform like I need it to, and that comes with a lot of problems.
An article I wrote recently in fact is basically one big workaround:
Render Professional Screens on IoT[^]
Real programmers use butterflies
|
|
|
|
|
I am writing on some sort of vector drawing application, as a pet project, at home.
On the right side I have a property screen where I can set my current tool's property.
My.. issue, shall we say, is some of those simple property have ginormous base editor. Like color value editor is huge.
Here is a snippet: top rect is the property row, bottom rect is half of the color value picker.
So my property list usually rather short, some property editor however could be huge and that can destroy the simplicity of the UX (in the shot above only half of the color editor is seen, and some tools have multiple color properties!!)
Now I wonder what kind of UI mechanism I could use to improve that...
- having a second panel side by side for advance value editor? takes too much space!
- using popup/drop down? might be the right way... but... it's annoying how those popup always close at the most inopportune moment... beside if you click the magnify glass you have a "screen picker" where one could chose a color anyway on screen by clicking on it (which would close the popup)
- modal dialog, or even window a bit too far.. this break the workflow, I feel...
Anyway, share your thought please?!
[EDIT]
I think I might go with popup panel after.. I realized this afternoon they don't auto close like menu items do, it's up to me! I think that's a winner!
[EDIT2]
I went with popup, with a TODO to be able to "pin" them one day, i.e. turn them in sticky windows like Paint.NET
I like it.
Result / Screenshot
modified 6-Dec-21 5:54am.
|
|
|
|
|
I would somewhat mimic the interface Xara uses on their vector editing program. You can see a video at Xara Designer Pro Tutorial Movies. At about 2:20 in the Beginners 2 video, the color editor tool is demoed. That modal window can stay open without getting in the way of your chores, until you close it manually. It updates to the selected item as it changes, of course.
|
|
|
|
|
Thanks, watching the videos now!
|
|
|
|
|
I'm not a WPF lover expert, but maybe you can use the DockPanel control and let the user decide where to dock it.
If this is still too limited then maybe a tear-off panel would do the job, found something here:
GitHub - CommunityToolkit/Sample-TabView-TearOff[^] Sadly it has a limitation: Quote: Dragging a tab to another monitor/position doesn't open the window on the other monitor/position
|
|
|
|
|
I contemplated this...
I think I might go with popup panel after.. I realized this afternoon they don't auto close like menu items do, it's up to me! I think that's a winner!
|
|
|
|
|
And to confuse the user further: add lots of configuration options!
|
|
|
|
|
Having dealt with interfaces that were far too complex, I would ask yourself, what am I going to use on a regular basis? The list you come up with is your primary property page. Then there is the Advanced... button.
As for the color picker, I'm not sure my suggestion is doable.
I have long been an advocate to adding code all UIs to track over time what is being used and what is not. I'd love to see the metrics on something like Word or Excel... I'd wager 95% of what is in there is rarely if ever used.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
mm.. interesting. will see if i can do something like that...
the color picker is super easy to use in fact, mouse down on the icon, the cursor turn into a magnify glass, move the mouse (while the button is still pressed) on a pretty part of your desktop screen, release, done, color selected!!
|
|
|
|
|
Paint.NET has a hideable "on top" Color window that you can drag onto another monitor which is usually what I wind up doing so it's useful; at least for me.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
For some reason I read "Pain.NET" maybe its time for new glasses
|
|
|
|
|
yeah.. the idea crossed my mind..
I think.. I'll be starting with a popup.. that can be "pinned" into a dialog just like that one
|
|
|
|
|
Looks very interesting !
I'd favor a separate window/form for really complex tool ui's ... let the user move it where they want it, move it to another monitor, resize it to taste, etc.
Since certain subsets of "specialized" tools ... tools whose icons you may wish to not always be visible ... may be used frequently in a given workflow, consider:
1) configure/reorder menus
2) or, define custom tool palettes
3) or, use a "shelf" ui as found in NeXtStep [^]
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|