How to add icons and program group menu for a linux application.

How to add icons and program group menu for a linux application.

Post by Lothar Scho » Sat, 12 Oct 2002 14:46:29



I'm writing an installer for a linux app that should look and work
like the windows installer. Please don't tell me that i should create
a RPM or DEB package.

I think i found how to add an icon to the desktop. Its simply copying
a desktop-entry file described in
http://www.freedesktop.org/standards/desktop-entry-spec/desktop-entry...
to the $HOME/Desktop or $HOME/.gnome-desktop directories.

But how can i add an entry/program-group to the desktop (start) menu ?
The only thing i that seems to be able to take desktop files is the
".kde/share/apps/RecentDocuments" directory.

I know that this is possible, because my Kylix installer does it.
So please give me a hint or tell me where i can find this information.

 
 
 

How to add icons and program group menu for a linux application.

Post by Kevin Kramme » Sat, 12 Oct 2002 17:28:42



> I'm writing an installer for a linux app that should look and work
> like the windows installer. Please don't tell me that i should create
> a RPM or DEB package.

> I think i found how to add an icon to the desktop. Its simply copying
> a desktop-entry file described in

http://www.freedesktop.org/standards/desktop-entry-spec/desktop-entry...

Quote:> to the $HOME/Desktop or $HOME/.gnome-desktop directories.

> But how can i add an entry/program-group to the desktop (start) menu ?
> The only thing i that seems to be able to take desktop files is the
> ".kde/share/apps/RecentDocuments" directory.

put it into one of the paths retunred by
#> kde-config --path apps
or better, in one of the subdirectories there.

This only applies for the current situation.
Bothe deskotp environments are working on the vFolder specification to
unify the location and application groups.

Cheers,
Kevin

--

Student at Graz University of Technology
http://www.sbox.tu-graz.ac.at/home/v/voyager

 
 
 

How to add icons and program group menu for a linux application.

Post by Lothar Scho » Sun, 13 Oct 2002 07:12:19


Quote:

> put it into one of the paths retunred by
> #> kde-config --path apps
> or better, in one of the subdirectories there.

Thanks, this works perfect.

Quote:

> This only applies for the current situation.
> Bothe deskotp environments are working on the vFolder specification to
> unify the location and application groups.

I hope they hurry up with there desktop integration.
http://www.freedesktop.org looks not very busy :-(

Do you also know a way how i can find out if KDE or GNOME is running ?

 
 
 

How to add icons and program group menu for a linux application.

Post by Roger Leig » Sun, 13 Oct 2002 07:59:25



> I'm writing an installer for a linux app that should look and work
> like the windows installer. Please don't tell me that i should create
> a RPM or DEB package.

You should create a DEB or RPM package, and do the job properly.
Writing your own installer is the height of arrogance and laziness (do
you really think you can create a better, more robust tool with less
effort?).  Use the tools provided to make a binary package that will
play nice with the rest of the system.  Crappy installers are the bane
of windows; don't bring them to Linux too.

Quote:> I think i found how to add an icon to the desktop. Its simply copying
> a desktop-entry file described in
> http://www.freedesktop.org/standards/desktop-entry-spec/desktop-entry...
> to the $HOME/Desktop or $HOME/.gnome-desktop directories.
> But how can i add an entry/program-group to the desktop (start) menu ?
> The only thing i that seems to be able to take desktop files is the
> ".kde/share/apps/RecentDocuments" directory.

Never EVER EVER *EVER* use the installer to add or alter files in a
user's home directory.  It's not polite.  If you must, at least give
the user the choice to say "no".  In this case, there is absolutely
*no need*.

Distributions like Debian and RedHat have a defined way of adding
programs to the menus of desktop environments and window managers
(update-menus).  Why not do it the proper way?

Quote:> I know that this is possible, because my Kylix installer does it.
> So please give me a hint or tell me where i can find this information.

