Kde-windows Digest, Vol 30, Issue 30
Nuno Brito
mail at nunobrito.eu
Sat Mar 29 16:26:39 CET 2008
Hi again,
A generic KDE installer to later organize all kde specific apps is a good
idea to keep things under control.
Regarding the KDE installer:
I've been trying to make a portable kde to carry around on my pendisk and
showcase to a few work friends but copying the binaries and running on
another machine won't work.
Do I need to install any Qt related service or add any registry keys to
carry the kde base folder to somewhere else?
------
2008/3/29, kde-windows-request at kde.org <kde-windows-request at kde.org>:
>
> Send Kde-windows mailing list submissions to
> kde-windows at kde.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.kde.org/mailman/listinfo/kde-windows
> or, via email, send a message with subject or body 'help' to
> kde-windows-request at kde.org
>
> You can reach the person managing the list at
> kde-windows-owner at kde.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Kde-windows digest..."
>
>
> Today's Topics:
>
> 1. Re: Kde-windows Digest, Vol 30, Issue 29 (Nuno Brito)
> 2. Re: specialized installers (Jaros?aw Staniek)
> 3. Re: specialized installers (Ralf Habacker)
> 4. Hint: cs and cb commands on Windows (Jaros?aw Staniek)
> 5. Re: KProcess, KRun, KShell, KMacroExpander, their abuse,
> windows and security holes (Jaroslaw Staniek)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 28 Mar 2008 10:22:30 -0100
> From: "Nuno Brito" <mail at nunobrito.eu>
> Subject: Re: Kde-windows Digest, Vol 30, Issue 29
> To: kde-windows at kde.org
> Message-ID:
> <c6aeeb1d0803280422y25f27b34o857dfeb354b312e at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Innosetup is a very good installer.
>
> But how will this apply to the context of KDE?
>
> Shouldn't it be less dependent on the mechanisms of Windows?
>
> Imagine the restrictions for running a installer on Vista machines where
> UAC
> is enabled or under XP/2000 with no administrative permissions.
>
> The main advantage of the KDE project for windows (on my humble opinion)
> is
> the independence from the restrictions imposed by windows and let users
> decide what to do next.
>
> Would be good to see KDE as self contained as possible and handle their
> own
> installs without resorting to Add/Remove program tab from the windows
> control panel.
>
> :)
>
>
> 2008/3/28, kde-windows-request at kde.org <kde-windows-request at kde.org>:
> >
> > Send Kde-windows mailing list submissions to
> > kde-windows at kde.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://mail.kde.org/mailman/listinfo/kde-windows
> > or, via email, send a message with subject or body 'help' to
> > kde-windows-request at kde.org
> >
> > You can reach the person managing the list at
> > kde-windows-owner at kde.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Kde-windows digest..."
> >
> >
> > Today's Topics:
> >
> > 1. specialized installers (Ralf Habacker)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Fri, 28 Mar 2008 11:47:59 +0100
> > From: Ralf Habacker <ralf.habacker at freenet.de>
> > Subject: specialized installers
> > To: KDE on Windows <kde-windows at kde.org>
> > Message-ID: <47ECCCDF.4080207 at freenet.de>
> > Content-Type: text/plain; charset="iso-8859-15"
> >
> > Hi,
> >
> > Christian informed me that the amarok team asked for the possibility for
> > an application specific installer. Because in the future there may
> > additional projects like koffice which may like to use such a
> > specialized installer i like to give some hints about this topic:
> >
> > 1.There is always the way to build application specific setups using
> > nsis or inno setup. The advantage is that the application
> > maintainer/packager has full control about what is in the package and
> > what not. The disadvantage is that the application maintainer/package is
> > on his own on building every required package. Packagers could reduces
> > this expense by using the already available packages from the kde
> > mirrors, but then they are bound on the package release cycle
> >
> > 2. The qt based installer was extended to be able to handle application
> > specific themes containing different icons/images/pages like shown in
> > the appended screenshot for a possible amarok installer. Technical it
> > would use the public available binary packages. For specialized
> > installers patches are welcome.
> >
> > Any comments ?
> >
> > Ralf
> >
> >
> > -------------- next part --------------
> > A non-text attachment was scrubbed...
> > Name: amarok-installer.jpg
> > Type: image/jpeg
> > Size: 29065 bytes
> > Desc: not available
> > Url :
> >
> http://mail.kde.org/pipermail/kde-windows/attachments/20080328/4125bcea/attachment.jpg
> >
> > ------------------------------
> >
> > _______________________________________________
> > Kde-windows mailing list
> > Kde-windows at kde.org
> > https://mail.kde.org/mailman/listinfo/kde-windows
> >
> >
> > End of Kde-windows Digest, Vol 30, Issue 29
> > *******************************************
> >
>
>
>
> --
> Nuno Brito
> http://nunobrito.eu
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mail.kde.org/pipermail/kde-windows/attachments/20080328/c97a9fc7/attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Fri, 28 Mar 2008 12:44:29 +0100
> From: Jaros?aw Staniek <js at iidea.pl>
> Subject: Re: specialized installers
> To: KDE on Windows <kde-windows at kde.org>
> Message-ID: <47ECDA1D.7080103 at iidea.pl>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Nuno Brito said the following, On 2008-03-28 12:22:
> > Innosetup is a very good installer.
> >
> > But how will this apply to the context of KDE?
> >
> > Shouldn't it be less dependent on the mechanisms of Windows?
> >
> > Imagine the restrictions for running a installer on Vista machines where
> UAC
> > is enabled or under XP/2000 with no administrative permissions.
> >
> > The main advantage of the KDE project for windows (on my humble opinion)
> is
> > the independence from the restrictions imposed by windows and let users
> > decide what to do next.
>
> I consider NSIS and Innosetup (rather) only as temporary solution for
> anyone
> who wants to play with them. We indeed want and have more and more control
> over our installation processes and that is good.
>
> That said, of course we won't have equally lightweight installers for
> particular apps as long as we use Qt, but we do value ease of maintenance
> and
> quality, right?
> Moreover (that was probably already mentioned), what a problem with extra
> 2MB
> if a number of gfx card drivers' installers contain 20MB+ of additional
> garbage? ;)
>
> As a side note: note however, that some enterprises have policy of only
> allowing .msi installers in their environments...
>
> Again, Ralf and Christian, kudos for your work on the installer(s)!
>
> > Would be good to see KDE as self contained as possible and handle their
> own
> > installs without resorting to Add/Remove program tab from the windows
> > control panel.
>
> Yes, putting every application (or rather module like amarok or koffice)
> in
> the add/remove list would be indeed an overkill. Note how much this list
> is
> broken under Vista (every important KB fix is mentioned there), and I
> guess on
> XPSP2 too.
> So we can have our subsystem and just keep "KDE icon" in the control
> panel.
> Optionally we can have one add/remove entry called "K Desktop Environment
> -
> Add/remove programs" or so.
>
> just my 2 cents
>
> --
> regards / pozdrawiam, Jaroslaw Staniek
> Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work
> on
> Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
> KDE Libraries for MS Windows (http://windows.kde.org)
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 28 Mar 2008 13:14:56 +0100
> From: Ralf Habacker <ralf.habacker at freenet.de>
> Subject: Re: specialized installers
> To: KDE on Windows <kde-windows at kde.org>
> Message-ID: <47ECE140.8070402 at freenet.de>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Jaros?aw Staniek schrieb:
> > Nuno Brito said the following, On 2008-03-28 12:22:
> >
> >> Innosetup is a very good installer.
> >>
> >> But how will this apply to the context of KDE?
> >>
> >> Shouldn't it be less dependent on the mechanisms of Windows?
> >>
> >> Imagine the restrictions for running a installer on Vista machines
> where UAC
> >> is enabled or under XP/2000 with no administrative permissions.
> >>
> >> The main advantage of the KDE project for windows (on my humble
> opinion) is
> >> the independence from the restrictions imposed by windows and let users
> >> decide what to do next.
> >>
> >
> > I consider NSIS and Innosetup (rather) only as temporary solution for
> anyone
> > who wants to play with them. We indeed want and have more and more
> control
> > over our installation processes and that is good.
> >
> > That said, of course we won't have equally lightweight installers for
> > particular apps as long as we use Qt, but we do value ease of
> maintenance and
> > quality, right?
> > Moreover (that was probably already mentioned), what a problem with
> extra 2MB
> > if a number of gfx card drivers' installers contain 20MB+ of additional
> > garbage? ;)
> >
> there is no problem i think additional compared to the size of the whole
> kde installation the 2MB of the installer are irrelevant ;)
> > As a side note: note however, that some enterprises have policy of only
> > allowing .msi installers in their environments...
> >
> Applications on windows more and more supports self contained
> updaters/installers like Acrobat Reader, Apple Quicktime and others
> independently from the Microsoft Windows Installer, they only use an
> initial msi package. To fit this need there could be one msi package
> which installs the kde installer and the software control panel entries
> you mentioned below.
> > Again, Ralf and Christian, kudos for your work on the installer(s)!
> >
> >
> >> Would be good to see KDE as self contained as possible and handle their
> own
> >> installs without resorting to Add/Remove program tab from the windows
> >> control panel.
> >>
> >
> > Yes, putting every application (or rather module like amarok or koffice)
> in
> > the add/remove list would be indeed an overkill. Note how much this list
> is
> > broken under Vista (every important KB fix is mentioned there), and I
> guess on
> > XPSP2 too.
> > So we can have our subsystem and just keep "KDE icon" in the control
> panel.
> > Optionally we can have one add/remove entry called "K Desktop
> Environment -
> > Add/remove programs" or so.
> >
> I add this to the installer todo list.
>
> Thanks for this pointers.
>
> Ralf
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 28 Mar 2008 19:16:21 +0100
> From: Jaros?aw Staniek <js at iidea.pl>
> Subject: Hint: cs and cb commands on Windows
> To: KDE on Windows <kde-windows at kde.org>
> Message-ID: <47ED35F5.9010602 at iidea.pl>
> Content-Type: text/plain; charset="utf-8"
>
>
> The command prompt is not as flexible but at least I have two batch
> commands
> (attached).
>
> 1. I use
>
> cb kdelibs
>
> to move to kdelibs bianary directory, e.g. to quickly type nmake install
> somewhere. In my case it moves to
> c:\kde4\tmp\kdelibs-20080202\work\msvc2005-Debug.
>
> That's for msvc, and assuming your builddir is %KDEROOT%\tmp.
> So you may want to alter this.
>
>
> 2. I use
>
> cs kdelibs
>
> to move to kdelibs source directory.
>
>
> --
> regards / pozdrawiam, Jaroslaw Staniek
> Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work
> on
> Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
> KDE Libraries for MS Windows (http://windows.kde.org)
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: cb_cs.zip
> Type: application/zip
> Size: 269 bytes
> Desc: not available
> Url :
> http://mail.kde.org/pipermail/kde-windows/attachments/20080328/0e23c443/attachment-0001.zip
>
> ------------------------------
>
> Message: 5
> Date: Fri, 28 Mar 2008 22:07:39 +0100
> From: Jaroslaw Staniek <js at iidea.pl>
> Subject: Re: KProcess, KRun, KShell, KMacroExpander, their abuse,
> windows and security holes
> To: kde-core-devel at kde.org
> Cc: KDE on Windows <kde-windows at kde.org>
> Message-ID: <47ED5E1B.9030407 at iidea.pl>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Oswald Buddenhagen said the following, On 2008-03-16 22:40:
>
> > first of all, a rant: i did a grep on KShell::quoteArg ... the number of
> > hits is amazing. and 90+% indicate unnecessary use of a shell.
> > the top three reasons *not* to go through a shell:
> > - it is not portable
> > - it is slow
> > - you risk security holes (if you get the argument quoting wrong) -
> > remember that delayed release some years ago?
> > so if your code contains any of these:
> > - system()
> > - popen()
> > - KProcess::setShellCommand() or K3Process::setUseShell(true)
> > you are likely to be doing something wrong. please review and fix any
> > code that you maintain.
> > on a related note, KMacroExpander::expandMacrosShellQuote() and
> > KShell::splitArgs() are still under-used, leading to lots of duplicated
> > (and usually not particularly robust) code. but see below.
> >
> >
> > now to the broader topic ... starting subprocesses and supplying
> > arguments to them. for now only unix ...
> >
> > - the basic and usually only correct way to start a process is by using
> > KProcess (without resorting to setShellCommand). you can run processes
> > synchronously, asynchronously or completely detached, supply a working
> > dir, make redirections, chain processes and deal with their i/o.
> >
> > - if you have the user supply file names, you might want to run them
> > through KShell::tildeExpand() prior to passing them to the process.
> > but KFileDialog already handles this internally, so usually there is
> > no need to bother with it (and expanding strings that are not meant to
> > be would be potentially harmful, anyway).
> >
> > - then there is KShell::splitArgs() (used without AbortOnMeta). it
> > performs word-splitting according to somewhat simplified bash rules.
> > the result is usually fed into a KProcess.
> > meanwhile it is even somewhat popular.
> > but one has to wonder what it is actually used for - why would anyone
> > supply something that resembles a shell command, but is none?
> >
> > - then exists the possibility to run a complete command through a shell
> > via KProcess::setShellCommand().
> >
> > - if you use KShell::quoteArg() or KShell::joinArgs() to construct a
> > command line, you should reconsider - see above.
> >
> > - a generally justified use of the shell are user-supplied command
> > lines. often such a command line is filtered through
> > KMacroExpander::expandMacrosShellQuote() prior to passing it to
> > KProcess to replace any expandos in the command.
> >
> > - a somewhat fancy way to execute a shell command is
> > KRun::runCommand()
> >
> > - a fairly efficient way to execute a shell command is using
> > KShell::splitArgs() with the AbortOnMeta flag - if it can be parsed
> > according to the simplified bash rules, it can be run directly,
> > otherwise it needs to be run through the shell.
> > KRun does that internally.
> >
> > now comes into play this bloody braindead waste of time that is called
> > windows. it pretty much screws us over with everything that actually
> > requires using a shell. the gory details are explained in
> > http://lists.kde.org/?l=kde-windows&m=119159232432366&w=2
> >
> > as a consequence i suggest the following course of action:
> >
> > - i would build the KShell::splitArgs() with AbortOnMeta magic from KRun
> > directly into KProcess::setShellCommand(). on unix, a flag to bypass
> > this automagic would exist. on windows, it would simply refuse to
> > run anything too complex - users can be expected to use batch files
> for
> > complex constructs anyway.
> > to KRun::runCommand() the same would apply.
> >
> > - KShell::splitArgs() would disappear from the public api on windows. on
> > unix, its use should be limited. it would be mostly obsoleted by the
> > previous point anyway.
> >
> > - any code that uses KShell::quoteArg() or KShell::joinArgs() is likely
> > to be either bogus or inherently platform-dependend. i think it
> > should be made unix-only again.
> >
> > - KMacroExpander::expandMacrosShellQuote() would be safe only as far as
> > the improved KProcess::setShellCommand() goes.
> >
> > anything i did not consider?
>
> I can only say that the fact that bool
> KMacroExpanderBase::expandMacrosShellQuote( QString &str,
> int &pos ) just fails on Windows makes KRun::processDesktopExec() failing
> too,
> what in turn breaks opening in my KMail :).
>
> On windows it's true that 99.(9)% of use cases for symbol expanding is
> "<command> %f" call, what's indeed the pattern used so often in the
> windows
> registry.
>
> --
> regards / pozdrawiam, Jaroslaw Staniek
> Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work
> on
> Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
> KDE Libraries for MS Windows (http://windows.kde.org)
>
>
> ------------------------------
>
> _______________________________________________
> Kde-windows mailing list
> Kde-windows at kde.org
> https://mail.kde.org/mailman/listinfo/kde-windows
>
>
> End of Kde-windows Digest, Vol 30, Issue 30
> *******************************************
>
--
Nuno Brito
http://nunobrito.eu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-windows/attachments/20080329/3598b66b/attachment-0001.html
More information about the Kde-windows
mailing list