From trick at icculus.org  Sun May 25 13:53:00 2008
From: trick at icculus.org (Gerry JJ)
Date: Sun, 25 May 2008 19:53:00 +0200
Subject: A couple patches, etc
Message-ID: <20080525195300.648ce9dc@lighthouse.localdomain>

Hello there.  Made some new DROD installers recently, which brought up a
few issues.  I've attached a .patch file (against svn head, rev 563)
that fixes some of them.  All of these patches are in the latest DROD
v3.2.0.83 installers and seems to work =).  Some comments:

1. scripts/mojosetup_mainline.lua, @@ -1328,6 +1328,7 @@:
The installer would fail if attempting to install into a directory
whose parent directories didn't yet exist.  This fixes that by making
the parent dirs first if required.

2. gui_gtkplus2.c, @@ -171,8 +171,8 @@:
Destination browse button: Set initial path to the path currently
selected in the combo box.  (GTK will pop up a dialog to complain if the
currently selected path doesn't exist, but imo that's ok; it alerts the
user that the path isn't what it might be expected to be and then sets
the directory to the first valid parent dir in stead, which is excatly
what the FIXME there suggests to do).

3. docs.txt, @@ -297,7 +297,7 @@:
Typo: postinstall -> postuninstall

4. gui_gtkplus2.c, @@ -754,7 +754,7 @@:
The entries in the destination combo box was in the reverse order, this
patch fixes this, ie the first path in recommended_destinations array
appears first in the list (also consistent with ncurses ui).

5. platform_unix.c, @@ -508,7 +508,7 @@:
This is in the MojoPlatform_unlink function.  We need to use lstat here
in stead of stat, since stat will fail if the target is a dangling
symlink.  lstat handles that, and works fine for other files too.

6. platform_unix.c, @@ -1170,11 +1170,18 @@:
In MojoPlatform_switchBin.  Switching binaries very occasionally failed
for no apparent reason (easy for me to detect since 32-bit and 64-bit
gtk looks different on my dev box).  The reason appears to be that the
directory entry for the new executable wasn't updated before mojosetup
launched it.  This patch tries to avoid that by first fsyncing the fd
before close and then waiting a little bit if the chmod fails and try
that again a few times.  (There's probably a better way to do this.  I
first tried to do fsync on the dir, but that didn't really work out.
Also, this might be required for the gui plugins too, though I didn't
have problems with those).

7. lua_glue.c, @@ -1121,7 +1121,8 @@:
This adds autodetection for splash orientation (while we're waiting for
a splash position setting in the config =)).  Splash images that are
wider than they are high (or square) goes on top as before, images that
are higher than they are wide goes on the left.  The new DROD installers
rely on this, so I hope this will get approved =)

Some other isses and feature requests I didn't find/patch yet (since I
found ways around them and was in a bit of a hurry):

* Setting permissions through the file filter by returning name, mode
 doesn't seem to work anymore?  At least it had no effect at all on
 permissions on my test runs, both from regular directory and appended
 zip archive.