The kylix installer is an abomination.  It's based on loki-installer,
which is also an abomination.  Linux is not Windows.  Throw the whole
concept of "installers" into the great Bin of History and use a
package manager, like the rest of the world.

I suggest you read up on package management.  Free Hint: there's much
more to it than copying the files blindly onto a system and putting
icons on a desktop.  For example, clean removal, upgrade, standards
compliance (e.g. Debian-Policy), dependencies, integration with the
rest of the system.

Kylix was the first and last time I tried installing a program with an
"installer", and I was very unhappy with the tons of *junk* it
installed in my $HOME.  I won't use software unless it's in DEB format
or available as source (when I can make my own DEBs).

Regards,
Roger

--
Roger Leigh
                "Liberty and Livelihood" - Support the Countryside Alliance
                Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/
                GPG Public Key: 0x25BFB848 available on public keyservers

 
 
 

How to add icons and program group menu for a linux application.

Post by Robin Rosenber » Sun, 13 Oct 2002 15:17:48



> But how can i add an entry/program-group to the desktop (start) menu ?
> The only thing i that seems to be able to take desktop files is the
> ".kde/share/apps/RecentDocuments" directory.

RPM-based distributions use a Debian program called update-menus that
do the magic. Basically you should create a menu file like the ones in
/usr/lib/menu.  Grab the source-rpm for any package that does this,
and dissect it.

Look for the menu entry that gets installed in /usr/lib/menu (or %_menudir)
a xxx.desktop file, the %install commands and %post %postun actions.

-- robin

 
 
 

How to add icons and program group menu for a linux application.

Post by Lothar Scho » Sun, 13 Oct 2002 21:12:49


Quote:> You should create a DEB or RPM package, and do the job properly.

But i can't afford the time and money to test this on all
distributions.

Quote:> Writing your own installer is the height of arrogance and laziness (do
> you really think you can create a better, more robust tool with less
> effort?).  Use the tools provided to make a binary package that will
> play nice with the rest of the system.  Crappy installers are the bane
> of windows; don't bring them to Linux too.

Under Linux with its clean separation of libraries there is no
problem. I see RPM 's and package managers very useful for system
programs but not for propritary individual licensed software. I had so
much programs starting with the task "Please became root". Most people
don't have a root account to store anything outside /temp and
/home/myname.

Quote:> Never EVER EVER *EVER* use the installer to add or alter files in a
> user's home directory.  It's not polite.  If you must, at least give
> the user the choice to say "no".  In this case, there is absolutely
> *no need*.

Why not VFolder is a clear protocol do to tasks that are also done by
windows installers.

Quote:> Distributions like Debian and RedHat have a defined way of adding
> programs to the menus of desktop environments and window managers
> (update-menus).  Why not do it the proper way?

Same as GNOME and KDE. Why should i not use the Desktop ways.

Quote:> The kylix installer is an abomination.  It's based on loki-installer,
> which is also an abomination.  Linux is not Windows.  Throw the whole
> concept of "installers" into the great Bin of History and use a
> package manager, like the rest of the world.

It worked perfect.

Quote:> I suggest you read up on package management.  Free Hint: there's much
> more to it than copying the files blindly onto a system and putting
> icons on a desktop.  For example, clean removal, upgrade, standards
> compliance (e.g. Debian-Policy), dependencies, integration with the
> rest of the system.

I have a clean installation, removal, upgrade. I don't know what the
Debian-Policy but i don't see any problem. Integration with the rest
and dependencies are a big mess and the root cause for a lot of
problems. The only way for commerical programs is to have no
dependencies (this makes the installation/download a litte bit larger)
and integrate with individual systems as less as possible, because
this binds you to one system. I think what you are missing by the most
programs is a good installation manual that exactly tells you what is
installed in what places, which files must be executable, which can be
moved etc.

Quote:> Kylix was the first and last time I tried installing a program with an
> "installer", and I was very unhappy with the tons of *junk* it
> installed in my $HOME.  

