I have to admit that I sometimes use xlogo to display a color. (xterm is probably the most-used program for me), but why xlogo and xeyes? > I understand your defense of xterm etc. we can convert X.Org on a platform to support new graphic hardware for KDE/Gnome only but, in this case, I will certainly switch to another platform that supports true X11 again! Gnome and KDE are not the way for some people here. I submitted a PR on these matters some years ago but no one cared about it. All these features worked nicely on XFree86 3.x.
#Xclipboard source code update#
xclipboard and xmh broke when XFree86 4 was released (xclipboard does not show the sliding bars on large texts or the black rectangle on lines longer than the xwindow width, xmh has issues incorporating new mail that require "resizing" the windows to refresh and update them to make it readable). I will ask not only to provide these useful components of X11 but also to fix their current bugs. xclipboard is a very useful clipboard able to store hundreds of pasted (and editable!) texts concurrently. Xclock, xterm and so on are *required* for people not running Gnome or KDE on their machines. xeyes and xlogo are a component of X11 too. These are very useful tools when running simple window managers as FVWM or mwm. We *need* xclock, xclipboard, xmh, xterm and so on. > First this is a great opportunity to weed out accumulated fluff and cruft from X - perhaps moving some of it to ports (or nowhere at all Does anyone really need or want xeyes?) Will also finish merge OpenBSD local changes into the new X. Other arches will follow in the next weeks, and I I already have a fully working X11R7.1 installation on i386, amd64 and I've named this system "xenocara" after the fish Packages, I've been working on a "meta" build system, using Is used to keep track of version dependencies between new modules.Īnd how does this all affect the OpenBSD CVS repository? To coordinate the build of the myriad of Is supposed to lower the maintenance burden on the X developers whichĪre now free to concentrate on their code. Being maintained outside of the X.Org project Large user and developer base, and thus feel easier to use by the Modularized source tree are the GNU auto-tools. X.Org has decided that the best tools to manage the build of this new Independent releases, whenever they are needed.
#Xclipboard source code drivers#
Organization will allow drivers maintainers (or others) to make Switch to a more modular organization of the project, with more or
#Xclipboard source code software#
Graphics cards that can produce new models more often than that timeframe.īased on the experiences of other software projects, it was decided to The need for global releases, updating allĭrivers at once every six month or so doesn't really fit the market of The existing X11 source tree, built using the imake build system, wasĬonsidered as a big monolithic thing in which most developers found As people mayĪlready know, one of the main change in X.Org 7.x is a new modularīuild system, using GNU autotools. OpenBSD 4.0 release, to be ready for OpenBSD 4.1. The new X.Org release will be imported in OpenBSD shortly after Matthieu Herrb, reports on changes made to X.Org which will affect the way X11 is built on OpenBSD:
0 kommentar(er)
