Corinna Vinschen | 1 Feb 2007 09:29
Christopher Faylor | 5 Feb 2007 04:39
Favicon

So *is* anyone thinking of adding support for some sort of dialog interaction for cygwin packages?

Igor mentioned that he had some ideas for adding some sort of
interactive support for cygwin packages so that they could ask questions
and interact during installation.

I think that recent events have shown that letting people know what they
are getting into before they install a package is something that we
really need.  So, if anyone is exploring some way of adding an interactive
"preinstall" capability to setup.exe, I think I can guarantee some gold
stars.

What I'd like to consider doing with gcc (and bash?) is checking the
version currently running on disk and warning people that what they are
doing will require some understanding on their part.

Barring any of that, maybe a really simple solution would be to add a
screen pointing people to the cygwin-announce archives.

cgf

Phil Edwards | 6 Feb 2007 19:55
Picon

Searching in setup.exe

This is initially a "how does one...?" question, but may also be a
design/suggestion for setup.exe as per the rules of
http://cygwin.com/lists.html#cygwin-apps.

Here's the scenario:  having used cygcheck -p to locate the name of a
package that I'd like to download, I find myself staring at
setup.exe's collapsed tree view, wondering where the package is
located.  Most of the time I know the partial name of the package, and
in the cygcheck case I know the exact name.  But I still have to find
the containing category in order to click on the known name.  Sometime
it's obvious, sometimes it isn't.

So my question:  does search.exe support some kind of "search package
names" operation inside the GUI?  Skimming and googling over the
archives of cygwin-apps turned up nothing.

Dave Korn | 6 Feb 2007 20:19
Favicon

RE: Searching in setup.exe

On 06 February 2007 18:55, Phil Edwards wrote:

> This is initially a "how does one...?" question, but may also be a
> design/suggestion for setup.exe as per the rules of
> http://cygwin.com/lists.html#cygwin-apps.
> 
> Here's the scenario:  having used cygcheck -p to locate the name of a
> package that I'd like to download, I find myself staring at
> setup.exe's collapsed tree view, wondering where the package is
> located.  Most of the time I know the partial name of the package, and
> in the cygcheck case I know the exact name.  But I still have to find
> the containing category in order to click on the known name.  Sometime
> it's obvious, sometimes it isn't.
> 
> So my question:  does search.exe support some kind of "search package
> names" operation inside the GUI?  Skimming and googling over the
> archives of cygwin-apps turned up nothing.

  Oh c'mon....  you've read the docs, and it doesn't say so.  You've seen the
GUI, and there's no possible place for a search box, or menu.  How can you
still have to /ask/ someone?  Don't you have the slightest faith in your own
common sense?  Trust yourself a bit more!  Where could this search option
possibly /be/?  I know WJM, but we don't hide things that badly!

  Anyway, the quick solution to your problem is to switch to the "full" view,
at which point all the packages are displayed in alphabetical order and you
can trivially "search" by just scrolling down until you get to the packages
beginning with the same first letter.  It seems hardly worth going to the
trouble of writing a real search.  Still, your question does prompt two
more-easily implemented ideas:
(Continue reading)

Phil Edwards | 6 Feb 2007 20:39
Picon

Re: Searching in setup.exe

On 2/6/07, Dave Korn <dave.korn@...> wrote:
>   Oh c'mon....  you've read the docs, and it doesn't say so.  You've seen the
> GUI, and there's no possible place for a search box, or menu.  How can you
> still have to /ask/ someone?  Don't you have the slightest faith in your own
> common sense?  Trust yourself a bit more!  Where could this search option
> possibly /be/?  I know WJM, but we don't hide things that badly!

Consider it a deep-seated cynicism after years of working in software
development and being constantly surprised by "innovations" in user
interfaces.  I have no faith that I can think of all possible ways of
hiding things.

>   Anyway, the quick solution to your problem is to switch to the "full" view,

Ah, quite handy, thank you very much.  I agree, it doesn't seem worth
writing a "real" search, given this functionality.

> 2)  We could make the output from cygcheck -p return the package category, as
> well as the package name/path.

That would be ideal, from this user's perspective.

thank again!

Corinna Vinschen | 7 Feb 2007 11:17
Favicon

Re: EOL for Windows 95/98/Me

On Jul 24 18:59, Corinna Vinschen wrote:
> Now that Microsoft has finally dropped support for Windows 98 and Me,
> we're going to drop 9x support as well.
> 
> What we're planning to do is this:
> 
> The complete net distribution gets copied to a new place.  This new
> place is the distro kept for people running 9x.  There is no further
> development in this distribution.  Maintainers may decide whether or not
> they apply fixes to the packages in the 9x distro, or keep it up to date
> at all.
> 
> The "normal" net distribution will continue to be the normal distro.  It
> might work on 9x, but there's no guarantee at all that it will continue
> to do so.
> 
> The setup tool (hello setup developers?) should either be split into two
> versions, one for 9x, one for NT.  Or the setup tool should choose the
> download path depending on the OS it's running on.  Or something
> completely different.
> 
> Comments?  Ideas?

