Re: Clipboard

["Sean Middleditch" <sean middleditch iname com>]

> No, not the way I have designed it.
> One of many idea's is that you should be able to "connect" this clipboard
to
> any other clipboard.
> Currently, you are able to use it from the commandline, whithout X running
> or even installed.
> Dependencys are to glib, and a CORBA ORB. To compile it, you'll need
ORBit.
> Not Gnome.

OK, sorry, I didn't realize that.  That's definitely a double plus.

> I wan't it to be GNOME *compilant*, not Gnome dependent, and this at a
> minimum requires you to use Gnorba.
> Once Gnorba is independent of X, if it'll ever be that, you'll still be
able
> to use the clipboard from both GNOME, KDE, the Console, M$ Windows or
> whatever that provedes a CORBA enviroment.
>
> But OK. I allso think that the best thing to do, would be to enchant an
> existing, standard clipboard. However, from what I know, this would break
> backwards compability. At least if you wan't things like filters, and
"CORBA
> plugin storages", history listings, etc to X-clip...

I didn't even know there were other X clipboards.  I'm actually a bit new to
X (about 6 months of use).

> Wouldn't a standard sound daemon be a more suitable place for a standard
> sound interface, than XLib?
> Allthough X spawns a lot of events, which *can* produce sound, I don't
> really think that X itself should do the beeping! ;-)

Yes, there you are correct.  Sound should be independent of X, so console
programs can make use of them.  Currently (for Linux at least), things like
OSS and ALSA exist, but here we have two seperate and incompatible API's.

An X example of my point: XFree86 4.0 will have this new DRI (Direct
Rendering Interface), right?  Let's say someone else creates a Fast Graphics
Interface.  Then some programs will be written for DRI, some for FGI.
Here's the problem: either X servers will have to support one (so one wont
work), they'll have to support both (takes up more memory), or it will truly
support one and create a wrapper/emulator for the other (that one ahs
reduced performance).  A single, universal standard that everyone follows
will make life easier for everyone.

I at first wanted to add all these standardization features into GNOME.
Then I realized that there's a lot of software that's not GNOME specific
needs these standardizations.  Now I see maybe that's too specific.  If all
programs stuck to a single API, things will run smoother, faster, and
easier.

That's perhaps the one really nice thing about Windows.  Everything comforms
to the Windows standard, making life easier (well, in SOME ways) on Windows.
Windows doesn't have to have 40 different Desktop Environments installed for
all Windows apps to run.  It doesn't need 20 different sound APIs.  It all
runs of one (maybe 2) APIs.  Unfortuneately for Windows, both of the API's
really suck.

> If you has got any ide'a about how one would be able to add custom filters
> to the X-clipboard whithout breaking compability, and preferably whithout
> having to rewrite every program from xv to gmc, please let me know. I have
> no clue about how this should be done.

Is it truly that hard?  Cannot one make an extension to the X clipboard that
uses the custom filters, and leave the old one there for older apps?  If
your clipboard becomes standard enough, most apps would be ported to use it
anyways.  That's a great thing about free operating systems: they advance
whenever possible.

But if your clipboard can use the data in the X clipboard, and have
additional features for apps that know how to use them, this is a wonderful
step.  If the KDE clipboard can also interact with the X clipboard, that
would solve a lot of problems right there, no?

Sean Middleditch

P.S.  For any of you who think I have no idea what I'm talking about, you're
probably right.  But I wont learn anything if I don't try, now, will I?  ;)