xffm translation: date specification

[edscott wilson garcia]

El jue, 19-06-2003 a las 09:08, Bernhard Walle escribió:
> Hello,
> 
> On Thu, 19 Jun 2003 at 08:39 (-0500), edscott wilson garcia wrote:
> > El mié, 18-06-2003 a las 15:50, Benedikt Meurer escribió:
> > > On Wed, 18, Jun 2003, edscott wilson garcia wrote:
> > > 
> > > Why? (IMHO) we try to keep the other components "hack-free" (we had
> > > discussion on wm and panel lately), so lets keep xffm "hack-free"
> > > as well (just my opinion).
> > 
> > The only issue here is that since I have no idea what the hack consists
> > of (having just done a cut and paste from the GNU-ls code) I would
> > probably just replace on hack with another. If you know how to get rid
> > of the hack, please do. All I ask for is:
> > -files younger than 6 months show hh:mm instead of year 
> > -no strings for month translations be necessary in the po files (they're
> > big enough already).
> > 
> > If you could help me on these issues I would greatly appreciate it.
> 
> 
> Where's the problem? Something like
> 
> 
> char *getModificationString (const char* path) {
>       static char   string[BUFSIZ];
>       time_t        now             = time(NULL);
>       struct stat   statstruct;
>       char*         formatstring;
>       
>       memset (string, 0, BUFSIZ);
> 
>       if (stat (path, &statstruct) != 0) {
>           return NULL;
>       }
> 
>       formatstring = difftime(now, statstruct.st_mtime) > 24*60*60*30*6
>           ? OLD_FORMATSTRING
>           : NEW_FORMATSTRING;
>       
>           
>       if (strftime(string, BUFSIZ, formatstring, localtime(&statstruct.st_mtime)) == 0) {
>           return NULL;
>       }
> 
>       return string;
> }
>       
> would work, just the two strings must be translated. 

There's the rub. We're in translation freeze. There should be a way not
to require the translations.

> 
> 
> 
> > BTW, OT, I'm going to change the behaviour on the copy operation.
> > Previously only moved files received the date of the original file. In
> > the future, so will copied files, since the date information is much
> > more usefull if it reflects content. This will make working with CVS
> > sandboxes a bit faster. 
> 
> Do you really want another behaviour in a filemanager than just using
> GNU cp?

When the GNU/cp or DOS/copy is not usefull, yes. Otherwise I would stick
to an xterm like Joe. There is no reason why to have different dates of
otherwise identical files when the important aspect of a file (from a
human standpoint) is the content, not the physical location on the disk.
In old days, you could not "mv" from one device to another. Then you
could, but it would alter the date. Now it sets the date as the original
file. Which means the the GNU cp behaviour is probably not frozen in
time either.

regards,

Edscott

> 
> 
> Gruss,
> Bernhard
> 
> -- 
> _________ http://www.bwalle.de _________________________________________________
> Der Versuch, beschäftigt zu wirken, wenn man es nicht ist, ist die schwerste 
> Aufgabe von allen.
> 	-- Feather
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> http://moongroup.com/mailman/listinfo/xfce4-dev
>