[izpack-users] Debugging Panel

Miraodb miraodb at hotmail.com
Tue Mar 7 09:59:46 CET 2006


Hi klaus,

I see what you mean and i must say that it makes sense as long as those
panels are really what we call custom.
Custom in the sense that only a few users or developer would find them
useful. Custom also in the sense that they could change depending on
user/developer needs.
However, what if we have panels that are completely documented, very useful
for user coz asked so many times in the list and that should unlikely never
change.

I agree that the dataCheckPanel is NOT one of them, it could change, surely
will, Plus it's really necesarry only for developers.

The sample folder... i never really understood its use. I'm sure the idea of
the custom folder makes more sense. For one thing, it's no big deal to move
sample to custom and also it would be wise to keep a naming convention.

Custom actions, custom panels, custom this, custom that..... should be in
"Custom" folder.

Another point, you mentioned about how Custom stuffs should be specified as
non-supported stuffs.
Well, i think that's a bit harsh but it's true though. Some guyz might
develop things for their own goal, share it and then leave the project. Are
we gonna hunt them down till they answer... that would sound like the
mafia's job, not ours :-)
Seriously... i think there's enough skilled people in this project to assure
a reasonable support, even on things that we didn't do ourselves. We could
say something like: "Custom stuffs are not part of the official docu but
information and help can be found either in the list or in the wiki".

What do you think ?

Conclusion for custom folder is: I vote YES !

Cheers,
fabrice

----- Original Message ----- 
From: "Klaus Bartz" <bartzkau at gmx.net>
To: <izpack-users at berlios.de>
Sent: Tuesday, March 07, 2006 9:28 AM
Subject: Re: [izpack-users] Debugging Panel


> Uups, wrong button pressed, sorry.
> secound try...
> Am 07.03.2006, 09:10 Uhr, schrieb Klaus Bartz <bartzkau at gmx.net>:
>
> > Hi,
> > nice to see a new panel.
> > Of course, docu is real importent because not so much people means
> > (as I) that the source is the best docu :-)
> By the way, what about a separate package for custom panels of
> IzPack users? The package
> com.izforge.izpack.panels
> contains all the standard panels. I think there should be a restricted
> policy for this panels. E.g. support should be possible also the author
> is not available. Some of our current panels makes at this some
problems...
>
> But there are custom panels which makes there job for one or two
> user, but they are not really common. I have some which I can share,
> but I have no time (and fun) to bring them on a state which will be
> needed to put them into the panels package. As short message:
> Let us create a separate package for custom panels where we said
> "these are custom panels from IzPack users without support from the
> IzPack developer team". Docu have to be, but in a saparate chapter.
> My idea:
> com.izforge.izpack.custom.panels
> Since ~ 10 month we have com.izforge.izpack.sample. But I think
> these type of panels are a little bit more than samples, therefore
> an other path.
>
> Any comment?
>
> Cheers
>
> Klaus
>
>
> >
> >
> > Am 06.03.2006, 17:36 Uhr, schrieb Miraodb <miraodb at hotmail.com>:
> >
> >> Hey,
> >>
> >> Better think twice before posting ;) ahahahhaha
> >> Just kidding !
> >> Just tried this panel and it's real cool.
> >>
> >> If you can write up a small doc (should be real small from what i can
> >> imagine...) and then i can commit that if nobody is against it. I'll of
> >> course update the docu.
> >>
> >> Cheers,
> >> fabrice
> >> ----- Original Message -----
> >> From: "Hal Vaughan" <hal at thresholddigital.com>
> >> To: <izpack-users at berlios.de>
> >> Sent: Monday, March 06, 2006 3:17 AM
> >> Subject: Re: [izpack-users] Debugging Panel
> >>
> >>
> >>> Attached is a slightly newer version, that prints out everything to
the
> >>> console and presents it in a scrollable text area for ease of viewing.
> >>>
> >>> Hal
> >>>
> >>>
> >>> On Sunday 05 March 2006 12:07, Hal Vaughan wrote:
> >>> > While working on a few panels, I found I needed to get values of
> >>> > several variables in InstallData as well as reading allPacks and
> >>> > selectedPacks to see which packs were there and which were selected.
> >>> >
> >>> > One panel I'm working on, ProgramFinderPanel, can remove packs from
> >>> > allPacks and selectedPacks, but has to re-insert them if the end
user
> >>> > backs up, so I needed a way to check all the variables both before
> >>> > and after the panel I was testing.  I've gotten tired of temporarily
> >>> > altering other panels to print out variables or pack names to check
> >>> > on the results from the panel I'm working on, and realized it'd be
> >>> > easier to make a simple test panel.
> >>> >
> >>> > I created DataCheckPanel, which has NOTHING but a line of text on
it,
> >>> > saying it is for debugging (maybe I'll add a scrolling text area to
> >>> > it), but it prints to the console a sorted list of all the variables
> >>> > in InstallData, along with a list of allPacks, indentifying which
> >>> > packs are selected.
> >>> >
> >>> > The code is attached.  (Does this list accept attachments?  If not,
> >>> > I'll reply to this with the code in the text of the letter.)
> >>> >
> >>> > I hope it can help others like it's helped me.
> >>> >
> >>> > Hal
> >>>
> >>
> >>
> >> _______________________________________________
> >> izpack-users mailing list
> >> izpack-users at lists.berlios.de
> >> http://lists.berlios.de/mailman/listinfo/izpack-users
> >>
> >>
> >> __________ NOD32 1.1422 (20060301) Information __________
> >>
> >> Diese E-Mail wurde vom NOD32 Antivirus System geprüft
> >> http://www.nod32.com
> >>
> >>
> >
> >
> >
>
>
>
> -- 
> Erstellt mit Operas revolutionärem E-Mail-Modul:
http://www.opera.com/mail/
> _______________________________________________
> izpack-users mailing list
> izpack-users at lists.berlios.de
> http://lists.berlios.de/mailman/listinfo/izpack-users
>





More information about the izpack-users mailing list