Re: cygwin install blurry on high dpi Windows 10
On Fri, May 29, 2020 at 7:16 PM Jon Turney wrote: > > On 27/05/2020 12:41, Sharuzzaman Ahmat Raslan via Cygwin wrote: > > Hi, > > > > My office laptop is Windows 10 with a high DPI display. > > > > I found that the installer is blurry, especially inside the window. The > > title of the window is clear. > > > > Is this something that has been reported before? If nobody has reported it, > > then I would like to report the issue here. > > Thanks for reporting this issue. > > This is Windows doing "dpi virtualization" (it reports 96 dpi to the > app, and then upscales what it draws to the actual dpi) > > Since we (now) use standard UI elements for everything in setup, it > should 'just' be a case of marking setup as being able to handle being > told the real dpi. > > I built an updated setup with that change: > > https://cygwin.com/setup/setup-2.904-4-gaa071e.x86_64.exe > https://cygwin.com/setup/setup-2.904-4-gaa071e.x86.exe > Thank you very much. I was waiting for this to happen. Here's a before-and-after comparison: https://imgur.com/a/nawlvNd Csaba -- You can get very substantial performance improvements by not doing the right thing. - Scott Meyers, An Effective C++11/14 Sampler So if you're looking for a completely portable, 100% standards-conformant way to get the wrong information: this is what you want. - Scott Meyers (C++TDaWYK) -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygwin install blurry on high dpi Windows 10
Am 29.05.2020 um 18:05 schrieb Jon Turney: On 27/05/2020 12:41, Sharuzzaman Ahmat Raslan via Cygwin wrote: Hi, My office laptop is Windows 10 with a high DPI display. I found that the installer is blurry, especially inside the window. The title of the window is clear. Is this something that has been reported before? If nobody has reported it, then I would like to report the issue here. Thanks for reporting this issue. This is Windows doing "dpi virtualization" (it reports 96 dpi to the app, and then upscales what it draws to the actual dpi) Since we (now) use standard UI elements for everything in setup, it should 'just' be a case of marking setup as being able to handle being told the real dpi. I built an updated setup with that change: https://cygwin.com/setup/setup-2.904-4-gaa071e.x86_64.exe https://cygwin.com/setup/setup-2.904-4-gaa071e.x86.exe Looks fine for me, sharp as a knife. However, also the font size is a half-point smaller and looks quite spiddly, maybe you could make it a point larger? Thanks Thomas -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygwin install blurry on high dpi Windows 10
On 27/05/2020 12:41, Sharuzzaman Ahmat Raslan via Cygwin wrote: Hi, My office laptop is Windows 10 with a high DPI display. I found that the installer is blurry, especially inside the window. The title of the window is clear. Is this something that has been reported before? If nobody has reported it, then I would like to report the issue here. Thanks for reporting this issue. This is Windows doing "dpi virtualization" (it reports 96 dpi to the app, and then upscales what it draws to the actual dpi) Since we (now) use standard UI elements for everything in setup, it should 'just' be a case of marking setup as being able to handle being told the real dpi. I built an updated setup with that change: https://cygwin.com/setup/setup-2.904-4-gaa071e.x86_64.exe https://cygwin.com/setup/setup-2.904-4-gaa071e.x86.exe Perhaps you could try that and see if it improves things for you? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Help needed with gobject-introspection
On 25/05/2020 16:04, Ken Brown via Cygwin-apps wrote: On 5/24/2020 1:00 PM, Ken Brown via Cygwin-apps wrote: On 5/24/2020 12:45 PM, Ken Brown via Cygwin-apps wrote: On 5/24/2020 11:56 AM, Jon Turney wrote: On 21/05/2020 18:07, Ken Brown via Cygwin-apps wrote: On 5/21/2020 11:48 AM, Jon Turney wrote: On 21/05/2020 16:13, Ken Brown via Cygwin-apps wrote: On 5/21/2020 9:24 AM, Jon Turney wrote: On 20/05/2020 15:50, Ken Brown via Cygwin-apps wrote: On 5/19/2020 7:04 PM, Ken Brown via Cygwin-apps wrote: [...] This does indeed shed some light. If I remove all the commas but leave the single quotes, the command fails with the same error message as before: cp: target 'docs/index.html.tmp' is not a directory If I also remove the single quotes, the command succeeds. I think the problem is the quotes around the double ampersands, so they are treated as arguments to the cp command instead of being interpreted by the shell executing the command. So, yeah, this is a meson bug, which I will work on (if this command ends up in the build.ninja, it's executed by ninja with 'sh -c', but if it ends up in a pickle, it's executed by meson with execve()) Yes, that does seem like a meson bug. But is it also a babl bug to some extent? When babl puts '&&' in a command argument, it's assuming that the command will be executed by 'sh -c'. I have very little experience with meson. Have you ever seen this issue in other projects that use meson? I just noticed this, at https://mesonbuild.com/Custom-build-targets.html : Meson only permits you to specify one command to run. This is by design as writing shell pipelines into build definition files leads to code that is very hard to maintain. If your compilation requires multiple steps you need to write a wrapper script that does all the necessary work. We're not talking about a shell pipeline here, but it's similar. So I'm thinking this really is a babl bug. Yeah. Ideally meson would stop people from writing custom targets which use shell operators. Unfortunately, it doesn't and there are probably many other existing instances of this usage. Additionally, meson is perhaps a bit schizophrenic on this topic and (I think) actually has code to make sure this works as expected when the command ends up being put directly into build.ninja (which is what will usually happen on linux etc.) Regardless of whose bug it is, I've got a simple but ugly workaround (attached), now that you've explained to me what's going on. Good stuff.
Re: Help needed with gobject-introspection
On 27/05/2020 21:32, Ken Brown via Cygwin-apps wrote: On 5/24/2020 11:56 AM, Jon Turney wrote: So, yeah, this is a meson bug, which I will work on (if this command ends up in the build.ninja, it's executed by ninja with 'sh -c', but if it ends up in a pickle, it's executed by meson with execve()) It looks like I've bumped into a variation of this bug. While attempting to build the documentation for the latest glib2.0 release, I got the following: FAILED: docs/reference/gobject/gobject-decl.txt /usr/bin/meson --internal exe --unpickle /home/kbrown/src/cygpackages/glib2.0/glib2.0-2.64.3-1.x86_64/src/glib-2.64.3/x86_64-pc-cygwin/meson-private/meson_exe_meson_1ed2fbe217cac49ae4affd274e0d4a729085a002.dat ['/usr/bin/meson', '--internal', 'gtkdoc', '--sourcedir=/home/kbrown/src/cygpackages/glib2.0/glib2.0-2.64.3-1.x86_64/src/glib-2.64.3', '--builddir=/home/kbrown/src/cygpackages/glib2.0/glib2.0-2.64.3-1.x86_64/src/glib-2.64.3/x86_64-pc-cygwin', '--subdir=docs/reference/gobject', '--headerdirs=gobject', '--mainfile=gobject-docs.xml', '--modulename=gobject', '-- [...] /docs/reference/gobject/tut_tools.xml', '--cc=gcc', '--ld=gcc', '--cflags=-I@BUILD_ROOT@/gobject -I../gobject -pthread -I@BUILD_ROOT@/. -I../. -I@BUILD_ROOT@/glib -I../glib -I@BUILD_ROOT@/docs/reference/gobject/. -I../docs [...] So @BUILD_ROOT@ didn't get replaced by the build root after pickling and unpickling. Needless to say, this produced errors like: cc1: error: @BUILD_ROOT@/glib: No such file or directory [-Werror=missing-include-dirs] I can give you a precise recipe for reproducing this bug if it would help your debugging. Definitely a bug. I'll see if I can take a look at it this weekend.
Re: Issue with lyx and recent dll
On Thu, May 28, 2020 at 10:01:15PM +0200, Marco Atzeri via Cygwin wrote: > On 28.05.2020 20:25, Enrico Forestieri wrote: > > On Thu, May 28, 2020 at 08:09:49PM +0200, Marco Atzeri via Cygwin wrote: > > > > > > after installing also another package > > > texlive-collection-pstricks > > > > > > I was able to have an instant preview > > > > > > can you check if the test 2.3.4.2-2 > > > solve the issue also for you ? > > > Than I can promote it to stable > > > > Yes, that did it! I am curious to know how you compiled it, because I see > > the same strange behavior when compiling lyx from source. > > > > > --enable-qt5 PYTHON="python3" Doh! Nevertheless, it remains a mystery why I had to revert to cygwin 3.0.7 for having instant preview working with the Qt4 version. -- Enrico -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: git repositories for cygwin packaging - please test
On 29/05/2020 15:40, Alexey Sokolov wrote:
04.08.2019 21:08, Jon Turney пишет:
Please give this a test, if possible, and report any problems here.
I've tried to push the playground branch to
cygwin.com:/git/cygwin-packages/znc and the output was full of this:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "",
LC_ALL = (unset),
LANG = "ru_RU.utf8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "",
LC_ALL = (unset),
LANG = "ru_RU.utf8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Fascinating.
I've stopped the local setting of LANG propagating into this script on
the remote, which should prevent this (but this probably means that the
remote git won't give you localized output, if it did before)
These are just warnings, the push was successful.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: git repositories for cygwin packaging - please test
04.08.2019 21:08, Jon Turney пишет:
>
> While a number of maintainers keep their cygwin packaging under some
> sort of version control, there is currently no central collection of
> these repositories.
>
> To remedy this lack, using the same ssh key you use for sftp package
> upload, package maintainers can now also push to git repositories, like so:
>
> git push cyg...@cygwin.com:/git/cygwin-packages/
>
> where is a package name you are listed as a maintainer for
> in http://cygwin.com/cygwin-pkg-maint.
>
> These repositories are lazily created on the first push.
>
> Since it's intended that these repositories will only contain cygport
> scripts, patches, and other packaging files, and to prevent the
> accidental committing of upstream archives, pushes containing large
> binary files will be rejected.
>
> These repositories are viewable via gitweb at
> https://cygwin.com/git-cygwin-packages/ (URL may be subject to change),
> and should be cloneable via anonymous git/http with the URLs shown there.
>
> Please give this a test, if possible, and report any problems here.
I've tried to push the playground branch to
cygwin.com:/git/cygwin-packages/znc and the output was full of this:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "",
LC_ALL = (unset),
LANG = "ru_RU.utf8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "",
LC_ALL = (unset),
LANG = "ru_RU.utf8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Re: Update of packages by non-maintainer
Am 29.05.2020 um 00:34 schrieb Yasuhiro KIMURA: In my case following line should be put as override.hint. Right? -- curr: 0.4-1 -- You would probably also need a "replace-versions:" line. I'd tend to use the "version:" line to override the upstream version number to something that sorts correctly with the previous version number in this case, though. Something as simple as "deb+0.4" might already do that. -- Achim. (on the road :-)
[ANNOUNCEMENT] Updated: lyx-2.3.4.2-2
released On 27.04.2020 09:27, Marco Atzeri wrote: New test version 2.3.4.2-2 of lyx is available in the Cygwin distribution CYGWIN CHANGES Re-built with Qt5 and Python 3.6 CHANGES Last upstream BUGFIX release. https://www.lyx.org/announce/2_3_4_2.txt DESCRIPTION LyX is a document processor that encourages an approach to writing based on the structure of your documents (WYSIWYM) and not simply their appearance (WYSIWYG). LyX combines the power and flexibility of TeX/LaTeX with the ease of use of a graphical interface. HOMEPAGE http://www.lyx.org Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Updated: lyx-2.3.4.2-2
released On 27.04.2020 09:27, Marco Atzeri wrote: New test version 2.3.4.2-2 of lyx is available in the Cygwin distribution CYGWIN CHANGES Re-built with Qt5 and Python 3.6 CHANGES Last upstream BUGFIX release. https://www.lyx.org/announce/2_3_4_2.txt DESCRIPTION LyX is a document processor that encourages an approach to writing based on the structure of your documents (WYSIWYM) and not simply their appearance (WYSIWYG). LyX combines the power and flexibility of TeX/LaTeX with the ease of use of a graphical interface. HOMEPAGE http://www.lyx.org Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com .