* The uninstaller returns true if aborted.  (I'd expect it to return
 false in all cases where the installed app wasn't uninstalled.)

* Is generic name for desktop menu items really required?  I ran into a
 bug in KDE (I think) where it'll sometimes mess up the names and
 display only the generic name if the main name includes a colon.  (I
 got around this by setting both name and generic name to be the same)

* A hook for running things after the main eula has been accepted but
 before install options are selected would be nice.  (The DROD
 installers detects existing installations and prompts to uninstall
 the previous version before going on with the install.  Currently this
 is done in precheck, but I think doing it after the eula, yet before
 options, would be more natural.  preflight is run after options.)

* A yes/no/cancel dialog would be nice.  (For example, for the
 uninstall prompt, the choices could be yes for uninstall, no for
 don't uninstall but continue installation, or cancel for abort
 install.)

* Also, is there a way to signal that the installation should
 not continue without popping up an additional dialog box (through
 fatal) for people to click through?  (For use in abort install
 questions)

* A way to get the home dir for root, if possible.  When running an
 installer through sudo, the home directory is not updated.  This
 became a problem for me because I put a symlink to the manifest xml
 in $HOME/.caravel/installed/<id>.xml (to detect existing installations,
 and for compatibility with some earlier versions which used Loki
 Setup), but doing this under sudo will put files owned by root in the
 user's home directory (and location depends on current user,
 obviously, so detection might fail if run by a different user).
 Currently I just detect euid and see if '/root' exists and use that
 for home in stead if it does, but I'm not exactly thrilled with that
 solution..  (You could also argue if /root is the right place to put
 that in the first place, but it's what Loki Setup did.  Bah.)

* It'd be nice if MojoSetup supported installation of (semi-)globally
 shared, writable data.  Actually this is related to a feature request
 I've got for PhysicsFS; have two different write paths at once, one
 for user-local and one for shared data.  You can't simply use
 PHYSFS_setWritePath for this since PHYSFS_setWritePath will fail if
 some files are still open in the old write path, and there's also no
 cross-platform way in physfs to get the shared path (would maybe use
 CSIDL_LOCAL_APPDATA in Windows and probably /var/games/<id> in Linux,
 at least for games?).  Anyway, what I'm getting at here is that this
 directory also needs to be set up with right permissions (also system
 dependent), which is probably best done by an installer.  Like
 MojoSetup, say.

- Gerry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mojopatch.patch
Type: text/x-patch
Size: 3885 bytes
Desc: not available
URL: <http://icculus.org/pipermail/mojosetup/attachments/20080525/594bbfe3/attachment.bin>

From thesamo at gmail.com  Mon May 26 12:06:22 2008
From: thesamo at gmail.com (Kareem Kenawy)
Date: Mon, 26 May 2008 19:06:22 +0300
Subject: Arabic translation finished and revised
Message-ID: <91649120805260906j1aba7e2bgb930961152e687f9@mail.gmail.com>

Hello,
the translation has been finished and revised for a while now, i'd
like to test it but i still dunno how..

-- 
- Kareem Kenawy


From icculus at icculus.org  Fri May 30 23:09:34 2008
From: icculus at icculus.org (Ryan C. Gordon)
Date: Fri, 30 May 2008 23:09:34 -0400
Subject: [mojosetup] A couple patches, etc
In-Reply-To: <20080525195300.648ce9dc@lighthouse.localdomain>
References: <20080525195300.648ce9dc@lighthouse.localdomain>
Message-ID: <4840C16E.5060403@icculus.org>


> 1. scripts/mojosetup_mainline.lua, @@ -1328,6 +1328,7 @@:
> The installer would fail if attempting to install into a directory
> whose parent directories didn't yet exist.  This fixes that by making
> the parent dirs first if required.

This is now svn revision #565.

> 2. gui_gtkplus2.c, @@ -171,8 +171,8 @@:
> Destination browse button: Set initial path to the path currently
> selected in the combo box.  (GTK will pop up a dialog to complain if the
> currently selected path doesn't exist, but imo that's ok; it alerts the
> user that the path isn't what it might be expected to be and then sets
> the directory to the first valid parent dir in stead, which is excatly
> what the FIXME there suggests to do).

This is svn revision #568.

> 3. docs.txt, @@ -297,7 +297,7 @@:
> Typo: postinstall -> postuninstall

Whoops.  :)     It's now svn revision #564.

> 4. gui_gtkplus2.c, @@ -754,7 +754,7 @@:
> The entries in the destination combo box was in the reverse order, this
> patch fixes this, ie the first path in recommended_destinations array
> appears first in the list (also consistent with ncurses ui).

This is svn revision #569.

> 5. platform_unix.c, @@ -508,7 +508,7 @@:
> This is in the MojoPlatform_unlink function.  We need to use lstat here
> in stead of stat, since stat will fail if the target is a dangling
> symlink.  lstat handles that, and works fine for other files too.

Good catch: it's now svn revision #566.

> launched it.  This patch tries to avoid that by first fsyncing the fd
> before close and then waiting a little bit if the chmod fails and try

Is this a network filesystem? I can't imagine the kernel isn't passing 
the chmod()'d exec bit to processes out of the filesystem cache 
immediately, regardless of when it actually hits the disk's platter.

When the chmod() fails, what is errno set to?

> that again a few times.  (There's probably a better way to do this.  I
> first tried to do fsync on the dir, but that didn't really work out.
> Also, this might be required for the gui plugins too, though I didn't
> have problems with those).

Shared libraries don't need the executable bit to be dlopen()'d, so it 
shouldn't be a problem here.

> This adds autodetection for splash orientation (while we're waiting for
> a splash position setting in the config =)).  Splash images that are
> wider than they are high (or square) goes on top as before, images that
> are higher than they are wide goes on the left.  The new DROD installers
> rely on this, so I hope this will get approved =)

