Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: to X, or not to X...
38 views
Skip to first unread message
Ivan Shmakov
Feb 24, 2013, 6:10:22 AM2/24/13
to
>>>>> crankypuss <noe...@noemail.invalid> writes:
[Cross-posting to news:comp.windows.x, for this discussion is
hardly specific to its GNU/Linux implementations.]
> Suppose that, instead of requiring that an X Server always be running
> in order to support fullscreen applications, it was optional. That
> is to say, what if there was a fullscreen character-mode support
> layer that would allow pixel-mode windows to be created as part of
> its ongoing character-mode support?
As in: Wayland?
[...]
> So you few who inhabit this usenet group (golly it isn't a web forum
> with smiley-face icons),
It depends on the software used. For instance, Gnus provides a
setting to substitute smiley-face icons for ASCII smileys.
OTOH, one'd hardly encounter any icons on Web fora when using
Lynx, as I do.
> what do you think about going back to basics in a way that doesn't
> require all the X applications and all the applications that are
> built on top of the various libraries to make X applications easier
> to write be thrown away?
I think that if I can't run it over SSH, it doesn't worth the
effort. (Why, I now have four machines running continuously in
my bedroom's network.) Naturally, both X and "text terminal"
applications are capable of that.
The inability of the applications to take certain keys or their
combinations for their own uses away from an unsuspecting user
(as in: me) looks like an advantage on its own. At least after
the logic behind such behavior is revealed.
But I do agree that the situation with "X libraries" (or,
rather, GUI toolkits) is somewhat a bitter one. My current
preference (though I hardly do any serious GUI programming) is
Tk, but even it has some issues.
--
FSF associate member #7257 np. Know Why the Nightingale Sings -- Nightwish
[Cross-posting to news:comp.windows.x, for this discussion is
hardly specific to its GNU/Linux implementations.]
> Suppose that, instead of requiring that an X Server always be running
> in order to support fullscreen applications, it was optional. That
> is to say, what if there was a fullscreen character-mode support
> layer that would allow pixel-mode windows to be created as part of
> its ongoing character-mode support?
As in: Wayland?
[...]
> So you few who inhabit this usenet group (golly it isn't a web forum
> with smiley-face icons),
It depends on the software used. For instance, Gnus provides a
setting to substitute smiley-face icons for ASCII smileys.
OTOH, one'd hardly encounter any icons on Web fora when using
Lynx, as I do.
> what do you think about going back to basics in a way that doesn't
> require all the X applications and all the applications that are
> built on top of the various libraries to make X applications easier
> to write be thrown away?
I think that if I can't run it over SSH, it doesn't worth the
effort. (Why, I now have four machines running continuously in
my bedroom's network.) Naturally, both X and "text terminal"
applications are capable of that.
The inability of the applications to take certain keys or their
combinations for their own uses away from an unsuspecting user
(as in: me) looks like an advantage on its own. At least after
the logic behind such behavior is revealed.
But I do agree that the situation with "X libraries" (or,
rather, GUI toolkits) is somewhat a bitter one. My current
preference (though I hardly do any serious GUI programming) is
Tk, but even it has some issues.
--
FSF associate member #7257 np. Know Why the Nightingale Sings -- Nightwish
crankypuss
Feb 24, 2013, 8:06:05 AM2/24/13
to
On 02/24/2013 04:10 AM, Ivan Shmakov wrote:
>>>>>> crankypuss <noe...@noemail.invalid> writes:
>
> [Cross-posting to news:comp.windows.x, for this discussion is
> hardly specific to its GNU/Linux implementations.]
>
> > Suppose that, instead of requiring that an X Server always be running
> > in order to support fullscreen applications, it was optional. That
> > is to say, what if there was a fullscreen character-mode support
> > layer that would allow pixel-mode windows to be created as part of
> > its ongoing character-mode support?
>
> As in: Wayland?
I'm not familiar with Wayland other than having gotten the idea that it
>>>>>> crankypuss <noe...@noemail.invalid> writes:
>
> [Cross-posting to news:comp.windows.x, for this discussion is
> hardly specific to its GNU/Linux implementations.]
>
> > Suppose that, instead of requiring that an X Server always be running
> > in order to support fullscreen applications, it was optional. That
> > is to say, what if there was a fullscreen character-mode support
> > layer that would allow pixel-mode windows to be created as part of
> > its ongoing character-mode support?
>
> As in: Wayland?
is a replacement for x11 that is under development and that people seem
to disapprove of, am I in the process of reinventing their wheel?
> > what do you think about going back to basics in a way that doesn't
> > require all the X applications and all the applications that are
> > built on top of the various libraries to make X applications easier
> > to write be thrown away?
>
> I think that if I can't run it over SSH, it doesn't worth the
> effort. (Why, I now have four machines running continuously in
> my bedroom's network.) Naturally, both X and "text terminal"
> applications are capable of that.
but that seems (to me at least) to be something of an application issue.
On a conceptual basis any subroutine can be called through a
socket-like connection as long as the amount of data transferred and the
latency involved do not create insurmountable performance problems; the
main issue involved in controlling headless servers (imo) really amounts
to the security of the connection and the availability of suitable
software on both sides. I don't see it as problematic.
> The inability of the applications to take certain keys or their
> combinations for their own uses away from an unsuspecting user
> (as in: me) looks like an advantage on its own. At least after
> the logic behind such behavior is revealed.
the "operating system" and can be used at any time to escape into a
known and trusted environment. Beyond that, applications should (imo)
be able to use whatever they please, keeping in mind that "applications"
may consist of many levels that set up increasingly specific conventions
for the user environments they create.
> But I do agree that the situation with "X libraries" (or,
> rather, GUI toolkits) is somewhat a bitter one. My current
> preference (though I hardly do any serious GUI programming) is
> Tk, but even it has some issues.
>
started (or whether X is even installed), I've been using an abstraction
based on ncurses and relaunching into a terminal emulator when
necessary. It is not what I consider an acceptable solution.
Aragorn
Feb 24, 2013, 8:31:57 AM2/24/13
to
On Sunday 24 February 2013 14:06, crankypuss conveyed the following to
comp.os.linux.x...
Latency is generally only a problem in this context when the remote user
wants to have all the eye candy available over the network connection -
think "remote desktop". Pure character mode implementations are
generally not that bandwidth-hungry. That's another argument in favor
of character mode. :-)
>> The inability of the applications to take certain keys or their
>> combinations for their own uses away from an unsuspecting user
>> (as in: me) looks like an advantage on its own. At least after
>> the logic behind such behavior is revealed.
>
> There should (imo) be *one* inviolate key combination that is owned by
> the "operating system" and can be used at any time to escape into a
> known and trusted environment. Beyond that, applications should (imo)
> be able to use whatever they please, keeping in mind that
> "applications" may consist of many levels that set up increasingly
> specific conventions for the user environments they create.
Well, the Linux kernel does have the "magic SysRq" keys to let the
operator at the local console interact with the system directly - but
on-screen feedback of this interaction is of course restricted to
character mode, as the X server doesn't have any way of trapping said
output - but other than that, everything is pretty much defined at the
application layer.
>> But I do agree that the situation with "X libraries" (or,
>> rather, GUI toolkits) is somewhat a bitter one. My current
>> preference (though I hardly do any serious GUI programming) is
>> Tk, but even it has some issues.
>
> Since I want my applications to run whether or not an X server has
> been started (or whether X is even installed), I've been using an
> abstraction based on ncurses and relaunching into a terminal emulator
> when necessary. It is not what I consider an acceptable solution.
One of the (many) things I find interesting about a UNIX-style operating
system is that the applications are typically written with separation of
function and form, which on account of X Window System applications
typically means that they are only GUI front-ends to the same tools as
one would use from a command line prompt - office suite applications
such as LibreOffice et al excluded, of course.
In earlier RedHat distributions and derivatives (such as early
Mandrake), you had a number of tools for system administration which ran
with an ncurses interface when invoked in a pure character mode
terminal, or with an xlib interface when invoked from within a GUI -
including starting them from a terminal emulator window in a GUI
environment.
The version of GNU emacs which I have here on my system behaves
similarly. If I start it in a pure character mode virtual console,
it'll have the conventional emacs user interface, and if I start it from
a terminal emulator window or a shortcut icon or menu entry in a GUI
environment on top of X, then it'll have a graphical user interface.
Not quite the same interface as with xemacs - as that's a different
thing - but you still do get some of the advantages of the GUI, such as
a more prominent syntax highlighting with different fonts and font
attributes - e.g. italicized for comments - et al.
The main problem, as I see it, is the biological unit between the
keyboard and the chair, and that which said biological unit has adopted
as "the norm", with a little help of other biological units in which
typically large amounts of the intelligent logic either have become
defunct or entered a power savings mode from which they continuously
fail to recover. <grin>
--
= Aragorn =
(registered GNU/Linux user #223157)
comp.os.linux.x...
wants to have all the eye candy available over the network connection -
think "remote desktop". Pure character mode implementations are
generally not that bandwidth-hungry. That's another argument in favor
of character mode. :-)
>> The inability of the applications to take certain keys or their
>> combinations for their own uses away from an unsuspecting user
>> (as in: me) looks like an advantage on its own. At least after
>> the logic behind such behavior is revealed.
>
> There should (imo) be *one* inviolate key combination that is owned by
> the "operating system" and can be used at any time to escape into a
> known and trusted environment. Beyond that, applications should (imo)
> be able to use whatever they please, keeping in mind that
> "applications" may consist of many levels that set up increasingly
> specific conventions for the user environments they create.
operator at the local console interact with the system directly - but
on-screen feedback of this interaction is of course restricted to
character mode, as the X server doesn't have any way of trapping said
output - but other than that, everything is pretty much defined at the
application layer.
>> But I do agree that the situation with "X libraries" (or,
>> rather, GUI toolkits) is somewhat a bitter one. My current
>> preference (though I hardly do any serious GUI programming) is
>> Tk, but even it has some issues.
>
> Since I want my applications to run whether or not an X server has
> been started (or whether X is even installed), I've been using an
> abstraction based on ncurses and relaunching into a terminal emulator
> when necessary. It is not what I consider an acceptable solution.
system is that the applications are typically written with separation of
function and form, which on account of X Window System applications
typically means that they are only GUI front-ends to the same tools as
one would use from a command line prompt - office suite applications
such as LibreOffice et al excluded, of course.
In earlier RedHat distributions and derivatives (such as early
Mandrake), you had a number of tools for system administration which ran
with an ncurses interface when invoked in a pure character mode
terminal, or with an xlib interface when invoked from within a GUI -
including starting them from a terminal emulator window in a GUI
environment.
The version of GNU emacs which I have here on my system behaves
similarly. If I start it in a pure character mode virtual console,
it'll have the conventional emacs user interface, and if I start it from
a terminal emulator window or a shortcut icon or menu entry in a GUI
environment on top of X, then it'll have a graphical user interface.
Not quite the same interface as with xemacs - as that's a different
thing - but you still do get some of the advantages of the GUI, such as
a more prominent syntax highlighting with different fonts and font
attributes - e.g. italicized for comments - et al.
The main problem, as I see it, is the biological unit between the
keyboard and the chair, and that which said biological unit has adopted
as "the norm", with a little help of other biological units in which
typically large amounts of the intelligent logic either have become
defunct or entered a power savings mode from which they continuously
fail to recover. <grin>
--
= Aragorn =
(registered GNU/Linux user #223157)
Ivan Shmakov
Feb 24, 2013, 9:36:31 AM2/24/13
to
>>>>> crankypuss <noe...@noemail.invalid> writes:
>>>>> On 02/24/2013 04:10 AM, Ivan Shmakov wrote:
[...]
>>>>> On 02/24/2013 04:10 AM, Ivan Shmakov wrote:
>> I think that if I can't run it over SSH, it doesn't worth the
>> effort. (Why, I now have four machines running continuously in my
>> bedroom's network.) Naturally, both X and "text terminal"
>> applications are capable of that.
> There seems to be a definite need to remotely control headless
> servers,
ability to have an application installed and configured at one
place (host), but to be available at another. It may be
unreasonable to install such an application just everywhere, for
it may require:
* a different OS or distribution that's needed at the place it's
to be used; (due to a "must have" application there, for
instance);
* too much effort to synchronize the working state of such an
application between hosts (as in: reading netnews from several
places; won't it become necessary to keep .newsrc in sync?);
* more resources that are physically available at that place (as
in: modelling and computations software may require a better
CPU's and larger RAM that's available at the machine sitting
on one's table.)
[...]
> the main issue involved in controlling headless servers (imo) really
> amounts to the security of the connection and the availability of
> suitable software on both sides. I don't see it as problematic.
that needs to be available "on the other side" is SSH. Which is
a huge win.
Also to note is that in the GNU world, the majority of "server"
applications may be configured via either a text editor, or a
command-line tool (or both.) Both of which are easily
"SSH-friendly" means.
>> The inability of the applications to take certain keys or their
>> combinations for their own uses away from an unsuspecting user (as
>> in: me) looks like an advantage on its own. At least after the
>> logic behind such behavior is revealed.
> There should (imo) be *one* inviolate key combination that is owned
> by the "operating system" and can be used at any time to escape into
> a known and trusted environment. Beyond that, applications should
> (imo) be able to use whatever they please, keeping in mind that
> "applications" may consist of many levels that set up increasingly
> specific conventions for the user environments they create.
Say, my preference is that Alt-F4 brings to me the 4'th virtual
terminal. Now, an application developer decided that the "Quit"
command is to be bound to such a sequence. Given the system
suggested, how do you prevent him or her from doing just that?
Conceptually, it's right, indeed, but my preference is that some
of the aforementioned "levels" reside in a place which can only
be altered using a privileged user account ("root".)
From this viewpoint, the idea of using HTML forms for a user
interface has its merit, BTW: with a single application directly
interfacing the user, the chances of the "payload" application
getting "out of hand" are lower than ever. (Somehow, I believe
that NeWS advocated essentially the same approach.)
[...]
> Since I want my applications to run whether or not an X server has
> been started (or whether X is even installed), I've been using an
> abstraction based on ncurses and relaunching into a terminal emulator
> when necessary. It is not what I consider an acceptable solution.
FWIW, I start my applications under GNU Screen, and then detach
and re-attach them to the terminals as I see fit. This way, I
may go from a text VT to an XTerm window to a remote SSH session
(and then back again) almost instantly, without having to
re-launch my applications at any time.
crankypuss
Feb 24, 2013, 1:16:31 PM2/24/13
to
please see my second reply to your initial post in this thread.
crankypuss
Feb 24, 2013, 1:43:19 PM2/24/13
to
On 02/24/2013 04:10 AM, Ivan Shmakov wrote:
>>>>>> crankypuss <noe...@noemail.invalid> writes:
>
> [Cross-posting to news:comp.windows.x, for this discussion is
> hardly specific to its GNU/Linux implementations.]
I'm unfamiliar with the purview of comp.windows.x but I am assuming that
>
> [Cross-posting to news:comp.windows.x, for this discussion is
> hardly specific to its GNU/Linux implementations.]
it is for discussion of X Windows, rather than MS-Windows.
After reading your later response, and giving the matter some additional
thought because of the issues you brought up, I think that it may very
well be a linux-specific topic rather than anything really relevant to X
Windows.
I am not suggesting that X be modified, removed, or that anything at all
be done to X. What I am suggesting is something quite different from
that, which seems to apply specifically to linux (although it might or
might not equally apply to Unix).
There is much talk about the linux operating system but there truly is
no such thing; there is a linux kernel, there is a set of core commands
which have been inspired by their Unix counterparts, there is a set of
linux filesystems, and there are many "linux distributions" that include
the aforementioned plus numerous applications, but linux is more of a
toolkit than an "operating system".
And I am not really suggesting here that *any* of that be changed.
What I am suggesting is basically the interposition of a thin-client
layer between the hardware and the X Server, which would support a
character-mode interface to the pixel-capable screen for application
use, and, within that screen, allocate windows which could be used by X.
This thin-client layer could also provide access to the server operating
within the same physical housing, such things as killing runaway
processes or even configuration functions.
And it could do it *without* the need to translate application output
into arcane character sequences defined by "terminal" hardware obsoleted
decades ago and then deciphering it in order to perform simple display
functions.
Ivan Shmakov
Feb 24, 2013, 2:43:36 PM2/24/13
to
>>>>> crankypuss <noe...@noemail.invalid> writes:
>>>>> On 02/24/2013 04:10 AM, Ivan Shmakov wrote:
>> [Cross-posting to news:comp.windows.x, for this discussion is hardly
>> specific to its GNU/Linux implementations.]
> I'm unfamiliar with the purview of comp.windows.x but I am assuming
> that it is for discussion of X Windows,
It's "X window." No trailing "s".
>>>>> On 02/24/2013 04:10 AM, Ivan Shmakov wrote:
>> [Cross-posting to news:comp.windows.x, for this discussion is hardly
>> specific to its GNU/Linux implementations.]
> I'm unfamiliar with the purview of comp.windows.x but I am assuming
> that it is for discussion of X Windows,
> rather than MS-Windows.
LIST NEWSGROUPS reads:
comp.windows.misc Various issues about windowing systems.
...
comp.windows.x Discussion about the X Window System.
> After reading your later response, and giving the matter some
> additional thought because of the issues you brought up, I think that
> it may very well be a linux-specific topic rather than anything
> really relevant to X Windows.
relevant to GNU/Linux, either. Perhaps news:comp.terminals
would be a better fit.
[...]
> What I am suggesting is basically the interposition of a thin-client
> layer between the hardware and the X Server, which would support a
> character-mode interface to the pixel-capable screen for application
> use, and, within that screen, allocate windows which could be used by
> X.
> This thin-client layer could also provide access to the server
> operating within the same physical housing, such things as killing
> runaway processes or even configuration functions.
utilities for these tasks? (As it's currently done.)
> And it could do it *without* the need to translate application output
> into arcane character sequences defined by "terminal" hardware
> obsoleted decades ago and then deciphering it in order to perform
> simple display functions.
interface it, there /is/ a choice. The two may communicate via
series of "function calls" (which may require that the subsystem
is really just a library, running in the very same address space
as the application itself.) Or, the two may communicate by
passing around "messages" (which are, for the most part, memory
buffers annotated with length.) Or, there may be a stream,
which is either composed of "octets", or "ASCII codes." (Which
is a kind of "subset" of an octet stream. Then, either stream
may carry serialized "messages", too, but it isn't necessary.)
As it is, AIUI, X uses an octet stream (and "messages" on top of
that), while the text terminal interface uses an "ASCII code"
stream.
The crux of the things, however, is that there /must/ be an
encoding. (And once the goal is set to provide a way to run the
application over a network connection, this encoding should be
"compatible" with octet streams.)
Above, you show your dissatisfaction of having to "translate
application output into arcane character sequences ..." But the
truth is that, one way or another, the machine only understands
numbers (and octet streams are only capable of delivering
octets.) So, irrespective of the goals, the application would
/have/ to describe its intent in numbers.
For instance, there's /no way/ for application to command "set
the cursor at 3, 7": not until there's defined a some
combination of numbers for this command (like: 13 3 7.) So, the
only real issue you're having is that you dislike the particular
set of numbers set for that action (as in: 27 91 51 59 55 72.)
Which doesn't seem all that reasonable.
It's entirely the same for the keyboard (and pointer) input:
there's a particular encoding to choose. To my mind, ASCII is
quite a sensible choice. I understand that the "classic" PC
keyboards offer three (NB!) more "scan-code" encodings to choose
from (I don't know if the USB keyboards allow for either, or
all, of them, or provide yet another one), but would this really
be a sensible choice to use a particular piece of hardware as a
"reference" for such a protocol? Wouldn't we then need to use
an emulation once we move to some different hardware?
Also, you say "... defined by 'terminal' hardware obsoleted
decades ago." Yet again, the truth is, whatever hardware one'd
choose to model the interface after is going to be "obsoleted
decades ago" a few, well, decades from now. Wouldn't that mean
that every single application created for that particular
interface would have to be abandoned, and the whole decades-long
effort to be started from scratch?
Aragorn
Feb 24, 2013, 4:45:23 PM2/24/13
to
On Sunday 24 February 2013 20:43, Ivan Shmakov conveyed the following to
comp.os.linux.x...
> crankypuss <noe...@noemail.invalid> writes:
>
>> I'm unfamiliar with the purview of comp.windows.x but I am assuming
>> that it is for discussion of X Windows,
>
> It's "X window." No trailing "s".
I already meant to comment on that myself, but given that when I say
such things, I am often found to be a pedantic asshole, I chose not to
say anything this time. :p
On the other hand, I read a nice quote about this in my fortune database
the other day - I can't remember who exactly said it - which went
something like this...:
"You can call it the X Window System. You can call it X11. You may
even call it just plain X. But call it X-Windows and somebody's
going to flame you over it. And you will have deserved it."
;-)
P.S.: Ivan, the way your newsreader accentuates the attributions makes
it very hard to actually make out who wrote what in relation to
the quoting indentation. I've been meaning to tell you this
earlier on already, but I didn't specifically want to reply to
one of your posts just tell you only about that particular thing.
comp.os.linux.x...
> crankypuss <noe...@noemail.invalid> writes:
>
>> I'm unfamiliar with the purview of comp.windows.x but I am assuming
>> that it is for discussion of X Windows,
>
> It's "X window." No trailing "s".
such things, I am often found to be a pedantic asshole, I chose not to
say anything this time. :p
On the other hand, I read a nice quote about this in my fortune database
the other day - I can't remember who exactly said it - which went
something like this...:
"You can call it the X Window System. You can call it X11. You may
even call it just plain X. But call it X-Windows and somebody's
going to flame you over it. And you will have deserved it."
;-)
P.S.: Ivan, the way your newsreader accentuates the attributions makes
it very hard to actually make out who wrote what in relation to
the quoting indentation. I've been meaning to tell you this
earlier on already, but I didn't specifically want to reply to
one of your posts just tell you only about that particular thing.
crankypuss
Mar 7, 2013, 2:04:12 PM3/7/13
to
On 02/24/2013 04:10 AM, Ivan Shmakov wrote:
>>>>>> crankypuss <noe...@noemail.invalid> writes:
>
> [Cross-posting to news:comp.windows.x, for this discussion is
> hardly specific to its GNU/Linux implementations.]
>
> > Suppose that, instead of requiring that an X Server always be running
> > in order to support fullscreen applications, it was optional. That
> > is to say, what if there was a fullscreen character-mode support
> > layer that would allow pixel-mode windows to be created as part of
> > its ongoing character-mode support?
>
> As in: Wayland?
I think DirectFB sits at the level I want to work with and also supports
>
> [Cross-posting to news:comp.windows.x, for this discussion is
> hardly specific to its GNU/Linux implementations.]
>
> > Suppose that, instead of requiring that an X Server always be running
> > in order to support fullscreen applications, it was optional. That
> > is to say, what if there was a fullscreen character-mode support
> > layer that would allow pixel-mode windows to be created as part of
> > its ongoing character-mode support?
>
> As in: Wayland?
X as a back-end. So if my understanding is correct, it might be
possible to use DirectFB for what I wish to do.
0 new messages