Update: A new release or X-Chat Portable is availble, please see X-Chat Portable 2.8.4 Development Test
New: Run-Command (Dec 2, 2024), Platform 29.5.3 (Jun 27, 2024)
1,100+ portable packages, 1.1 billion downloads
No Ads Nov/Dec!, Please donate today
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
I tried pkeffects portableapps.com chat room. No one was there, but it seemed to connect ok.
Life is about the journey not the destination!
The Kazoo Spartan
Tried it and connected to EFNet with no issues.
There's a reference to PidginPortable.exe in the \Other\Readme.txt file. That should probably be changed to X-ChatPortable.exe
Does the WaitForPidgin=false setting in the settings.ini actually do anything? I can't see any code that looks for that setting.
Is there a way to change the "dcc_dir=" setting in \Data\settings\xchat.conf to point to a directory in the xchat portable app structure (maybe dynamically?). I can see that being an issue if someone gets sent something via DCC and it's left in the default dir on their D: drive. Maybe xchat prompts the user if the directory doesn't exist. If it creates the directory, that would be "bad manners" for a portable app. What if they don't have a D:\ drive or it's a CD-ROM?
Friendly warning for those on corporate LANs and the like -- any IRC server is going to try to authenticate you on port 113. This is no doubt blocked on firewalls so by you using this app, you're sending up a big, red flag to the network admins to come and check you out since you're probably breaking some user agreement you signed. Don't bring attention to yourself with this app (or any other IRC/chat/IM app for that matter).
Cancer Survivors -- Remember the fight, celebrate the victory!
Help control the rugrat population -- have yourself spayed or neutered!
Thanks about the Readme, I'll correct that.
I thought I'd changed the WaitForPidgin, I'll look into that.
Actually, the xchat.conf is set to like G:\Documents\Downloads and I set the drive letter under DefaultData to G, so when you are on a new drive, it should replace the old drive letter (currently G for the first run) with whatever you're on. Maybe you can test that with a fresh install and I will too, I may have screwed up the settings. Were you running it from D? I'm the only person with my Documents folder on my D drive, most have it on C. Maybe I did screw up the default settings. I'll test this.
Thanks for testing.
Edit: Just checked, the default settings are set to F:\Documents\Downloads, and when I run it from say, C on first run, it changed my download dir to C:\Documents\Downloads. Maybe I will just make it change to the current drive letter, but I don't know how yours changes to D? Are you running it from D? But I'll remove the next of the path on next release. It's just the PAPlatform has the Documents directory, and this would only create a Downloads directory within it.
Yes, I run portable apps from my D: (hard drive). Making a subdir under [portable_drive]:\Documents\ makes sense, but what happens in my case? I get a directory created on the hard drive left there as "evidence" (D:\Documents doesn't exist anyways...will x-chat crap out then if I use DCC receive?).
John had some code in the past that detected the drive type. Maybe you could use something like that to check if the user is running from a fixed or portable drive. If running from a portable flash drive, save to the place you do now. If it's executed from a fixed drive, do something else (don't have an idea what to do in that case right now.)
Reminder: portable USB hard drives are recognized by the system as removable drives (at least on my WinXP system).
Cancer Survivors -- Remember the fight, celebrate the victory!
Help control the rugrat population -- have yourself spayed or neutered!
The default DCC Dir the root of the drive instead as default. I'm not gonna make it check if it's running from a fixed of portable drive because that's extra code which seems pointless to me since it should be run from a portable drive. You can set the path yourself to a place on your fixed drive, and if you continue to run it from that fixed drive, that path will stay the same and the drive letter will not change.
...it should be run from a portable drive...
That's your opinion and you're entitled to it, but you can't control where people run apps from. However, you as the coder should compensate for all possible scenarios.
Cancer Survivors -- Remember the fight, celebrate the victory!
Help control the rugrat population -- have yourself spayed or neutered!
The default download directory the root of the drive no problem, but I'm not doing extra coding for someone that chooses to run if from a local drive. That's not its purpose. It's meant to be run from a portable drive. If you run if from a local machine, you have no problem having a Download directory created under their Documents directory. However if someone copies there portable app to a local drive (for whatever reason), they would not want that folder created. So I may make the DCC_Dir just the drive root. We'll see.
Portable.
Life is about the journey not the destination!
The Kazoo Spartan
This thread has bugged me for a couple of days now. And even though I wanted to leave it be, I feel I have to say something about it. And not because I believe anyone is correct or wrong, but just that it doesn't reflect what I see as reality.
Developers are free to program anyway they like and even within the strict rules applied here for PortableApps, have a lot of leeway on how they do it. Some of it might require special concerns later for end-users, but the fact that they do it at all is great stuff.
End-users are also free to use the programs given to them anyway they want so long as they live up to the licensing and rules governing them. Some of the ways may have been unimaginable to the developer, but the fact that someone takes that crafted bit of special code and uses it at all is also great stuff.
But I don't see where there has to be antomosity on this. I myself understand that developers have to make some assumptions in order to work with a codebase. But I also understand end-users will always find new ways to push those assumptions. This will always leave both sides scratching their heads at the other.
As for myself, I use the PortableApps developed here in *many* locations - for me, "portable" means more than just pulling a USB drive out. I currently run the same copy of PortableApps (thanks to robocopy.exe) from the following locations:
A spare USB drive on a friend's PC
An ecrypted truecrypt Drive at work
On my home PC in a subdirectory called "\PortApps"
Off a networked location when accessed from my Media PC
Why so many different locations? Speed mainly. USB drives, especially cheap ones, are very slow. Hard drives are faster. Another reason is that I pretty much run all application in a "portable" mode, even apps that aren't a part of this website (like Trillian). I've embraced the 'portable computing' method and found it easy to use; not only using them, but also troubleshooting, restoring, and generally making them friendlier.
I guess what bugs me is that this conflict of where such 'portable' apps should be run from feels like a missed opertunity to make things better for both developers and end-users alike. End-users should know that these apps have reasons why assuptions are made - and not just because the developer wanted it that way but it could be built or limited in the code itself. And developers might find some of the ideas interesting and could expand their code to make their code even more 'portable'. Just a thought.
Gah - I didn't want this to be a "can't we all get along" post. Too touchy-feely for me.
But I feel that things can only get better if people didn't think we are working at cross-purposes here. If the code-monkeys write it, the (l)users are here to test it. 
What was your final point, you think I should change it to just the drive letter to benfit the end-user?
I'd say when copying it over, set it to ..\..\Documents using GetParent.
"If you're not part of the solution, you're part of the precipitate."
I'm saying, do whatever you want to do, but I'm just thinking of it benefits the end-users and they use your programs more, wouldn't that be the whole point?
the plugin link sent me to a Welcome frontpage on joomla...
If a packet hits a pocket on a socket on a port,
and the bus is interrupted as a very last resort,
and the address of the memory makes your floppy disk abort,
then the socket packet pocket has an error to report
Thanks, I'll fix that.
Just wanted to let you know John, I added a cropped version of the best high res X-Chat logo I could find for the splash screen, I thought this would be a better idea instead of cluttering your inbox with my poorly thought out e-mails.
It looks fine resized to 128.
Am I the only one having screen redraw problems? Whenever any window gets in front of the main chat window, as the main chat window scrolls it keeps redrawing more copies of the window in front.
In the way of a request, I'm sure others besides just me would appreciate having a preference allowing us to have a DCC tab instead of the window.
Thanks for all your efforts! It is appreciated.
I haven't had that re-drawing problem. Like, does it actually create more instances? Try the regular X-Chat, www.silverex.info and see if you have the same problem.
I didn't create the actual program, only made it portable, so I can't add any new features to the actual app.
[testers needed]
clicking the tray icon crashes the software, at least here
Never had that problem. Try heading over to http://www.silverex.info and download the non-portable version, it you get the same problem let me know.
In the App\X-Chat directory, you included the GTK that is shipped with Silverex's build, leading to an approximate 20MB extra size. It runs fine without it, so there might be a problem?
so there might be a problem?
Yes, I'm dumb.
Did it run okay for you?
It works with and without the GTK+ installation in the X-Chat dir since it just calls the app\gtk copy anyway.
To confirm. What components exactly do I remove to remove GTK. I know mostly what I need to remove, I just want to make sure I don't leave any uneeded files in the X-Chat dir.
Everything seems to be running well, though when I install the X-Tray plugin, i get 2 icons for X-Chat instead of one in the tray.
Keep up the good work!
Yes you do.
Thanks for testing.
Actually, NO you don't. I know what's wrong. Go into X-Chat's settings. Then go Under Chatting > Alerts, and UNcheck the box for "Enable system tray icon" (don't remember if it's default on or not) and you only get one icon
I actually haven't used X-Chat in like two months. So I forgot about that.
I would like to use the English and the German spellchecker in portable mode. (Aspell is also Open Source.)
http://b0at.tx0.org/xchat/
Seams those unofficial builds lack lots of features.
Are you interested in making a meaga xchat package?
- portable for sure
- scripting: Perl, Python, Tcl, Ruby
- plugins: exec, dns, xTray, uptime
- features: SSL, DCC64, DCC server, spelling, emoticons, faster text rendering, ipv6
- license: only Free Software of course
I also thought about creating a own build if needed.
Btw, what is JTH`s opinion about hosting it here?