I must install my complete binary in $HOME. The reason is that it can
and should not shared by individual users. The license code is patched
into the binary at download time and valid only for a one non
concurrent user. So it is worse to install this in a place like
/usr/bin or /usr/local/bin.

And yes, what are you doing when you add some software as a normal
user and don't want to tell the system administrator ask for help ?

Quote:> I won't use software unless it's in DEB format
> or available as source (when I can make my own DEBs).

Then you don't need the software and i would not consider you a
potential customer this means you are unintersting.
 
 
 

How to add icons and program group menu for a linux application.

Post by Kevin Kramme » Sun, 13 Oct 2002 21:26:18



> I hope they hurry up with there desktop integration.
> http://www.freedesktop.org looks not very busy :-(

The specification is already done, so no cahnges to freedesktop.org
needed.

You would have to check the developer mailinglists' archives to find
out about the implementation status.

I think it is already implemented in both projects' head branches.

Quote:> Do you also know a way how i can find out if KDE or GNOME is running ?

You mean running or being installed?

Installed is easy, you just check if you can run kde-config or
gnome-config (or whatever this is called on GNOME)

Cheers,
Kevin

--

Student at Graz University of Technology
http://www.sbox.tu-graz.ac.at/home/v/voyager

 
 
 

How to add icons and program group menu for a linux application.

Post by Roger Leig » Sun, 13 Oct 2002 23:54:15


llot...@web.de (Lothar Scholz) writes:
> > You should create a DEB or RPM package, and do the job properly.

> But i can't afford the time and money to test this on all
> distributions.

http://www.easysw.com/epm/

