Post by Pete Batardbuilt into Device Manager
Well, that's the problem. I was expecting a simple drag and drop control
that would use whatever is the browsing default for whatever Windows
version users are running, but there's no such thing in the MS supplied
development environments right now. And my current understanding is that
there is such a hook in the shell DLL, only it's not exposed.
That stinks. Though a separate dialog is as good or better than a control,
it sounds like that's not accessible, then.
Post by Pete BatardThe setdrv commandline tool is pretty much already done, but is a bit
limited,
Ah, well, I don't remember hearing about that one on the list, either.
Post by Pete BatardPost by Pete Batard(MinGW/cygwin support)
I think you only need to support one freeware environment for the GUI.
When there's no reason to limit ourselves to a specific environment, why
do so? I'm not really keen on adding artificial limits unless there's
valid ground for it, and I don't consider a simple browse issue as
reasonable enough to introduce a limitation.
I wasn't mentioning it solely for the browse issue. I said it because I
know it's a pain to test in each environment. If you prefer to pick a
different environment, great, but my point was just to pick one, not so much
which one to pick.
Post by Pete BatardIt is possible to write perfectly good Windows GUI applications without
using Microsoft tools (I was actually surprised at how easy MinGW/cygwin
were able to compile the GUI app),
Oh sure. But that's just compiling it. Which is why I suggested it might
be a good idea to focus on VS support for development, and something else
(perhaps DDK) for a freeware build environment.
Post by Pete Batardno telling how Microsoft is going to cripple the DDK in the future
Good point.
Post by Pete BatardA bit like how you felt
that later versions of MSVC6 didn't really cover your needs... Wouldn't
it have been nice, if you had had the option to migrate your MSVC6
projects away from VS, onto open source software then?
To elaborate, two people brought the issue up once each on a gcc mailing
list about a decade ago, with just about no response whatsoever. (It is a
feature that needs to go in both the compiler AND the environment to
actually work, and the compiler work would logically come chronologically
first.) This is perhaps related to the apparent attitude in F/OSS that IDEs
are for the weak. However, if I want to be able to maintain as large a
piece of software as possible while still keeping relevant details close at
hand or in my head, this particular feature likely improves that ability by
at least an order of magnitude. So even then, most IDEs lack the same
appeal. So yes, it would have been nice, but it just wasn't there, and I
don't see it showing up in the near future anywhere else.
So I see your point. If you want to support multiple compilers, great, but
let me soften it to say that the most compelling reasons are absent,
compared to the libraries, rather than simplistically saying there's no
reason.
Post by Pete BatardDoesn't look like it. But they strongly seem to invite developers not to
use the old controls on these platforms, and I usually try to follow
MSDN's advice where applicable.
Common dialog, not control (two different things). And an insanely-high
percentage of all Windows software would break if they did that (with either
the common dialogs or certain common controls).
Post by Pete BatardFrankly, I think writing a GUI in plain C was less than desirable,
Lowest common denominator.
It's been a long time since I've seen a C-only compiler. Or are you trying
to say that you wish to cater to developers who only know one or the other?
If so, you have to make a largely-arbitrary choice. Anyway, you've made the
choice and I see no problem sticking with it.
Post by Pete BatardThe GUI app is very basic [...details...]
why not stick with good old C.
Agreed, then C shouldn't be hard to do it in, and still keep it
maintainable. I didn't really know the scope of the program, but the
screenshots help some. If you don't expect to add much more to that dialog,
then I'd just keep doing what you're doing, rather than discard existing
work.
Post by Pete BatardThere's probably the odd GUI developer out there that wants
to use libwdi and C,
I think this is confusing libwdi with the GUI, unless I misunderstand the
terminology. There is no issue using a C library (libwdi) in a C++ app
(GUI). Where am I going wrong?
Post by Pete BatardPost by Pete Batardthe dialog looks 7ish enough when used on 7
Oh, God forbid it might actually have square corners instead of glossy
round
Post by Pete Batardones. The device might not work (for 5 year olds), or someone might
get cut
Post by Pete Batardon it and sue. :-)
Aha, but a 5 year olds might precisely be the ones installing USB
drivers with the GUI app.
And know what a VID and PID and MI are? Here goes... (I hope the following
doesn't sound too harsh)
Post by Pete BatardAnd to answer one of your further question
already, yes I do expect the GUI app to be distributed as is,
I find that quite surprising, as the screenshots don't resemble anything
I've seen in a commercial installer. The very fact that it *requires* the
user to do something other than click "install" means that few end-users
will figure it out. The few that can will certainly appreciate having it,
mind you, much like they appreciate the *option* of doing a custom install,
but *option* is key.
Post by Pete Batard(it's a very simple app, so why not?)
Simple for you to write, or simple for some random person to know why they
even need, much less how to use? It will probably do what it does quite
well, but I am again surprised you expect anyone to distribute this app
as-is.
Post by Pete Batardincluding very clueless ones, or people focusing on the
shiny aspect.
Who panic and click any random button to try to make a box go away, without
reading it (Raymond Chen rants about this pretty frequently in his book,
based on his experience with customer testing at MS). The average user base
of Windows (or Mac) are not what you make them out to be.
Post by Pete BatardWhere on earth are the
3D controls promised by VS 2008 in its UI designer tool?
Dunno, that's odd. How did you get the "promise" one? Is that what the
resource editor shows you, or did you photoshop it? If the former, you
might need to add some sort of code to enable stuff (generate a throwaway
appwizard program to see if you missed any initialization).
Post by Pete BatardWhen an app with default controls from the latest Visual Studio runs on
the latest version of Windows, I do expect it to look native, and that's
the look an feel that I am after, nothing more.
Agreed, but that always seemed to be the default, which is why I was puzzled
about your comment about "looking Win7 enough" in the previous email.
Post by Pete BatardA user can pretty much just launch the app, plug in their USB
device, then click the big "Install" button and tada!, they can use
their previously driverless device with a libusb (or native WinUSB) app.
And do what? Use a GUI version of xusb after that? I mean, is this for
some generic device, or for...? I guess what I'm getting at is I would have
expected that, for an end-user, this would happen in the context of some
other program, and that that program would either launch your installer with
some sort of defaults, if not outright no choice, or else that the other
program would simply link to the libwdi library with no special UI at all.
Post by Pete BatardAnd, since that single GUI exe works on all versions of Windows, from XP
to 7, including 64 bit, I very much see it being used as is.
I can write a hello world that probably works on all those platforms, but
I'm not sure an end-user is going to know any more what to do with that
(probably will click "X" in both cases). Sorry, but I really do think the
quoted text is a flimsy enough reason to deserve that.
Post by Pete BatardI'm actually planning to release up to date versions of the binary GUI
app myself as a matter of fact, be it only to help with people who want
to try libusb and don't want to be bothered with the Windows driver
installation part (should help with the mailing list too).
And I think it's useful for that! But those are either developers, or
people who think somewhat like one.
Post by Pete BatardI don't like these kind of compromises. It's not because you deal with
hardware that you should mistreat UIs (or end users for that matter),
It's not a matter of mistreatment so much as putting form ahead of function.
But I don't see the point of debating it now that I can't even figure out
how this will be used. And I hope "you deal with hardware" is an abstract
"you", rather than extrapolation from the example program I mentioned.
Post by Pete Batardcan't even get a simple UI right?
Right, or pretty? I'd consider not getting it right having it crash, or do
any number of *functional* things wrong (like incorrectly validating input,
or locking you to a box you don't want to be in until you *make* it valid).
Those are (or can be) UI blunders, but they have nothing to do with the
look. If it's not pretty (but is intuitive), I'd trust them all the same.
If it breaks, I would not trust them much, but that doesn't seem to be
what's at issue here. If it's ugly because they tried to make it look
exactly the way they wanted, I treat that very differently than if it's ugly
because they didn't consider spending time on prettiness a priority. The
former is incompetence combined with elitism, but the latter is pragmatism
(or laziness, but one can hope).
Post by Pete Batardjust a plain decent driver installer with a GUI, and it
shouldn't be that hard to make it look good.
Agreed, but if it is, I'd suggest that maybe it gets a lower priority.
Post by Pete BatardNow the license is another matter altogether,
No, it was key to my point. You get something that works to YOUR
satisfaction (not mine), and the company that's making money selling the
hardware can invest time in it if they care enough about the user
experience. But I was also making that point before being thoroughly
bewildered by the idea a user will ever see this.
Post by Pete BatardThanks for the pointer. I'll definitely look at it. They probably hook
directly into the DLL or something.
I guess I was unclear, but no, it was an example of the first suggestion
(using the save as hack). I think you probably realized this, though, after
looking at the second email.
Post by Pete BatardAgain, the layout you currently see is was I crafted in a very short
time, and I am very well aware that it needs to be improved on.
And it looks very good. I just don't think it will be used by the people
you imagine. Yes, I know this is easy compared to udev or the like, but
it's still not going to get picked up by a company who cares about not
catching their phone lines on fire, at least not if it is anything more than
an unsupported hidden extra.
Post by Pete BatardI wasn't really ready to discuss the GUI app (or even libwdi) until I
Then, in the future, don't push? :) I wouldn't have even given it a second
thought if someone hadn't been kind enough to do some testing.
Post by Pete Batardtherefore bound to receive a lot criticism.
Well, I hope it's at least been slightly helpful, and not just a
distraction.
Post by Pete BatardFinally, I do hope that I'm still free to use my development time as I
see fit though
Why wouldn't you be? Am I (or anyone else) imposing requirements on you
(other than git details)? I think I was clear at the end of the last email
that you're free to do whatever you want with this. I just thought
mentioning these things might save you some time.
Post by Pete Batardeven if it's seemingly spent looking at the "ooh shiny!" stuff,
as I do enjoy working out these minute UI aspects
Which can be fun. I do understand. But recall this whole thing started
around a comment that something would be a "pain". A paradox to me...
Regards,
Michael