Re: [RFC] calm, setup: per-version requires

[Achim Gratz]

Jon Turney writes:
> prior to 2.880:  Will ignore 'depends:', so 'requires:' needs to
> remain the union of dependencies for the benefit of these versions of
> setup.

If you want to maintain backwards compatibility.  I am still sitting on
the fence on that, but I currently lean to propose a clean cut and
producing a setup.ini file for backwards compatibility for some time in
parallel with some new file that uses the new syntax only.

> 2.880 onwards: The curr: version will get the union of 'depends:' and
> 'requires:', other versions will get 'requires:'.

That doesn't make any sense, since the requires would be the union of
all depends already.  So, 2.880+ should ignore the requires: and use the
union of [curr] and any version specific depends:.  But maybe I
misunderstood what you want to be doing.

> The prereq checker checks that the dependencies are satisfied
> (including any version relation), but then installs the 'curr:' or
> 'test:' version (depending on chooser preference) imagining that will
> satisfy it.
>
> libsolv-based: 'depends:' supersedes 'requires:', installs the right
> right thing (hopefully :))

Wait…  I thought libsolve-based was 2.880+?

Again the note that the libsolve-based setup.ini format should include a
way to provides: a named feature that other packages can then depends:
on.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: [PATCH setup 00/14] Use libsolv, solve all our problems... (WIP)

[Ken Brown]

On 12/5/2017 9:32 AM, Jon Turney wrote:

On 14/09/2017 21:46, Ken Brown wrote:

On 9/14/2017 1:26 PM, Achim Gratz wrote:

Ken Brown writes:

What I've been struggling with, however, is the UI.  But now that I
think about it, maybe it isn't that hard.  It's just a matter of doing
something reasonable if the user unchecks "Accept default problem
solutions".  I'll see what I can come up with.


Well, zypper pretty much just gives you a bunch of possible solutions
and asks you to select one if there is either more than one or the
otherwise preferred solution is blocked by a lock.  There is always one
"break  package by doing " down that list.  You could
maybe offer something along those lines in the inevitable dialog box?


In the long run I think that's the way to go.  But implementing that 
is more work than I feel like doing at the moment.  For now I've gone 
with an approach that was easier to program, more like the current 
setup.exe.   If the solver finds problems (including missing 
dependencies), the user has four choices on the Prerequisite page:


1. Click Back to go back to the Chooser page, with the Pending view 
showing the solver's default solutions.


2. Click Next to accept the default solutions.


Doing some testing of per-version requires, I've been looking at this 
page quite a bit.


It seems we're missing something to actually apply the default solution, 
so "accept default solutions" makes no changes, at the moment. (looks 
like we have to do this ourselves with solver_take_solution() ?)


I'm not sure.  I thought at some point I saw "accept default solutions" 
do something, but there have been a lot of changes since then.


Also, in the dependency problem report, we should identify which of the 
possible solutions is the default one, so it's clearer what "accept 
default solutions" is going to do.


Agreed.

Ken

Re: [PATCH setup] Make Enter in the user URL box cause ADD instead of NEXT

[Ken Brown]

On 12/5/2017 11:03 AM, Ken Brown wrote:

On 12/5/2017 7:58 AM, Jon Turney wrote:

Please apply.


Done.


The search textbox on the package chooser page needs the same fix.


It's not immediately clear to me how to do this, since I don't know what 
the default pushbutton should be while the user is typing in the search 
box.


One possibility is to convert the label "Search" to the left of the box 
to a SEARCH pushbutton, whose effect is to call OnTimerMessage().  If we 
make this the default, then pressing Enter will cause the search filter 
to immediately take effect, which is probably what the user expects.


Something like the attached?  This might not be quite right, because the 
previous default button is never restored.  I'm not sure how important 
that is.


Ken

From e7f96c2db95c8bb4e9eb3a91730db7328b6e7d12 Mon Sep 17 00:00:00 2001
From: Ken Brown 
Date: Tue, 5 Dec 2017 12:21:12 -0500
Subject: [PATCH] Fix response to Enter in the chooser textbox

Make Enter cause the search filter to immediately take effect.
Previously Enter would cause NEXT.
---
 choose.cc  |  5 +
 res.rc | 10 +-
 resource.h |  1 +
 3 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/choose.cc b/choose.cc
index 1bc4c0b..0c6704f 100644
--- a/choose.cc
+++ b/choose.cc
@@ -386,6 +386,7 @@ ChooserPage::OnMessageCmd (int id, HWND hwndctl, UINT code)
 
   if (code == EN_CHANGE && id == IDC_CHOOSE_SEARCH_EDIT)
 {
+  SendMessage (GetHWND (), DM_SETDEFID, (WPARAM) IDC_CHOOSE_DO_SEARCH, 0);
   SetTimer(GetHWND (), timer_id, SEARCH_TIMER_DELAY, (TIMERPROC) NULL);
   return true;
 }
