[Interest] Set QTableWidgetItem checkbox when clicking, anywhere on QTableWidget's row

[Roland Hughes]

Sean,

 >>> P.S. Oh, and get rid of the QTableWidget. Use QTableView instead.
 >> What does that do for me in this case?
 > Nothing to solve this particular issue. Its just a pet-peeve of mine.
 >> My table is very simple, it's basically a read-only table EXCEPT for 
allowing
 > the user to check/uncheck items. Maybe I'm wrong in my ideas, but I 
tend to
 > view QTableWidget as working pretty nicely for very simple tables 
like this
 > but with it you get less control than QTableView. I feel like when 
I've used

I had to cut and paste this myself so please forgive if I got 
attribution wrong.

I just wanted to weigh in on the QTableWidget issuing knowing full well 
it is pretty close to the "What's the best editor" flame war bait. It 
has been my experience that there are 2 primary camps when it comes to 
spreadsheets in Qt.

1) Those who think having to write 5000+ lines of code to do a simple 
thing is great!
2) Production coders (most often salaried employees) who have 12 other 
projects scheduled to complete before they will be allowed to take vacation.

Admittedly Camp-1 tends to be a younger crowd reading all of the high 
minded books and papers trying to become one with the original OOP 
Object from whence all other objects came. In a less politically correct 
time people used to day they spend much of their day sitting cross 
legged on the floor in a white smock, palms skyward, eyes closed, 
chanting oooooohhhhhhhhmmmmmmm in an effort to achieve this 
enlightenment. Those who don't get such a reference will have to watch a 
lot of 1970s and early 1980s movies with characters like that, not that 
getting the reference is important.

Camp-2 has a release schedule which was chosen before the spec was 
written. Even if, no, especially if you are an hourly contractor you 
need to bang it out fast. You have one month to do a system which would 
ordinarily take six months before it got to internal alpha testing. 
Management is going to award higher billing rate contracts to those who 
pulled off a miracle last time. When your primary life goal is to be 
able to retire before the mass quantities of caffeine and nicotine cause 
you to expire increasing the billing rate is about the only way to do it.

Management, especially if they hold an MBA tends to know nothing about 
software development. They just have these charts and graphs showing 
progress or the lack thereof and make decisions based on them. All they 
really know is the Windows/Java/etc. developers have these controls they 
can just drop in and configure 800 ways to Sunday so a full blown 
spreadsheet with most of the features of an OpenOffice spreadsheet gets 
added as a requirement at the 10AM meeting and those developers have it 
in the code base before lunch.

Putting it in non-IT terms, since I'm currently getting a starter 
rebuilt for my WWII era forklift

Camp-2 tends to believe they don't need to know how to build a starter 
to install one in the vehicle they are working on. They only need to 
know where to get it and how to install it. Camp-1 believes you should 
assemble the starter by hand from parts which have to be milled to fit 
together to make a perfect starter. The extreme members of Camp-1 
believe you should harvest the ores and coal yourself, smelting the 
metals to hand craft the perfect starter to fit in the opening and align 
with the bolt holes on the engine.

Now that I'm on the shadier side of the hill I'm more deeply in Camp-2 
than I ever was. I worry less about project deadlines than completing 
all of the projects I want to build before the dead deadline.

If my statements about drop in controls seem dated that would be due to 
the fact the last time I touched the virus known as Windows VBX controls 
were all the rage. My personal belief when I got into Qt having moved 
from Zinc Application Framework and several others before it was that we 
(the community) would have an ever increasing number of highly 
configurable widgets to drop into our applications. That belief has not 
proven to be the case, but, it was my belief nonetheless.

During my youth Assembler, COBOL and BASIC ruled the business computing 
land and FORTRAN ruled the scientific world. Camp-2 dwellers worked with 
this high level languages while Camp-1 dwellers worked in Assembler 
trying to squeeze every cycle out of a processor by getting as close to 
one with the metal as possible. There are still some bare metal 
programmers out there and God love them. Without them we would not have 
BIOS or UEFI or any other kind of built in firmware, but the big things 
don't get written like that.

Qt has been occupying a weird place. Originally trying to create 
something for desktop applications which could be cross compiled to many 
platforms, it has slowly been pulled more into a Camp-1 type of orbit. 
It tried to bow to the fact most kids in school are script kiddies these 
days, rarely taught much in the way of 3GLs and structured design when 
it created QML. For battery operated things QML is a horrible choice 
because scripted languages have a higher run-time burden on the 
processor. I don't see that changing until we finally get to the place a 
fully charged smart phone drains its battery 10 minutes after your 
application starts. We seem to be getting closer to that day with each 
passing hour.

Oh well, just my 0.0002 cents.