It's a good idea...when an explicit position config option is added, 
it'll default to something like "auto", which does this.

This patch is svn revision #567.


I have to do some research on the other feature and bug notes...I'll get 
back to you on that.

Thanks!

--ryan.



From icculus at icculus.org  Fri May 30 23:53:13 2008
From: icculus at icculus.org (Ryan C. Gordon)
Date: Fri, 30 May 2008 23:53:13 -0400
Subject: [mojosetup] Arabic translation finished and revised
In-Reply-To: <91649120805260906j1aba7e2bgb930961152e687f9@mail.gmail.com>
References: <91649120805260906j1aba7e2bgb930961152e687f9@mail.gmail.com>
Message-ID: <4840CBA9.3020101@icculus.org>


> the translation has been finished and revised for a while now, i'd
> like to test it but i still dunno how..

First: thank you for your efforts. I'm really pleased with all the 
translation help this project has received from around the world.

I've imported the latest translations into Subversion now, so if you're 
building your own installer, it should Just Work with the latest revision.

Otherwise, here's an x86 Linux installer with the translations:

http://icculus.org/mojosetup/examples/duke3d/duke3d-mojosetup-linux-x86.bin


Two things worth noting:
- That installer only has the MojoSetup strings translated...anything 
specific to Duke Nukem 3D--like the README--is not translated.
- Most of the GUI plugins can't handle right-to-left languages like 
Arabic. My Linux terminal can render the glyphs correctly, but in 
reverse order, and it's likely that the ncurses GUI will both render 
them in reverse and incorrectly size boxes, etc. The GTK+ GUI _does_ 
handle the Arabic strings correctly; I just tried it here to verify. I 
assume that's what most Linux users will be using, so I don't plan to 
improve the console-based UIs to handle Arabic better...doing it 
correctly would probably require me to introduce a dependency on 
libfribidi, which I'm not really willing to do, since GTK+ takes care of 
that on the user's system.

--ryan.



From thesamo at gmail.com  Sat May 31 12:55:56 2008
From: thesamo at gmail.com (Kareem Kenawy)
Date: Sat, 31 May 2008 19:55:56 +0300
Subject: [mojosetup] Arabic translation finished and revised
In-Reply-To: <4840CBA9.3020101@icculus.org>
References: <91649120805260906j1aba7e2bgb930961152e687f9@mail.gmail.com>
	 <4840CBA9.3020101@icculus.org>
Message-ID: <91649120805310955m25bc263ei9b0d6a6b81437af1@mail.gmail.com>

On Sat, May 31, 2008 at 6:53 AM, Ryan C. Gordon <icculus at icculus.org> wrote:
>
>> the translation has been finished and revised for a while now, i'd
>> like to test it but i still dunno how..
>
> First: thank you for your efforts. I'm really pleased with all the
> translation help this project has received from around the world.
>
> I've imported the latest translations into Subversion now, so if you're
> building your own installer, it should Just Work with the latest revision.
>
> Otherwise, here's an x86 Linux installer with the translations:
>
> http://icculus.org/mojosetup/examples/duke3d/duke3d-mojosetup-linux-x86.bin
>
>
> Two things worth noting:
> - That installer only has the MojoSetup strings translated...anything
> specific to Duke Nukem 3D--like the README--is not translated.
> - Most of the GUI plugins can't handle right-to-left languages like Arabic.
> My Linux terminal can render the glyphs correctly, but in reverse order, and
> it's likely that the ncurses GUI will both render them in reverse and
> incorrectly size boxes, etc. The GTK+ GUI _does_ handle the Arabic strings
> correctly; I just tried it here to verify. I assume that's what most Linux
> users will be using, so I don't plan to improve the console-based UIs to
> handle Arabic better...doing it correctly would probably require me to
> introduce a dependency on libfribidi, which I'm not really willing to do,
> since GTK+ takes care of that on the user's system.
>
> --ryan.
>
>
> ---
> To unsubscribe, send a blank email to mojosetup-unsubscribe at icculus.org
> Mailing list archives: http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?61
>
>
>


I'm well aware of the state of Arabic on the linux console/terminal.
there are currently some solutions involving bicon or mlterm. and some
work being done on libvte to support shaping. I assume that those
running the curses version on an Arabic locale would be aware of these
issues. While users who go with the - I hope - Default route of gtk2
will have it working out of the box.

-- 
- Kareem Kenawy


