search

dnschneid / crouton

Chromium OS Universal Chroot Environment
https://goo.gl/fd3zc?si=1
BSD 3-Clause "New" or "Revised" License
8.56k stars 1.24k forks source link

xiwi opening window too soon? #1768

Closed mark-hahn closed 2 years ago

mark-hahn commented 9 years ago

In another issue I mentioned "the black screen of death". I have seen this often when I try to open a xiwi app, the app has a problem, a window opens, and the broken app doesn't put anything in the window. I just realized now what is going on in general and I think maybe crouton (xiwi) could be enhanced to make this happen less.

I usually run an editor with the command xiwi atom. I just issued the command xiwi atom --help by accident. The app did nothing but print out help in the console and quit. But a black window opened.

Is there any way that the actual opening of the window could be "lazy" and not open until the app tries to put something in? Or maybe, just see if the app is actually running?

Sorry if this is a stupid question.

tedm commented 9 years ago

@mark-hahn that's how a Windows app would work, and you did get the help text, so I'm not sure this is a xiwi issue.

But the issue you pointed out a couple of days ago where the black screen is there as it thinks something may be running, may be an issue, as the user has no feedback of why the program isn't displaying. Since you're running a lot of graphical apps, it seems, you might want to install a DE like lxde or xfce, and you can still run a terminal or multiple terminals.

Also, for debugging, I like to keep a watch of what spits out in the crosh window where the enter-chroot or start* command was run. If you start with -b or close that terminal window, you will miss many status/error messages of your session, and may be unable to unmount cleanly from a new crosh/shell.

Also, xiwi can run things from outside the chroot, and bring a window and chroot up at the same time. Look for the -Xmethods or -X xiwi parameters that will just open your chroot with xiwi and/or xorg, if that switching method is still working. @DennisLfromGA would know, as I think he wrote part of that.

mark-hahn commented 9 years ago

so I'm not sure this is a xiwi issue.

I was trying to say it would be an enhancement, not that it is an issue. Believe it or not, I'm not bitching about anything this time. (grin) I know my workflow is not optimal and I can follow your advice, which I will, but it would be nice if the xiwi window didn't show until it knew something was going to be displayed.

that's how a Windows app would work

And a linux app. I just tried xterm --help in the unity desktop and it did what I would expect. It showed help and no window appeared. In crouton, xiwi xterm --help showed a black window. It would be a nice enhancement if it didn't.

Now I know that xiwi xterm --help makes no sense and is a mistake to type. I'm just using that as an experiment to better understand how one might make the black windows appear less often. It is just a UX issue. Seeing black windows makes one think it is a xiwi problem. I'm sure @dnschneid winces when he hears "black window of death".

Since you're running a lot of graphical apps, it seems, you might want to install a DE

Actually I'm not running a lot of gui. I just run one editor a lot and a couple others infrequently. I spend half my time in shells. To me shells and one GUI editor is an ideal workflow.

Also, I love not having a desktop. I can't tell you how liberating it is. Dragging icons around, finding ways to accomplish something, looking through menus, having things happen magically in the background, etc. etc., are all pains I didn't know I was suffering. Everyone should try it.

If you start with -b or close that terminal window

When I didn't run in the background I got screens of errors on each xiwi startup which annoyed me. I wouldn't notice any errors coming from my app anyway. Also I had to be very careful to not accidentally close the terminal and blow away my editor with changes unsaved.

Look for the -Xmethods or -X xiwi parameters

That sounds cool. I didn't know about this. I'll try it out right away.

P.S. When I get all the glitches out of running without a desktop I'd like to try my hand at writing a wiki page about how to do it. I wouldn't have even known it was possible if @dnschneid hadn't mentioned it in a throw-away comment.

dnschneid commented 9 years ago

We could definitely delay creating the browser window until after a window is created on the X11 side of things. The trick is knowing when to give up and destroy the X server: currently crouton doesn't know the difference between xterm --help immediately exiting, and gvim forking off the GUI thread and exiting. I don't have a good solution for that at the moment, which is why the user has to close the screen when appropriate to kill off the X server if the application forked and when no windows are left.

mark-hahn commented 9 years ago

We could definitely delay creating the browser window until after a window is created on the X11 side of things.

crouton doesn't know the difference between xterm --help immediately exiting, and gvim forking

If --help (or a broken app) doesn't even begin to create an X11 window and no browser window has been created then why would you need to know when the process exited? Are you saying xiwi would be waiting forever for the X11 window? If so I would think a long timeout would work.

I hope I'm not wasting everyone's time on this long discussion.

dnschneid commented 9 years ago

xiwi doesn't have any insight into what a program's intentions are. They may or may not create an x11 window, and may or may not spontaneously fork and have the other process may or may not create an x11 window. It may even fork a daemon process that never creates an X11 window, and xiwi can't know.

There's also software that for various reasons takes forever to launch, so you can't necessarily time out and give up without risking exiting prematurely. Also, as long as you're waiting, the X server will show up in the extension even if you haven't displayed anything yet.

Really, it's the halting problem :)

On the other hand, we have the -f parameter to xiwi that is there to handle the cases where xiwi's heuristics fail, so a timeout that applies only when the "forked process" detection triggers may make sense.

tedm commented 9 years ago

@mark-hahn with a lightweight DE and something like terminator, you can have the best of both worlds, including a root terminal for the times when you really need it. Check it out. image

mark-hahn commented 9 years ago

I keep learning new things from you. I'll check it out.

On Tue, May 19, 2015 at 10:31 PM, tedm notifications@github.com wrote:

@mark-hahn https://github.com/mark-hahn with a lightweight DE and something like terminator, you can have the best of both worlds, including a root terminal for the times when you really need it. Check it out. [image: image] https://cloud.githubusercontent.com/assets/3884283/7719546/d1a1947e-fe76-11e4-9a0e-949dfe4ebee4.png

— Reply to this email directly or view it on GitHub https://github.com/dnschneid/crouton/issues/1768#issuecomment-103765564.

mark-hahn commented 9 years ago

While trying to learn desktop options I ran into openbox. Is openbox technically the equivalent of the chromebook window manager? If so then running it in crouton would make no sense, right? I have a x86 pc box than I'm running unity on right now and after getting used to running apps in xiwi windows without a desktop I thought maybe replacing unity with openbox would give me a similar environment.