Hello,
I commited the patch for relative paths instead of absolute paths for
emoticons and DP a few weeks ago. It simply compares the left part of the
absolute path with the path of the home directory of the profile and
replaces it with a ~ before saving it to file. On every usage of the file it
expands the ~ again to the full path. That patch was in revision 9474 for
emoticons and 9486 for DP. I decided to use this way because it's the only
way to keep compatibility of the profiles and without the need of major
changings.
So to the other settings: I had a very simple solution that works very well
for me. Right before saving all the settings to file in save_config it
renames all OS-specific keys to *_win, *_unix, *_mac or *_other depending on
the running OS. After loading in load_config it renames those keys back if
they exist in the config file, otherwise it uses the default values or the
OS-independant keys (for configs created without that patch). So there are
no major changings required, only those two little things in config.tcl.
For the amsn_received-directory there are two possible solutions:
1. move this directory to the profile dir so I would use the same solution
like for the emoticons and DP, but this becomes OS-specific again if the
user chooses a directory outside the profile directory, or
2. mark the key as OS-specific, but then the received files are not really
bound to the profile and will be always stored on the local pc.
But I think, looking to all the current users, it would be better to mark
the key as OS-specific because most users will have their amsn_received
outside their profile directory and solution 1 wouldn't make it portable in
their case. Maybe a combination of both solutions would help those who want
to have their received files also portable in their profiles directory, but
I think, when a user really wants and needs this he can manually move this
directory to his profile directory.
Would that solution be OK, then I'll commit my patch?
Mirko
2008/1/29, Youness Alaoui <[EMAIL PROTECTED]>:
>
> Hello,
> I think it is great that you're doing this, it will be a nice feature to
> have for 0.98. Changing the paths to absolute paths is a good idea but
> might be causing problems with skins since all images are loaded through
> the skinning system, and when you have a relative path it tries to find
> the image in the skin directory.. but I think if the path is
> "smileys/cache/whatever.png" it will only affect us if a skin comes with
> "skin_name/pixmaps/smileys/cache/whatever.png" since the relative path is
> still being used even when looking inside the skins' folder...
> Anyways, the os specific config keys are indeed a problem and this could
> be resolved with your idea of having a suffix to them depending on OS. I
> agree this would be a good idea and you can do it if you want, assuming it
> doesn't add too much complications to the code (maybe wrap each
> variable inside a function, like ::config:getBrowser and have the if/else
> in there instead of having to put them everywhere we want to use that
> var..
>
> About the amsn_received, that's wrong, we always put the directory in the
> home. in mac it's the desktop, on linux, it's the $HOMe directory, and
> on windows, it's in the c:\documents and settings\<win
> username>\amsn_received directory. We use the scripts dir only when we can't
> find the env
> variables for our destination.. (if $HOME doesn't exist on linux or
> $NTPROFILE or whatever doesn't exist on windows, we fallback on the scripts
> dir.)
> That path shouldn't be common and be put in the .amsn/<profile>/received
> because of the issues you said about the hard to find (although xchat,
> bittorrent and some other programs do save dcc/received files in their
> ~/.something config dir). Advantage is that a file you received will not
> be 'shared' with the files someone else received, so you can receive your
> porn image without worrying about your dad seeing it when he uses aMSN
> (actually your mom since your dad might like it.. :p)
> On the other hand, aMSN as a setting for the received folder so a user can
> configure it.. in that case, how do you plan on doing the relative
> path thing in there ? what if it' son the D drive on windows.. ? this can
> be tricky...
> also, we *could* put it in the profile dir, have people use the 'open
> received files folder' through the menu, and if they want to, then they can
> set it up the way they want.. a 'bad default' but as long as a user can
> configure it, it should be fine even if it's hidden in ~/.amsn ...
> I'm not sure about this amsn_received thing, so let's see what others
> think...
>
>
> KaKaRoTo
>
>
> On Mon, Jan 28, 2008 at 07:56:44PM +0100, Mirko Hansen wrote:
> > 2008/1/28, Harry Vennik <[EMAIL PROTECTED]>:
> > >
> > >
> > > Op 28-jan-2008, om 16:41 heeft Mirko Hansen het volgende geschreven:
> > >
> > >
> > > > Hey everybody,
> > > >
> > > > as I had a lot of trouble the last days with my laptop (I usually
> > > > use aMSN only on my laptop with WinXP, at home and at university)
> > > > because it had a hard disk crash, I was trying to use my profile on
> > > > my Mac at home and the Linux-PCs at university and noticed that
> > > > profiles are more or less incompatible between other OSs. There are
> > > > several settings in the config that are OS-specific or absolute
> > > > paths only reachable on the same system, so I was wondering if I
> > > > was the only one having those problems? The worst thing were the
> > > > paths to the custom emoticons, therefor I allowed myself to commit
> > > > a patch that stores the path in the config.xml as a relative path
> > > > from the profile directory instead of the absolute path, that there
> > > > is no need to modify the config.xml before moving the profile to an
> > > > other OS. I did the same for the DP, but there are several other
> > > > settings left that are not directly portable. So my intention is to
> > > > make the profiles portable between OS or even increase the
> > > > portability as much as possible, if you agree.
> > > > At first I have a simple question: Is there any reason why the
> > > > directory of the received files is located on a "neutral" place?
> > > > Well, on MacOS it's much easier to find because it's located on the
> > > > desktop, but on Windows it's located in the scripts directory, so I
> > > > was wondering whether it couldn't be placed in the profile
> > > > directory, too? On Linux and other Unix that would result in a
> > > > problem, trying to find the directory, as .amsn is hidden, but
> > > > maybe a menu item "view received files" in the CL like the button
> > > > in the transfer window would help here.
> > >
> > > That menu item is already there (in the Account menu)
> >
> >
> > Aaah you're right, I havn't noticed it before ... I should better open
> my
> > eyes next time ;)
>
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Amsn-devel mailing list
> > Amsn-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/amsn-devel
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Amsn-devel mailing list
> Amsn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amsn-devel
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel
