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.
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
