> I apologize, I misread.
No problem. It happens all the time. It's similar to the english
shortening of the name Robert to 'Bob'. Ugh. *shudder* It's like pouring ice
down the back of my shirt.
> <sarcasm> So you better kick the whole Plucker for Win, because that
> requires a lot of proprietary, non-free components. Foundation classes
> for example, Win libs, or DOS. </sarcasm>
Technically, building open source software with the Palm SDK
directly violates their licensing agreement by sharing constructs of
internally developed code which is contained in the SDK, available by
agreeing to a license when downloaded/obtained.
> I don't insist on the control, it's merely convenient. But your
> hypocrisy(sp?) drives me mad.
Sorry about that. Sometimes I come across that way, but it's not
intentional.
> Actually I never intended to include my app in your CVS, nor did I
> intend to have a discussion about including it at all. I asked Dirk
> whether or not there was a tool like mine yet, and if not, whether he'd
> test it before I'd put it up on _my_ homesite to share with others who'd
> want it.
I see no problem whatsoever with including the code anywhere it's
referenced, whether that be in the cvs, the website, linked to your website,
in the FAQ, in the docs, whereever.
I do, however, care about burdoning the end users with the
requirement that they either license this control, or have to download/warez
the control to get it to build. If it's optional, and doesn't cripple the
capabilities of your tool, I'm all for it.
> It was Dirk who suggested telling this list; and I did so, hoping to get
> some input on how to make it better. Again, solely for my own
> satisfaction. All the better if the outcome would make it more
> satisfying to possible other users, but that isn't essential, it's
> merely an added benefit to me. And yes, the discussion with Dirk _did_
> give me some valuable insights.
If I had more experience with Windows, other than from a sysadmin
perspective or UI perspective, I would lend my comments. I don't have any of
the development tools required to build the software you and Dirk are
developing under Windows.
> Of course I thought about offering you to link to my site, because Win
> users would perhaps like to know about it, and the first place they'd
> look for something would be your site.
When you feel that the package is ready for public consumption, the
link can be put whereever the Windows users can easily reach it, either from
the docs, the download page, wherever.
Don't get me wrong, what you've done is great work from what I see
from the screenshot and the discussions I've read here between Dirk and
yourself. I fully support it's development and advancement. Wherever
possible, it is better to find and support any potential free alternatives
which provide the same or similar functionality.
> > third-party tool can do what they wish, proprietary or not, however,
> > the Plucker project itself will not be able to accept those patches or
> > additions internally if they require proprietary components or code.
>
> You mean like PalmOS?
Exactly. Proprietary. Restrictive. Limited. I support it because I
like the device. I have had many arguments with them in person, over and
over and over, and they've slowly started to open their eyes. It's
unfortunate that there are not more converts in their facility, as they
begin to clamp down on the tools and internalize them (POSE, prc-tools,
pilrc, etc.; they're trying to pull these in-house, and have declared an
initiative to do so within the next 3 quarters).
> It wraps Dirk's work into a GUI, there is no redundancy.
Ok, I misunderstood the purpose of the tool.
> If there was a free alternative, don't you think I'd have it?
I don't assume anything. Sometimes the alternatives aren't known.
Perhaps the component shipped with your IDE, perhaps it came with some other
product. Maybe there was no reason to seek out and find a free alternative.
What exactly is the name of this component again? What does it
provide? Simple resizing of a dialog?
> 2) The source does not contain the control.
Is the functionality of the source decreased without the control?
Can the source be built and function in absence of the control?
> 2a) unless a developer explicitely wants it (which would mean (s)he
> must email me).
Or obtain it from the original author, no? (albeit with a nag)
> 3a) and will run without problems without the control.
Ok, this was my concern.
> 4) I can (not must) include the control in the compiled executable.
*nod*
> 4a) I can just as well distribute the executable without the control.
What are the restrictions (imposed by the author of the control)
about distributing an executable compiled with that control (if any)?
> Do you want a polite or an honest answer?
I have thick skin. I prefer honesty, not costumes. I think we've
both come clear with our understandings here. I'm not trying to start a war.
I'm only trying to make sure that we don't cause users any additional stress
or strain, or that the functionality of your tool or Dirk's tool underneath
it, isn't decreased by the use of or removal of this control.
/d
