On Mon, Oct 21, 2013 at 12:26:22PM +0800, PCMan wrote:
> current vala rewrite. I checked the code and found that many things
> are hard-coded, and it only replaces XDG_CONFIG_HOME. Can we fix this
> part and hard code less stuff, putting the lubuntu-specific parts in
> the config files rather than the binary code?
I strongly second this appeal to avoid hardcoding.
I would also suggest leaving a way of overriding the config files'
contents (or at least the config file placement) by application-specific
environment variables, as much as possible.
The point is that the configuration files are to be found in some way.
Among others, this happens via an environment variable like HOME. This
variable is being used to find a _lot_ of different resources for
different programs. This means it is really hard to provide a different
configuration for a certain instance / process of one application. If I'd
reset $HOME to let it see a different config file then I'd have to copy
there the configuration for every other program which may be started by
this application instance. A command line option like --config= is nice
but not equally generic:
applicationX -> fork/exec something -> fork/exec applicationX
A command line argument is not being reapplied this way but a variable
would.
With other words I wish being able to customise differently two or more
instances of the same application to be run simultaneously on the same
computer and keep their customizations through the corresponding child
process trees, without separating the process trees into different $HOMEs.
-----
As a background please consider that we (Aetey) build applications which
are directly runnable on any Linux-like computer, they are not relying
on any local resources (and they are not to be copied to a local file
system themselves either).
As such, any local resource path assumed to be hardcoded at compile time
is artificially created pain which we have to patch around.
Actually I also see packaging LXDE for multiple different distros
separately as an unnecessary pain. When properly prepared it can be chosen
by anyone just by putting a proper line in one's ~/.xsession, without
any regard to which distro the computer administrator chose to install.
"Properly prepared" implies among others runtime configurability, when
no paths to any local file system are allowed to be hardcoded. Paths to
globally present resources are ok to hardcode, but those resources can
not reflect any local details, by the virtue of being global and for
being reusable.
This is not "just a wishful thingking", we do this for years - but the
"modern" desktop GUIs are notoriously bad in this aspect, the designers
never thought about the programs to be used globally and as a result made
bad design choices like hardcoding location of host-specific resources
or using a single environment variable to govern all parts of the system.
("Linux standardisation" efforts have been concerned about ensuring
that each and every Linux installation would have the same resources
in the same local places - this _is_ a wishful thinking.
Fortunately each and every computer can find the same resourses at the
same _global_ places, on a file system like AFS, Coda, DCE/DFS where
the paths are not host-specific and everywhere are /afs, /coda, /...)
Sorry for talking about "offtopic" issues but they influence a lot the
possibility to give every Linux user access to the best programs like
LXDE - without the traditional choices "which applications shall I install
and which versions of which libraries would collide with what?".
Regards,
Rune
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________
Lxde-list mailing list
Lxde-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxde-list
