Re: make xorg-server a dependency of x11 ports?
On Thu, 21 May 2020, Ken Cunningham wrote: On Wed, 20 May 2020, Ken Cunningham wrote: > /i was imagining just one key port — gtk, or some other always installed > />/required supporting lib — would do the test. / I don't think gtk is remotely close to being an always-required lib for X11 apps. Fred Wright Fill in your fav then, with your extensive x11 experience. If there is no such library, well then, let's move on. I suspect that there is, but that it's provided by the system rather than by a port. New users can segfault, and let them sort it out. It's a litmus test I suppose, to see if they are worthy. Another issue is that an X11 app could be installed purely for remote use over an X11 connection from another machine. In that case, the server wouldn't be needed at all. Again, a warning note would be OK, but not a hard dependency. Fred Wright
Re: make xorg-server a dependency of x11 ports?
On Wed, 20 May 2020, Ken Cunningham wrote: >/i was imagining just one key port — gtk, or some other always installed />/required supporting lib — would do the test. / I don't think gtk is remotely close to being an always-required lib for X11 apps. Fred Wright Fill in your fav then, with your extensive x11 experience. If there is no such library, well then, let's move on. New users can segfault, and let them sort it out. It's a litmus test I suppose, to see if they are worthy. K
Re: make xorg-server a dependency of x11 ports?
On Wed, 20 May 2020, Ryan Schmidt wrote: On May 20, 2020, at 21:09, Fred Wright wrote: Just because XQuartz is "out of date" doesn't mean that it might not be adequate in many cases, and I've found that switching from one X11 to another involves wrestling with some poorly documented configuration stuff, sometimes unsuccessfully. So forcing someone who already has XQuartz (or Apple's X11, for that matter) installed and working to switch to the MacPorts xorg-server could inflict unnecessary pain. XQuartz and xorg-server are the same software, maintained until a few years ago by the same person. He has become unavailable due to other commitments and has stopped updating XQuartz and contributing to MacPorts. Someone else has taken over keeping the MacPorts ports updated. But they are the same software and should require no different configuration. I found my notes on switching. What I'd found, by trial and error (not documentation), is that switching requires using some launchctl commands to switch the startx.plist, and it's necessary to reboot since logging out and logging in is insufficient (in spite of the classification as an "agent" rather than a "daemon"). And that procedure didn't work on the PowerBook, so there I wound up going back to XQuartz just to have a working X11. Apple's X11 only exists on Mac OS X 10.6 and earlier so it's not very interesting to talk about at this point. Well, some of us run old systems for testing. :-) And I believe Apple's X11 was provided at least as late as 10.7 as well. "could not open display" is a pretty normal error for an X11 app to give when it can't find the X11 server. I don't see an entry in our FAQ wiki page for this error. We could add one that tells the user how to install and set up the xorg-server port. That's also the error that one gets when there's a perfectly good X11 server installed but DISPLAY isn't set appropriately, so a distinction needs to be made between those cases. I've also seen a case where a missing DISPLAY results in a segfault from Gtk. macOS sets DISPLAY properly for you, ever since Mac OS X 10.5. So talking about a misconfigured DISPLAY isn't very interesting either; it would take a concerted effort on the user's part to deliberately set a wrong value. I assure you that I hadn't engaged in any "concerted effort" to screw myself when I got burned by this issue. And there was a time when it mattered whether one was launching from xterm or Terminal, though that discrepancy seems to have disappeared for no known reason. The best approach might be simply to have a conditional port note in any X11 app, that checks to see whether *some* X11 server is present, and gives a warning with an installation suggestion if not. What I'm trying to avoid is having to add boilerplate code to hundreds of ports. So I guess that means yet another portgroup to do this. But Sure - doing it in a PortGroup makes sense regardless of what it actually does. even that -- editing hundreds of possibly optionally X11-using portfiles to insert the inclusion of that portgroup only when X11 is actually going to be used -- is a big effort. Yup. And this peripherally relates to the +x11 vs. +quartz issue that shows up all over the place. At one point I started going down the rabbit hole of switching to +quartz as much as possible to minimize X11 dependencies, but that proved to be too much of a nightmare. On Wed, 20 May 2020, Ken Cunningham wrote: i was imagining just one key port — gtk, or some other always installed required supporting lib — would do the test. I don't think gtk is remotely close to being an always-required lib for X11 apps. Fred Wright
Re: make xorg-server a dependency of x11 ports?
> What I'm trying to avoid is having to add boilerplate code to hundreds of > ports. So I guess that means yet another portgroup to do this. But even that > -- editing hundreds of possibly optionally X11-using portfiles to insert the > inclusion of that portgroup only when X11 is actually going to be used -- is > a big effort. i was imagining just one key port — gtk, or some other always installed required supporting lib — would do the test. K
Re: make xorg-server a dependency of x11 ports?
On May 20, 2020, at 21:09, Fred Wright wrote: > On Wed, 20 May 2020, Ryan Schmidt wrote: >> On May 20, 2020, at 08:30, Ken Cunningham wrote: >> >>> Should xorg-server should be made a dependency of some key x11 component, >>> so that when people install an x11 application, xorg-server installs and it >>> actually works for them “out-of-the-box”. >>> >>> For example, CherryTree is apparently a very popular gtk application, and >>> there was some pressure for the past few years for a Mac version. I just >>> stumbled across it recently — took about 15 minutes to write the Portfile >>> (and a couple of minor edits after to get it completely right :>). >>> >>> But when people try "sudo port -v install cherrytree” it delivers a broken >>> installation due to no xorg-server (see below). >>> >>> It’s one more step to go back and explain how to install the server, but >>> really, as XQuartz.app is really out of date now, and MacOS no longer comes >>> with any X11 window server, I think we could just make our xorg-server a >>> dependency of some key part and have it installed automatically. >>> >>> Otherwise, it seems like just one more needless headache for people that >>> they should not have to worry about, and we’re all about making this work >>> “out of the box” for people, right? — or we should be, if we want to >>> recruit keep users. > > Just because XQuartz is "out of date" doesn't mean that it might not be > adequate in many cases, and I've found that switching from one X11 to another > involves wrestling with some poorly documented configuration stuff, sometimes > unsuccessfully. So forcing someone who already has XQuartz (or Apple's X11, > for that matter) installed and working to switch to the MacPorts xorg-server > could inflict unnecessary pain. XQuartz and xorg-server are the same software, maintained until a few years ago by the same person. He has become unavailable due to other commitments and has stopped updating XQuartz and contributing to MacPorts. Someone else has taken over keeping the MacPorts ports updated. But they are the same software and should require no different configuration. Apple's X11 only exists on Mac OS X 10.6 and earlier so it's not very interesting to talk about at this point. >> "could not open display" is a pretty normal error for an X11 app to give >> when it can't find the X11 server. I don't see an entry in our FAQ wiki page >> for this error. We could add one that tells the user how to install and set >> up the xorg-server port. > > That's also the error that one gets when there's a perfectly good X11 server > installed but DISPLAY isn't set appropriately, so a distinction needs to be > made between those cases. I've also seen a case where a missing DISPLAY > results in a segfault from Gtk. macOS sets DISPLAY properly for you, ever since Mac OS X 10.5. So talking about a misconfigured DISPLAY isn't very interesting either; it would take a concerted effort on the user's part to deliberately set a wrong value. > The best approach might be simply to have a conditional port note in any X11 > app, that checks to see whether *some* X11 server is present, and gives a > warning with an installation suggestion if not. What I'm trying to avoid is having to add boilerplate code to hundreds of ports. So I guess that means yet another portgroup to do this. But even that -- editing hundreds of possibly optionally X11-using portfiles to insert the inclusion of that portgroup only when X11 is actually going to be used -- is a big effort.
Re: make xorg-server a dependency of x11 ports?
On Wed, 20 May 2020, Ryan Schmidt wrote: On May 20, 2020, at 08:30, Ken Cunningham wrote: Should xorg-server should be made a dependency of some key x11 component, so that when people install an x11 application, xorg-server installs and it actually works for them “out-of-the-box”. For example, CherryTree is apparently a very popular gtk application, and there was some pressure for the past few years for a Mac version. I just stumbled across it recently — took about 15 minutes to write the Portfile (and a couple of minor edits after to get it completely right :>). But when people try "sudo port -v install cherrytree” it delivers a broken installation due to no xorg-server (see below). It’s one more step to go back and explain how to install the server, but really, as XQuartz.app is really out of date now, and MacOS no longer comes with any X11 window server, I think we could just make our xorg-server a dependency of some key part and have it installed automatically. Otherwise, it seems like just one more needless headache for people that they should not have to worry about, and we’re all about making this work “out of the box” for people, right? — or we should be, if we want to recruit keep users. Just because XQuartz is "out of date" doesn't mean that it might not be adequate in many cases, and I've found that switching from one X11 to another involves wrestling with some poorly documented configuration stuff, sometimes unsuccessfully. So forcing someone who already has XQuartz (or Apple's X11, for that matter) installed and working to switch to the MacPorts xorg-server could inflict unnecessary pain. Ken — example of cryptic error without xorg-server installed, gives people no clue what is wrong. = So I've tried to run this using port myself and get the following error: phillips321@Mac13:~$ cherrytree /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gtk-2.0/gtk/__init__.py:57: GtkWarning: could not open display "could not open display" is a pretty normal error for an X11 app to give when it can't find the X11 server. I don't see an entry in our FAQ wiki page for this error. We could add one that tells the user how to install and set up the xorg-server port. That's also the error that one gets when there's a perfectly good X11 server installed but DISPLAY isn't set appropriately, so a distinction needs to be made between those cases. I've also seen a case where a missing DISPLAY results in a segfault from Gtk. The best approach might be simply to have a conditional port note in any X11 app, that checks to see whether *some* X11 server is present, and gives a warning with an installation suggestion if not. Fred Wright
Re: make xorg-server a dependency of x11 ports?
On May 20, 2020, at 08:30, Ken Cunningham wrote: > Should xorg-server should be made a dependency of some key x11 component, so > that when people install an x11 application, xorg-server installs and it > actually works for them “out-of-the-box”. > > For example, CherryTree is apparently a very popular gtk application, and > there was some pressure for the past few years for a Mac version. I just > stumbled across it recently — took about 15 minutes to write the Portfile > (and a couple of minor edits after to get it completely right :>). > > But when people try "sudo port -v install cherrytree” it delivers a broken > installation due to no xorg-server (see below). > > It’s one more step to go back and explain how to install the server, but > really, as XQuartz.app is really out of date now, and MacOS no longer comes > with any X11 window server, I think we could just make our xorg-server a > dependency of some key part and have it installed automatically. > > Otherwise, it seems like just one more needless headache for people that they > should not have to worry about, and we’re all about making this work “out of > the box” for people, right? — or we should be, if we want to recruit keep > users. > > Ken > > — example of cryptic error without xorg-server installed, gives people no > clue what is wrong. > > > = > So I've tried to run this using port myself and get the following error: > > phillips321@Mac13:~$ cherrytree > /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gtk-2.0/gtk/__init__.py:57: > GtkWarning: could not open display "could not open display" is a pretty normal error for an X11 app to give when it can't find the X11 server. I don't see an entry in our FAQ wiki page for this error. We could add one that tells the user how to install and set up the xorg-server port.
Re: make xorg-server a dependency of x11 ports?
> On 20 May 2020, at 3:55 pm, Rainer Müller wrote: > > On 20/05/2020 15.30, Ken Cunningham wrote: >> Should xorg-server should be made a dependency of some key x11 component, so >> that when people install an x11 application, xorg-server installs and it >> actually works for them “out-of-the-box”. > > I doubt even with the dependency it will not work "out of the box" as > expected, > because installing xorg-server requires a logout/login cycle to get the > updated > launchd environment as documented in the port notes of xinit. Hiding the > installation of the X server may cause people to also overlook this essential > step. Yes, that is required, but port notes will be printed at the end of the installation explaining to the user they need to do this. Hopefully at least some users will see this an do this step. It is stil, I would say, better than just failing later on with a much more cryptic error message, as Ken points out, when the users tries to start the application. Chris > > Rainer smime.p7s Description: S/MIME cryptographic signature
Re: make xorg-server a dependency of x11 ports?
On 20/05/2020 15.30, Ken Cunningham wrote: > Should xorg-server should be made a dependency of some key x11 component, so > that when people install an x11 application, xorg-server installs and it > actually works for them “out-of-the-box”. I doubt even with the dependency it will not work "out of the box" as expected, because installing xorg-server requires a logout/login cycle to get the updated launchd environment as documented in the port notes of xinit. Hiding the installation of the X server may cause people to also overlook this essential step. Rainer
Re: make xorg-server a dependency of x11 ports?
Hi,
Personally, I would say yes, this makes sense given the current state of
XQuartz.app
cheers Chris
> On 20 May 2020, at 2:30 pm, Ken Cunningham
> wrote:
>
> Should xorg-server should be made a dependency of some key x11 component, so
> that when people install an x11 application, xorg-server installs and it
> actually works for them “out-of-the-box”.
>
> For example, CherryTree is apparently a very popular gtk application, and
> there was some pressure for the past few years for a Mac version. I just
> stumbled across it recently — took about 15 minutes to write the Portfile
> (and a couple of minor edits after to get it completely right :>).
>
> But when people try "sudo port -v install cherrytree” it delivers a broken
> installation due to no xorg-server (see below).
>
> It’s one more step to go back and explain how to install the server, but
> really, as XQuartz.app is really out of date now, and MacOS no longer comes
> with any X11 window server, I think we could just make our xorg-server a
> dependency of some key part and have it installed automatically.
>
> Otherwise, it seems like just one more needless headache for people that they
> should not have to worry about, and we’re all about making this work “out of
> the box” for people, right? — or we should be, if we want to recruit keep
> users.
>
> Ken
>
> — example of cryptic error without xorg-server installed, gives people no
> clue what is wrong.
>
>
> =
> So I've tried to run this using port myself and get the following error:
>
> phillips321@Mac13:~$ cherrytree
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gtk-2.0/gtk/__init__.py:57:
> GtkWarning: could not open display
> warnings.warn(str(e), _gtk.Warning)
> dbus[77158]: Dynamic session lookup supported but failed: launchd did not
> provide a socket path, verify that org.freedesktop.dbus-session.plist is
> loaded!
> dbus fail, maybe a firewall problem, centralized instances disabled
> libc.prctl not available, the process name will be python and not cherrytree
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/share/cherrytree/modules/core.py:69:
> Warning: invalid (NULL) pointer instance
> self.window = gtk.Window()
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/share/cherrytree/modules/core.py:69:
> Warning: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)'
> failed
> self.window = gtk.Window()
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/share/cherrytree/modules/clipboard.py:93:
> GtkWarning: gtk_clipboard_get_for_display: assertion 'display != NULL' failed
> self.clipboard = gtk.clipboard_get()
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/share/cherrytree/modules/core.py:114:
> Warning: invalid (NULL) pointer instance
> vbox_main.pack_start(self.ui.get_widget("/MenuBar"), False, False)
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/share/cherrytree/modules/core.py:114:
> Warning: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)'
> failed
> vbox_main.pack_start(self.ui.get_widget("/MenuBar"), False, False)
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/share/cherrytree/modules/core.py:114:
> GtkWarning: gtk_settings_get_for_screen: assertion 'GDK_IS_SCREEN (screen)'
> failed
> vbox_main.pack_start(self.ui.get_widget("/MenuBar"), False, False)
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/share/cherrytree/modules/core.py:114:
> Warning: g_object_get: assertion 'G_IS_OBJECT (object)' failed
> vbox_main.pack_start(self.ui.get_widget("/MenuBar"), False, False)
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/share/cherrytree/modules/core.py:114:
> Warning: value "TRUE" of type 'gboolean' is invalid or out of range for
> property 'visible' of type 'gboolean'
> vbox_main.pack_start(self.ui.get_widget("/MenuBar"), False, False)
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/share/cherrytree/modules/core.py:114:
> GtkWarning: gdk_screen_get_display: assertion 'GDK_IS_SCREEN (screen)' failed
> vbox_main.pack_start(self.ui.get_widget("/MenuBar"), False, False)
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/share/cherrytree/modules/core.py:114:
> Warning: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
> vbox_main.pack_start(self.ui.get_widget("/MenuBar"), False, False)
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/share/cherrytree/modules/core.py:119:
> GtkWarning: gtk_settings_get_for_screen: assertion 'GDK_IS_SCREEN (screen)'
> failed
> self.scrolledwindow_tree = gtk.ScrolledWindow()
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/share/cherrytree/modules/core.py:121:
> GtkWarning: gtk_settings_get_for_screen: assertion 'GDK_IS_SCREEN (screen)'
> failed
> self.scrolledwindow_text = gtk.ScrolledWindow()
>
