I'm a dimwit. Change line 351 of xcsi.c to :

   Atom ImageTypeAtom = StringTypeAtom;/// TODO : STRING , really? What Type should an image have?

You'll probably hate me for saying this, but I can't remember a time that Windows didn't reset the video mode back to the original desktop setting when a program aborted.

I'm going to go work on adding support for INCR transfers. You might need it when trying to retrieve an image from the clipboard when you copy your desktop image or maybe other times as well. If only I could figure out what the supposed maximum transfer size was...

Atom ImageTypeAtom = StringTypeAtom;/// TODO : STRING , really? What Type should an image have?

There's a file type for that. It's called a patch file (or less formally a diff file).^[1] You wouldn't know that in the Windows world though. Every one of you would just ... ugh ... edit the file manually. For the record, the MSYS (or maybe MinGW) version of patch does work and should be sufficient to inline a basic patch for something like ^ that. Cygwin's port definitely works. In fact, that simple of a patch is easy enough to write manually if you know what the original file looked like.

Windows does things rather fucked up. Its programs actually seem to need to know what type of program they are and such and that controls what they can and can't do. As a result, most Windows programmers are probably oblivious to the concept of standard streams, command line arguments, or exit codes, making their software pretty useless unless you hire a babysitter... In Linux, I think a program is just a program, and if it happens to create and draw X windows, or enable full screen mode and set the screen resolution then so be it. Of course, if it crashes after it has changed the screen resolution then X remains in the state that it is in. You might think that Windows is doing a better job here, and perhaps given the context it is, but I think the Linux (perhaps it's more correct to say UNIX) way is far better. It would be nice though to create a temporary context that dies with the application regardless of a clean exit. Given the design I'm not sure that it would make sense to though (I'm not very familiar with how it works [yet]).

It's a one line change, of exactly 4 whole characters. 6 if you count Ctrl-S.
Compared to

patch xcsi.c xcsi.diff

I saved you exactly 16 characters of typing.

I know exactly what a diff and a patch is, not to mention that I have gnuwin32 diff and patch installed on my computer and I've used them to send patches to the allegro mailing list before. Not to mention earlier in this thread I used diff to see what changes Arthur had made to my source file to get it to compile.

{"name":"603460","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/0\/90b3fb297211d5b8314a51d47479e84a.jpg","w":370,"h":406,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/0\/90b3fb297211d5b8314a51d47479e84a"}

Well, that's progress, sort of... It means the bitmap saved and loaded, so at least it was recognized as a bitmap. I'll try testing some things here.

Maybe the transfer process corrupted the file somehow?
Can you see anything wrong with using cat to pipe the file into xcsi's stdin?

cat xcsi_image_temp.bmp | xcsi -c -s=bmp
 

Is there a better way to feed a file to xcsi through stdin?

Try copying images from other programs and see what paste (key V) does with those.

Are you sure it was ClipboardTest or xcsi that caused it? I can't see why it would do that. I respond to all SelectionRequest and SelectionNotify events where appropriate.

I copied CyberMan.bmp to xcsi_image_temp.bmp, then ran the command. Nothing happened as far as I could see, so I blasted the the xcsi log to screen again, and saw a whole slew of SelectionRequest to Konqueror. I deleted the log and ran that cat command again, but no new log was created. But then both Konqueror and Firefox were pretty much catatonic when trying to post this. Get your own Linux to futz with! I'm not playing anymore!

I thought it was only Windows that differentiated between text and binary data? The "rb" and "wb" parameters to fread() & fwrite().

Okay, thanks, I'll try that instead.

No problem there, when you set the clipboard or primary selection with xcsi, it forks and then waits for SelectionRequest events.

Define 'whole slew'. Do you mean 50, 100, 500 requests? Also, do you remember the target that it was requesting? TARGETS would be normal, but image/bmp would be rather expensive to do on each update.

That's okay, no requests, no log entries.

It's hard for me to determine why without xcsi_log.txt to tell me what was going on while the programs were unresponsive. If you use pskill to stop xcsi from running, does that return konqueror and firefox to a normal responsive state?

It's up to you. I wouldn't have gotten this far without your help though, so many thanks for what you've done so far.

Hmm, you may be right. STDIN is probably being read as text. Although I don't believe that any character translations like \n to <CR><LF> are being performed on Linux, so technically, using getchar should act as if it were binary data.

Maybe I need to specify an input file as an argument to xcsi and then open the file in binary read mode and specify an output file as an argument and open the file in binary write mode.

That's easy enough to support though, the 4th (file) argument would be optional. If present, i/o would be performed through the specified file, otherwise through stdin.

Append
I'm currently posting this from FireFox using openSUSE 11.3 in a virtual machine under Vista. Whee! I have to say though, so far I'm not that impressed with Linux. It's okay, but it's nothing to brag about. I could also install either Fedora 14 or Ubuntu 10.10 if anyone recommends that. I'm currently using Gnome as my desktop.

Anyway, now that I have a Linux install up and running, maybe I can see about fixing the problems Arthur was having with my clipboard. It may be a few days though, until I get A4.4 up and running again.

Trezker, if you manage to do the clipboard lib could you post it in the Depot?, I was reading the topic but I get lost in page 3-4, so if you can do it using Allegro 5 I would like to try it, since I need something like that in my program. thanks

Edgar sorry I went away I was busy with IRL stuff, you know how it goes.

I don't think that loading packfiles from memory is supposed to be very difficult though? But then I read the docs and it says

So maybe my memory is obsolete now.

KDE4 is far too plastic-y looking. It looks like a cheap toy, and functions about equally as well. Linux user interfaces are a joke, they're about on par with Windows 95.

So basically your complaint is that it's not Windows? There is a learning curve involved. If you installed Linux looking for a free Windows then I'm afraid that you'll be sorely disappointed. On the other hand, GNU/Linux distributions do most things better than Windows, once you get used to them. And the things that they don't do better usually still work pretty well and are always open to improvement. There are still a handful of things that need improvement, but then you paid fuck all so who are you complaining to?

Then again, I'm not too sure about your choice of distribution. I've never used OpenSUSE so I can't really critique it fairly, but I have heard of problems and know Fedora to be relatively smooth sailing and Debian-based distros (Ubuntu being the most n00b friendly, I guess) are pretty well kept up as well. It's possible that you've chosen a lemon, though I suspect that your biggest problems are just change. Those are going to be there no matter what distribution you choose. Either stick it out or try a different distribution. Honestly, the best way to learn is to make the OS your primary OS. Then you have to learn. Of course, it still takes time. I wonder why you were even trying to make an X implementation if you're completely new to unices...

The file explorer can be configured somewhat. It should be able to satisfy your desires. I'm too drunk to figure out what those are though. The one option that I always enable isn't even present anymore when I check Nautilus' dialog, though it does behave correctly still. Aside from that, Nautilus (Gnome's default file manager AFAIK) works pretty predictable. Can you better describe what is wrong?

