Philippe Bertin wrote:
[...]
>>> Well that's what I meant. Maybe in the link above, it could be
>>> mentioned that this is an example of how to use libglade. It'd help
>>> out people (digging into the subject) to obtain an example more rapidly.
>>
>>
>> Some things are the way they are - and wont improve untill someone
>> who cares about those particular things sends a patch, I'm sure
>> James Henstrige wouldnt refuse that simple kind of patch...
>
>
> [EMAIL PROTECTED]:/usr/compils/glade3-3.0.1> find . -name test-libglade.c
> [EMAIL PROTECTED]:/usr/compils/glade3-3.0.1>
>
> It doesn't seem to be there ?
Yes, thats the libglade tarball you're looking for - not the glade3 tarball.
>>>> I think we need a little more trust on this front, if the user
>>>> is tampering with the system, its not a valid bug report/use case.
>>>
>>>
>>> That's a political discussion ;-)
>>
>>
>> Ugh - I give up here, I dont see why you are arguing that an
>> application distributor should support a situation where the
>> user tampered with the software (yes, the xml glade file that you
>> distributed with the app is "part of the software") - this is
>> not political at all.
>
>
> My reasoning is that if you inhibit the user the *possibility* to tamper
> with the files you deliver, you won't have to take this into account
> when providing support. Call me a security (effectiveniss ?) freak: the
> less tweaking that can be done, the less support one should provide. If
> you provide your compiled program as one whole (i.e. without a separate
> file called e.g. project.glade), then the question "Did you tamper with
> project.glade, sir ?" is a question you shouldn't even think of asking
> when supporting your end product. But it would surely have to be one of
> the *first* questions you'd be obliged to ask your customer when not
> linking everything statically (i.e. using libglade's autoconnect
> possibilities)...
The perspective I have is - a software distribution & suite including
a kernel, base operating system, window manager & windowing system,
applications, installers, package managers - everyone has thier distinct
role to play, the role of safegaurding configuration data files is
that of the package manager & operating system setup, at least somewhere
along those lines.
So my question is - if you have so much spare time to go stopping up
every possible way to recieve a bug report, why dont you spend that
time improving the package manager on the distribution of choice for
your end users instead ? ... how are we moving ahead as a community
if we dont share responsability ?
Also, its a two way street here - if you're not willing to work with
users bug reports and tree them properly - forwarding the correct bug
reports to GNOME, the linux kernel, Xorg and whatnot, and participate
to a certain extent in the free desktop computing system that your
software is running on, why should you expect to get any support in return ?
While that doesnt pertain directly to your "less possible tampering -
less support" philosophy - I think that that philosophy of doing
something differently than everyone else because for some reason -
you cant afford the real work when everyone else can - well I think
you get my drift.
Cheers,
-Tristan
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