It's used by Easy Software Products (of CUPS fame) for their
commercial products (and it's GPL, too).

As for testing, your own home-grown installer will be *much* more
unreliable on all the different distributions.  You can't expect to
get away without testing, whatever choice you make...

> > Writing your own installer is the height of arrogance and laziness (do
> > you really think you can create a better, more robust tool with less
> > effort?).  Use the tools provided to make a binary package that will
> > play nice with the rest of the system.  Crappy installers are the bane
> > of windows; don't bring them to Linux too.

> Under Linux with its clean separation of libraries there is no
> problem. I see RPM 's and package managers very useful for system
> programs but not for propritary individual licensed software.

It's just as useful.  You are shipping a program; it will have
dependencies.

> I had so much programs starting with the task "Please became
> root". Most people don't have a root account to store anything
> outside /temp and /home/myname.

???

> > Never EVER EVER *EVER* use the installer to add or alter files in a
> > user's home directory.  It's not polite.  If you must, at least give
> > the user the choice to say "no".  In this case, there is absolutely
> > *no need*.

> Why not VFolder is a clear protocol do to tasks that are also done by
> windows installers.

It's an invasion of the user's privacy to alter *their* files.  The
fact that it is done by windows installers does *not* impress me.  The
only time I saw it necessary was when the GnuPG database format
changed, and the Debian package upgrade *asked* me if I would like it
to perform the migration.  Not doing this would have resulted in a
non-functional gpg.

> > Distributions like Debian and RedHat have a defined way of adding
> > programs to the menus of desktop environments and window managers
> > (update-menus).  Why not do it the proper way?

> Same as GNOME and KDE. Why should i not use the Desktop ways.

You do not alter the *user's* files.  You put the entries into the
*system's* menus.

> > The kylix installer is an abomination.  It's based on loki-installer,
> > which is also an abomination.  Linux is not Windows.  Throw the whole
> > concept of "installers" into the great Bin of History and use a
> > package manager, like the rest of the world.

> It worked perfect.

It works.  That does not imply perfection.

> > I suggest you read up on package management.  Free Hint: there's much
> > more to it than copying the files blindly onto a system and putting
> > icons on a desktop.  For example, clean removal, upgrade, standards
> > compliance (e.g. Debian-Policy), dependencies, integration with the
> > rest of the system.

> I have a clean installation, removal, upgrade.

How do you prevent dependent shared libraries being removed?  For
example, assume your program is written in C++.  What happens when you
install gcc-3.2 and a new libstdc++ is installed.  Nothing uses the
old libstdc++ but your (non-packaged) app.  The package manager
doesn't know about your app, so it stops working.

>I don't know what the Debian-Policy but i don't see any problem.

Take a look: http://www.debian.org/doc/debian-policy/

It's a specification that all packages must conform to.  It ensures
consistency and integration with the rest of the system.

> Integration with the rest and dependencies are a big mess and the
> root cause for a lot of problems. The only way for commerical
> programs is to have no dependencies (this makes the
> installation/download a litte bit larger) and integrate with
> individual systems as less as possible, because this binds you to
> one system.

Hmm.  So, take a "simple" program that uses *just* GTK+-2.0 for a user
interface.  It depends on:

$ ldd `which gtk-demo`
        libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x40023000)
        libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x40035000)
        libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x4008d000)
        libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x4028e000)
        libXft.so.1 => /usr/X11R6/lib/libXft.so.1 (0x40296000)
        libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x402bf000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x402c4000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x402d2000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x403ac000)
        libpangoxft-1.0.so.0 => /usr/lib/libpangoxft-1.0.so.0 (0x403f8000)
        libpangox-1.0.so.0 => /usr/lib/libpangox-1.0.so.0 (0x40417000)
        libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x40423000)
        libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x40453000)
        libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x40468000)
        libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x404a0000)
        libdl.so.2 => /lib/libdl.so.2 (0x404a4000)
        libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x404a7000)
        libm.so.6 => /lib/libm.so.6 (0x4050b000)
        libc.so.6 => /lib/libc.so.6 (0x4052c000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

You aren't going to ship all of these statically linked or supply all
of the shared libs (it is *many* megabytes).  You are going to
/depend/ on them.  The fact that you pretend that your package has "no
dependencies" will not make the problem go away.  It will just make
your package fail unpredictably.

You can't avoid the problem, so you may as well accept it.  All
distributions should be ABI-compatible (I'm not saying there are no
problems), so read the LSB and do the right thing.

In addition, consider the benefits of shared libraries.  If just one
of the above libs had a security flaw or bug found, if would be *your*
responsibility to rebuild your program against the new libs and ship a
new version.  With shared libraries, it's fixed by the distribution
vendor's security/bugfix updates.

> I think what you are missing by the most programs is a good
> installation manual that exactly tells you what is installed in what
> places, which files must be executable, which can be moved etc.

Do you mean the FHS?  http://www.pathname.com/fhs/
or the LSB?  http://www.linuxbase.org/

It's also covered by Debian-Policy (go on, take a look!).

An installation manual is not something individual programs need worry
about, the specs are out there, so use them.  If you use a binary
package, the user need only learn how to use that to install all
programs.

> > Kylix was the first and last time I tried installing a program with an
> > "installer", and I was very unhappy with the tons of *junk* it
> > installed in my $HOME.  

> I must install my complete binary in $HOME. The reason is that it can
> and should not shared by individual users. The license code is patched
> into the binary at download time and valid only for a one non
> concurrent user. So it is worse to install this in a place like
> /usr/bin or /usr/local/bin.

Find a better way to check licensing.  For example, a *configuration
file* in the user's home directory.  Patching binaries is so MS-DOS
(and ugly)!

> And yes, what are you doing when you add some software as a normal
> user and don't want to tell the system administrator ask for help ?

Software should work equally well when installed in /usr, /usr/local
or a user's home directory.  Pre-compiled software should install into
a "system" location.  I would suggest /opt for proprietary software.

> > I won't use software unless it's in DEB format
> > or available as source (when I can make my own DEBs).

> Then you don't need the software and i would not consider you a
> potential customer this means you are unintersting.

                                ^^^^^^^^^^^^^^^^^^^^ ????
I will only install well-behaved software.  Custom installers that I
can't control won't cut it, and so are summarily ignored, whatever the
quality of the software

You might think that you are doing your users a favour my creating a
nice "installer", but you are only creating more problems for yourself
by taking the "easy" way.  Binary packages exist for a reason, so use
them.

--
Roger Leigh
                "Liberty and Livelihood" - Support the Countryside Alliance
                Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/
                GPG Public Key: 0x25BFB848 available on public keyservers

 
 
 

How to add icons and program group menu for a linux application.

Post by Roger Leig » Sun, 13 Oct 2002 23:54:16




> > Do you also know a way how i can find out if KDE or GNOME is running ?

> You mean running or being installed?

> Installed is easy, you just check if you can run kde-config or
> gnome-config (or whatever this is called on GNOME)

I can't speak for kde-config, but gnome-config is provided in the
development packages in most distributions, so you can't rely on it
being installed.

The best way is to depend on the right libraries, so what you need is
installed before your package is configured,

--
Roger Leigh
                "Liberty and Livelihood" - Support the Countryside Alliance
                Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/
                GPG Public Key: 0x25BFB848 available on public keyservers

 
 
 

How to add icons and program group menu for a linux application.

Post by Roger Leig » Mon, 14 Oct 2002 19:54:19


llot...@web.de (Lothar Scholz) writes:
> Roger Leigh <${rog...@invalid.whinlatter.uklinux.net.invalid> wrote in message <news:87elav90qq.fsf@whinlatter.uklinux.net>...
> > llot...@web.de (Lothar Scholz) writes:

> > > > You should create a DEB or RPM package, and do the job properly.

> > > But i can't afford the time and money to test this on all
> > > distributions.

> > http://www.easysw.com/epm/

> > It's used by Easy Software Products (of CUPS fame) for their
> > commercial products (and it's GPL, too).

> > As for testing, your own home-grown installer will be *much* more
> > unreliable on all the different distributions.  You can't expect to
> > get away without testing, whatever choice you make...

> Yes but i don't need X different distributions.

No, but with a simple $package.list file in the top level of your
source tree, you can build RPMs and DEBs with ease.  if you ever need
to target a different operating system, the tool will let you do just
that.

> Quick typing error i mean:
> Most people don't have a root account, they can't store anything
> outside /temp and /home/myname. So they will never be able to
> install the program in /usr/local/bin, /opt etc.

Then, in addition to a binary package, ship a tarball which contains
bin, lib, etc, share directories etc which can be unpacked in any
directory: $HOME, /usr/local/pkg, /usr/local etc. and still work.  A
lot of software is packaged like this.

> > It's an invasion of the user's privacy to alter *their* files.  The

> I don't alter there files. If you see the home directory as a file
> then every program that stores data in
> "$HOME/.my-program-configuration" is unpolite.

No, they are created at runtime as part of the program's normal
operation.  I have no problem with a program updating conffiles, or a
tool to perform the upgrade between two version, but the installer
shouldn't do this--require the user to run them explicitly.

> > > > Distributions like Debian and RedHat have a defined way of adding
> > > > programs to the menus of desktop environments and window managers
> > > > (update-menus).  Why not do it the proper way?

> > > Same as GNOME and KDE. Why should i not use the Desktop ways.

> > You do not alter the *user's* files.  You put the entries into the
> > *system's* menus.

> Again you are wrong, what file do i change ?

If you are running Debian, you create a file like this:
----------
?package(gnumeric):needs=X11 section=Apps/Math hints="Gnome,Spreadsheets" \
  title="gnumeric" command="/usr/bin/gnumeric" \
  icon="/usr/share/pixmaps/gnome-gnumeric.xpm"
----------
this is installed as /usr/lib/menu/$package and then the package
postinst script calls "update-menus" to have the program added to the
desktop menu.  When the package is removed, update-menus is called
again (by postrm) and the entry is removed.

> If they don't want anything like this check don't need to mark the
> checkboxes of the installer program. But most normal persons like it
> to get an icon on the desktop which they can move around (to the
> taskbar or to the trash bin).

On Windows, maybe.  I would suggest just adding it to the menus, like
above.

> > It works.  That does not imply perfection.

> The current way is much more imperfect. You seem to be the typical
> geek using Linux as a server machine.

I'm running the Gnome desktop right now.  Linux is not perfect by any
means, but the currently used package management systems are very
good.  For the inexperienced user, there exist graphical front-ends to
ease their use.

> I i don't want to spend hours to find out how i must configure my
> desktop. Thats why linux is still not considered a good desktop os.

Configuring the desktop is documented in the User Guides for Gnome and
KDE.  Individual programs have no right to be messing with an
individual user's settings though.

A "desktop" operating system can still be a "server" operating system
(whatever they are).  Some people consider GNU/Linux to be a bad
desktop OS due to a lack of applications, but it's shortcomings are
not due to installers not being able to add an icon to a user's
desktop.

> > $ ldd `which gtk-demo`
> >       libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x40023000)
> >       libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x40035000)
> >       libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x4008d000)
[snip]
> >       libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x404a7000)
> >       libm.so.6 => /lib/libm.so.6 (0x4050b000)
> >       libc.so.6 => /lib/libc.so.6 (0x4052c000)
> >       /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