@@ -402,6 +403,10 @@ ChooserPage::OnMessageCmd (int id, HWND hwndctl, UINT code)
   }
   break;
 
+case IDC_CHOOSE_DO_SEARCH:
+  SendMessage (GetHWND (), WM_TIMER, (WPARAM) timer_id, 0);
+  break;
+
 case IDC_CHOOSE_KEEP:
   if (IsButtonChecked (id))
 keepClicked();
diff --git a/res.rc b/res.rc
index a4d7e70..8839196 100644
--- a/res.rc
+++ b/res.rc
@@ -323,11 +323,11 @@ END
 #define SETUP_VIEW_W   (20)
 #define SETUP_VIEWLIST_X   (SETUP_VIEW_X + SETUP_VIEW_W + 2)
 #define SETUP_VIEWLIST_W   (60)
-#define SETUP_SEARCH_X (SETUP_VIEWLIST_X + SETUP_VIEWLIST_W + 2)
+#define SETUP_SEARCH_X (SETUP_SEARCHTEXT_X + SETUP_SEARCHTEXT_W + 2)
 #define SETUP_SEARCH_W (32)
-#define SETUP_SEARCHTEXT_X (SETUP_SEARCH_X + SETUP_SEARCH_W + 2)
+#define SETUP_SEARCHTEXT_X (SETUP_VIEWLIST_X + SETUP_VIEWLIST_W + 2)
 #define SETUP_SEARCHTEXT_W (60)
-#define SETUP_CLEAR_X  (SETUP_SEARCHTEXT_X + SETUP_SEARCHTEXT_W + 2)
+#define SETUP_CLEAR_X  (SETUP_SEARCH_X + SETUP_SEARCH_W + 2)
 #define SETUP_CLEAR_W  (22)
 
 IDD_CHOOSE DIALOG DISCARDABLE  0, 0, SETUP_STANDARD_DIALOG_DIMS
@@ -340,10 +340,10 @@ BEGIN
 SETUP_VIEW_W, 10
 COMBOBOXIDC_CHOOSE_VIEW, SETUP_VIEWLIST_X, 30, SETUP_VIEWLIST_W, 
84,
 CBS_DROPDOWNLIST | WS_TABSTOP
-RTEXT   "", IDC_STATIC, SETUP_SEARCH_X, 33, SETUP_SEARCH_W,
-10, SS_CENTERIMAGE, WS_EX_RIGHT
 EDITTEXTIDC_CHOOSE_SEARCH_EDIT, SETUP_SEARCHTEXT_X, 30,
 SETUP_SEARCHTEXT_W, 14, ES_AUTOHSCROLL
+PUSHBUTTON  "", IDC_CHOOSE_DO_SEARCH, SETUP_SEARCH_X, 30,
+SETUP_SEARCH_W, 14
 PUSHBUTTON  "", IDC_CHOOSE_CLEAR_SEARCH, SETUP_CLEAR_X, 30,
 SETUP_CLEAR_W, 14
 CONTROL "", IDC_CHOOSE_KEEP, "Button", BS_AUTORADIOBUTTON
diff --git a/resource.h b/resource.h
index a2e867f..79b876d 100644
--- a/resource.h
+++ b/resource.h
@@ -177,3 +177,4 @@
 #define IDC_FILE_INUSE_HELP   592
 #define IDC_NET_DIRECT_LEGACY 593
 #define IDC_DOWNLOAD_EDIT 594
+#define IDC_CHOOSE_DO_SEARCH  595
-- 
2.15.0

Re: [PATCH setup] Make Enter in the user URL box cause ADD instead of NEXT

[Ken Brown]

On 12/5/2017 7:58 AM, Jon Turney wrote:

Please apply.


Done.


The search textbox on the package chooser page needs the same fix.


It's not immediately clear to me how to do this, since I don't know what 
the default pushbutton should be while the user is typing in the search box.


One possibility is to convert the label "Search" to the left of the box 
to a SEARCH pushbutton, whose effect is to call OnTimerMessage().  If we 
make this the default, then pressing Enter will cause the search filter 
to immediately take effect, which is probably what the user expects.


Or do you have a better idea?

Ken

Re: [ITA] lcms2-2.9-1

[Andrew Schulman]

> On 2017-11-27 10:04, Ken Brown wrote:
> > My cygport file is attached.
> 
> GTG; package is yours now.  Thanks!

Gold star awarded! https://cygwin.com/goldstars/#KB

Re: [ITA] libXpm-noX 3.5.12

[Andrew Schulman]

> On 15/11/2017 17:30, Ken Brown wrote:
> > My cygport file and other files needed for reproducing the build are 
> > attached.
> 
> I added this to your uploads, 

Gold star awarded! https://cygwin.com/goldstars/#KB

Re: [RFC] calm, setup: per-version requires

[Jon Turney]

On 09/11/2017 18:18, Achim Gratz wrote:

Jon Turney writes:

On 05/11/2017 07:34, Achim Gratz wrote:
Yeah, I guess we could generate requires: line in each version section
now, and this might work with current setup.  I don't think this did
anything useful prior to [1] being fixed.


Yes, and even though I think the parser would accept them they weren't
really expected anyway.


The libsolv branch implements per-version '[dD]epends:' headers as per
[2] (which may also contain a version relation)


I'd really prefer we'd come up with a solution that does not have us
repeat the common dependencies for each version present.


My current plan is to do the simplest thing:
- requires: remains the union of dependencies
- if the version has a depends: hint, use that for depends: (not 
something cygport is currently capable of generating)

- otherwise, generate depends: from the requires: hint for the version


It's probably useful to bear in mind how various versions of setup will 
behave if I was to turn on 'depends:' generation in calm.  From staring 
at the code (so subject to testing), I think it breaks down as follows:


prior to 2.880:  Will ignore 'depends:', so 'requires:' needs to remain 
the union of dependencies for the benefit of these versions of setup.


2.880 onwards: The curr: version will get the union of 'depends:' and 
'requires:', other versions will get 'requires:'.


The prereq checker checks that the dependencies are satisfied (including 
any version relation), but then installs the 'curr:' or 'test:' version 
(depending on chooser preference) imagining that will satisfy it.


libsolv-based: 'depends:' supersedes 'requires:', installs the right 
right thing (hopefully :))

Re: [PATCH setup 00/14] Use libsolv, solve all our problems... (WIP)

[Jon Turney]

On 14/09/2017 21:46, Ken Brown wrote:

On 9/14/2017 1:26 PM, Achim Gratz wrote:

Ken Brown writes:

What I've been struggling with, however, is the UI.  But now that I
think about it, maybe it isn't that hard.  It's just a matter of doing
something reasonable if the user unchecks "Accept default problem
solutions".  I'll see what I can come up with.


Well, zypper pretty much just gives you a bunch of possible solutions
and asks you to select one if there is either more than one or the
otherwise preferred solution is blocked by a lock.  There is always one
"break  package by doing " down that list.  You could
maybe offer something along those lines in the inevitable dialog box?


In the long run I think that's the way to go.  But implementing that is 
more work than I feel like doing at the moment.  For now I've gone with 
an approach that was easier to program, more like the current setup.exe. 
  If the solver finds problems (including missing dependencies), the 
user has four choices on the Prerequisite page:


1. Click Back to go back to the Chooser page, with the Pending view 
showing the solver's default solutions.


2. Click Next to accept the default solutions.


Doing some testing of per-version requires, I've been looking at this 
page quite a bit.


It seems we're missing something to actually apply the default solution, 
so "accept default solutions" makes no changes, at the moment. (looks 
like we have to do this ourselves with solver_take_solution() ?)


Also, in the dependency problem report, we should identify which of the 
possible solutions is the default one, so it's clearer what "accept 
default solutions" is going to do.


3. Uncheck the "Accept default solutions" box and click Next.  If the 
user dismisses the resulting warning, setup will go ahead and do what 
the user requested.


4. Cancel.

Re: [PATCH setup v2 0/5] Distinguish between user URLs and cygwin mirrors in UI

[Jon Turney]

On 04/12/2017 21:48, Ken Brown wrote:

On 12/4/2017 10:18 AM, Ken Brown wrote:

This is the same as the previous patch series with one cosmetic
improvement: I've now made user URLs sort last, so that the
distinction between user URLs and cygwin.com mirrors is visually more
clear.


Sorry for repeatedly responding to myself, but I think I see now how to 
build on what I've done and show user URLs on a separate page as Jon 
originally suggested.


No problem, thanks for looking into this.

My suggestions are just that, I'm sure there are other and better ways 
of approaching this.

Re: [PATCH setup] Make Enter in the user URL box cause ADD instead of NEXT

[Jon Turney]

On 04/12/2017 15:58, Ken Brown wrote:

---
  site.cc | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/site.cc b/site.cc
index 641a6bb..64e56a8 100644
--- a/site.cc
+++ b/site.cc
@@ -759,7 +759,9 @@ bool SitePage::OnMessageCmd (int id, HWND hwndctl, UINT 
code)
  {
  case IDC_EDIT_USER_URL:
{
-   // FIXME: Make Enter here cause an ADD, not a NEXT.
+   // Set the default pushbutton to ADD if the user is entering text.
+   if (code == EN_CHANGE)
+ SendMessage (GetHWND (), DM_SETDEFID, (WPARAM) IDC_BUTTON_ADD_URL, 0);
break;
}
  case IDC_URL_LIST:



Very nice.  That fixme has been there since 2002 (and the bug probably 
longer...)


I thought perhaps we might need to reset the default control if the 
focus is moved to another control after IDC_EDIT_USER_URL so that enter 
works correctly then, but that doesn't seem to be the case.


Please apply.

The search textbox on the package chooser page needs the same fix.