Btw., it just occured to me that I'd rather get rid of the 9x stuff in
the 1.7.0 DLL entirely.  This would have visible advantages.

- The code size of the DLL would shrink by a good amount.

- The autoloading of functions could be reduced to the functions not
  available on all NT versions.  This would reduce the autoload overhead
(Continue reading)

Dave Korn | 7 Feb 2007 11:45
Favicon

RE: EOL for Windows 95/98/Me

On 07 February 2007 10:18, Corinna Vinschen wrote:

> On Jul 24 18:59, Corinna Vinschen wrote:

> Btw., it just occured to me that I'd rather get rid of the 9x stuff in
> the 1.7.0 DLL entirely.  This would have visible advantages.
> 
> - The code size of the DLL would shrink by a good amount.
> 
> - The autoloading of functions could be reduced to the functions not
>   available on all NT versions.  This would reduce the autoload overhead
>   by about 90%.
> 
> - The code complexity would be reduced enormously by stripping off at
>   least 50% of the `if (wincap.foo ()) tests.  This would also have
>   some positive effects on the performance.
> 
> - Long 32K pathname support doesn't exist in 9x.  So, when we switch
>   over to using the unicode functions for pathnames, we would have a
>   lot of avoidable hassle to keep 9x running at all.
> 
> You're all convinced, right?

  Hell yeah!  Let's have a mass-delete-fest!

  We should tag the repository beforehand, just in case some retro-enthusiasts
feel like keeping 1.5.x alive on a branch and keeping it hobbling along on '9x
for a while longer.

    cheers,
(Continue reading)

Corinna Vinschen | 7 Feb 2007 11:57
Favicon

Re: EOL for Windows 95/98/Me

On Feb  7 10:45, Dave Korn wrote:
> On 07 February 2007 10:18, Corinna Vinschen wrote:
> > Btw., it just occured to me that I'd rather get rid of the 9x stuff in
> > the 1.7.0 DLL entirely.  This would have visible advantages.
> > 
> > - The code size of the DLL would shrink by a good amount.
> > 
> > - The autoloading of functions could be reduced to the functions not
> >   available on all NT versions.  This would reduce the autoload overhead
> >   by about 90%.
> > 
> > - The code complexity would be reduced enormously by stripping off at
> >   least 50% of the `if (wincap.foo ()) tests.  This would also have
> >   some positive effects on the performance.
> > 
> > - Long 32K pathname support doesn't exist in 9x.  So, when we switch
> >   over to using the unicode functions for pathnames, we would have a
> >   lot of avoidable hassle to keep 9x running at all.
> > 
> > You're all convinced, right?
> 
>   Hell yeah!  Let's have a mass-delete-fest!
> 
>   We should tag the repository beforehand, just in case some retro-enthusiasts
> feel like keeping 1.5.x alive on a branch and keeping it hobbling along on '9x
> for a while longer.

We have a branch for 1.5.x already for >9 months.  Guess where the
recent 1.5.x releases came from? ;)

(Continue reading)

Dave Korn | 7 Feb 2007 12:03
Favicon

RE: EOL for Windows 95/98/Me

On 07 February 2007 10:58, Corinna Vinschen wrote:

> 
> We have a branch for 1.5.x already for >9 months.  Guess where the
> recent 1.5.x releases came from? ;)

  Ah, didn't notice.

  Is 1.7 going to branch off 1.5, or are 1.5 changes going to be merged back
to mainline and 1.7 series kick off from there?

    cheers,
      DaveK
--

-- 
Can't think of a witty .sigline today....

Corinna Vinschen | 7 Feb 2007 12:14
Favicon

Re: EOL for Windows 95/98/Me

On Feb  7 11:03, Dave Korn wrote:
> On 07 February 2007 10:58, Corinna Vinschen wrote:
> > We have a branch for 1.5.x already for >9 months.  Guess where the
> > recent 1.5.x releases came from? ;)
> 
>   Ah, didn't notice.
> 
>   Is 1.7 going to branch off 1.5, or are 1.5 changes going to be merged back
> to mainline and 1.7 series kick off from there?

Er... Dave?  Hello?  There's a 1.5 *branch*.  Where, do you guess, is
1.7 developed in?  The trunk maybe?

The trunk is 1.7 since 2006-07-25.  Didn't you notice that the snapshots
already diverge from 1.5 for a couple of months?  I actually thought
you're one of the guys following the development...

Corinna

--

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


Gmane