[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: ui.rc file location
From:       Fred <fmalabre () yahoo ! com>
Date:       2003-04-30 0:11:43
[Download RAW message or body]

I just read the whole thread now.
I agree with Sarang. It doesn't make sense to have to install the ui.rc when 
you are developing your application.

I think you should be able to work on a development version without afecting 
the production version.
I understand there are ways to do that with modifying the use profile, but it 
still doesn't make sense to me to have 2 different profiles depending of what 
version of the application you want to run - as they are 2 completly 
different binaries.

A good solution I can think about now would be to search for the ui.rc in the 
working directory first, and is not found search in the standard KDE 
directory (as it does today).
I don't see any bad impact of doing that, and that would solve this problem.

What I'm doing now is to put the full path of my ui.rc file in the code when I 
develop, and I'm not very happy with this solution.

Fred.

On Tuesday 29 April 2003 05:48 pm, Thiago Macieira wrote:
> Sarang Lakare wrote:
> >This is the best work-around mentioned till now I guess.. but it is still
> > not a solution.
> >
> >I havn't seen a single satisfying argument for not looking at the current
> >working directory for .rc file before the system directories. The behavior
> > in KDE 3.0 was right and should be restored IMHO. If there is an
> > important reason for not doing it that way, then I would like to know it?
>
> You have an ui.rc on your application. Imagine what would happen if another
> application also expects an ui.rc. If you run it, it'll be completely
> garbled.
>
> There's a reason why application-specific files go in application-specific
> directories.
>
> What I could argue, though, is that you should be able to set this on the
> environment. That would help KDevelop.

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]