As for versions of software, I honestly couldn't tell you. In my experience, I either deal with whatever version my distribution offers through its package manager, or attempt to build from source (which can go easily and can go difficult, depending mostly on dependencies). I would suggest that you ask yourself when you need a particular version. Often, the version available with the default options is sufficient. If not then you'll just have to accept the need for manual processing. Often the GUI interfaces in Linux are hacked together by people trying to fill a niche. The most complete and powerful interfaces are usually accessible from the command line first. Don't expect to point and click your way through Linux.

As for the existing PID lock, that is a GUI manager designed to show you when updates are available. There should be an icon in the analogue to the notification area (usually next to the time). Generally, you won't hurt anything by killing that process either if you feel so bold. It's a reasonable thing to occur though, and once you've gained more experience you'll learn to appreciate it. That said, as I mentioned earlier, I have zero experience with OpenSUSE (or any SUSE derivatives) so I can't honestly say how the system is built or even what package format is used. If you really can't survive with it then try a different distribution.

I have no idea what you're talking about regarding the icons on the menu. Maybe that's a theme used by OpenSUSE. With Fedora, Gnome's default menu(s), at least as far Fedora 13, are even easier to use than on Windows. Applications are grouped by type, and each option typically has an icon and a name, and displays a summary when moused-over.

log file attached.

Viewing the bitmap in the program is just a white square, and I can neither paste the bitmap nor the text into other programs (in fact they either show the paste option grayed out, or it is active but selecting it does nothing and then after about 10 seconds I get a dialog box saying that there is no data available in the clipboard).

I remember that on linux if you try to paste some data from the clipboard after closing the program that it was copied from, then it is no longer available, so I don't really like the way that copy+paste works on linux.

One example is the screenshot utility, I would normally press print screen, choose "copy to clipboard" and then close the dialog that comes up, and then paste into GIMP, but I have to remember to leave the dialog open until I have pasted into gimp otherwise the screenshot data is lost....

[EDIT] I just tried again, and it is really 30 seconds not 10 seconds before it says "no data found in clipboard"

[EDIT 2] Also to get it to work I had to change many "xcsi blah blah" into "./xcsi blah blah" in Clipboard.c for ALLEGRO_UNIX section