> Someone developing an commercial application like this must be
> stuid:

Using libraries is stupid?  This particular program targets a
particular "platform", in this case GTK+-2.0.  It will run on any
system with the GTK+-2.0 libraries (most of this list is depended on
indirectly i.e. NEEDED by libgtk).

> I use:

>   libX11, libXext, libm, libc, libdl, libgcc_s and /lib/ld-linux.so

That's fairly minimal, so there should be few problems.

> everything else is provided with the program and event this
> libraries are just 3,2 MB more to download from our website but all
> of these are in the linux standard specifications so there is no
> problem (i'm not 100% sure about libgcc_s)

libgcc_s is the gcc support library.  It's needed, amongst other
things, for C++ exception handling IIRC.  You can rely on it being
installed.  If you write plain C, you probably use a static version.

> If you remove them it's your fault but we still cover this in our
> installation manual and FAQ.

That's fair enough.

> > In addition, consider the benefits of shared libraries.  If just one
> > of the above libs had a security flaw or bug found, if would be *your*
> > responsibility to rebuild your program against the new libs and ship a
> > new version.  With shared libraries, it's fixed by the distribution
> > vendor's security/bugfix updates.

> Yes but i have seen to many problems with persons changing some shared
> libraries and then nothing else worked. Unless you provide paid
> support i don't see this economically reasonable.

You can't prevent a user from messing their system up.  If they do
that, it's their responsibility.  If you used a binary package, the
package dependencies will prevent the program from becoming unusable
(unless they deliberately force the dependencies, which again will be
their responsibility).

With proper library versioning, there is little to worry about if the
user upgrades them (since the soname will remain constant as long as
the ABI is backward compatible).  In practice, the incompatible
library package naming schemes that the RPM-based distribution vendors
use causes many more problems.  Hopefully they will start to use a
common scheme in the future.  This is probably the biggest problem
with RPM package building, but I admit I haven't used RPM packages for
a number of years.

- Show quoted text -

> > > I think what you are missing by the most programs is a good
> > > installation manual that exactly tells you what is installed in what
> > > places, which files must be executable, which can be moved etc.

> > Do you mean the FHS?  http://www.pathname.com/fhs/
> > or the LSB?  http://www.linuxbase.org/

> No i mean what are the file that this program installed. I had to
> adminstrate the JRUN application server some time ago and it was
> terrible. No idea what the files where used to.

> > An installation manual is not something individual programs need worry
> > about, the specs are out there, so use them.  If you use a binary
> > package, the user need only learn how to use that to install all
> > programs.

> But you still have to know much more as when you are using normal
> windows installer.

dpkg -i mypackage.deb
(install)

dpkg -r mypackage.deb
(remove)

dpkg -L mypackage
(list all files in installed package)

It's not that difficult, just a matter of reading the manual.  Once
you know how to use it, you can use it to install everything, rather
than negotiating a different installer for every single piece of
software.  The installation can be interactive too, asking the user
questions and giving feedback (have a look at debconf).

Or, apt-get install mypackage (and all the dependencies are resolved,
too).  If you provided DEBs on your CD, you could just get the user to
# apt-cdrom add              (add the CD to apt sources)
# apt-get install mypackage  (do the install)

> > Find a better way to check licensing.  For example, a *configuration
> > file* in the user's home directory.  Patching binaries is so MS-DOS
> > (and ugly)!

> But an effective way to reduce piracy. If you ever have to work on
> your own selling software you would agree to my point of view.

No, it's doing it wrong.  My point has nothing to do with not agreeing
with your goal, but rather with your way of doing it.  Note that
piracy (unauthorised copying) and licensing (unauthorised use) are
generally two separate issues.  Here, we are dealing with licensing.

If you have the program installed in a standard location
e.g. /usr/local/bin/myprog, every user can run it.  However, if you
require a valid licence for each user, require them to have a valid
"key", stored as a dotfile in their $HOME.  This could be readable
only by them, and so other users (without keys) can't run it.  You
supply the key with each licence.  This was (last time I tried it) the
approach taken by vmware, and kylix where you were emailed a key which
you just pasted into a named dotfile.

If you have a program the user runs to enter the licence key, the
program can then generate a new key from that, and do whatever magic
to make it unique that it likes e.g. tie it with the MAC address and
UID.

- Show quoted text -

> > Software should work equally well when installed in /usr, /usr/local
> > or a user's home directory.  Pre-compiled software should install into
> > a "system" location.  I would suggest /opt for proprietary

...

read more »

 
 
 

How to add icons and program group menu for a linux application.

Post by Kevin Kramme » Mon, 14 Oct 2002 21:31:43



> I can't speak for kde-config, but gnome-config is provided in the
> development packages in most distributions, so you can't rely on it
> being installed.

You are right. kde-config is also part of a dev package.
I always forget that I have dev packages installed as well.

Quote:> The best way is to depend on the right libraries, so what you need is
> installed before your package is configured,

Well, if he installs from source on the target system, the target
system must ahve dev pakcges installed and then he can rely on *-config
being installed.
If he installes a binary package ist would best be done using the
target systems package manager.
If this can't be done for whatever reason, the installer will have to
look through usual directories to find the installation.
On KDE you also have the option to put all data into an own directory
and extend KDEDIRS to include it.

Cheers,
Kevin

--

Student at Graz University of Technology
http://www.sbox.tu-graz.ac.at/home/v/voyager

 
 
 

1. Adding programs to applications menu?

  How do I go about adding a program to the applications menu in X?  I
have Netscape, and I would like to be able to run it from there.  As
of right now, I either have to open a file manager, or run it from a
shell.  Thanks for any help!

---
Douglas A. Smith

WWW:  http://www.teleport.com/~dsmith

2. temporary swap file?

3. kde - icon in applications 'start' menu

4. Just questions conserning the registration and administration of Domains etc.

5. Adding icons to menus on gnome on Solaris 10

6. tekram dc-390

7. adding icons to X menu. How?

8. Xconfig for Spider Black Widow card?

9. How do I add applications to window manager menus?

10. Adding Application Icons To Desktop

11. kde- no menu icons on programs

12. how to add an application icon on the KDE desktop ?

13. program that generates list or menu of applications?