Dotan Cohen wrote:
> 2009/5/20 James Richard Tyrer <tyrerj@xxxxxxx>:
>> Dotan Cohen wrote:
>>>> You are correct. I did find the dialog that I used in KDE-3 and checked
>>>> the box, but more research indicates that it simply does not work. So,
>>>> you need to file a bug report. This is a problem, not a feature
>>>> request. Please post the bug number here.
>>>>
>>> https://bugs.kde.org/show_bug.cgi?id=191846
>>>
>> I think that the remote opening is a separate issue from using a default
>> session.
>
> Remote opening? To what are you referring?
>
Having a new file opened in the currently running instance of the
application rather than opening an additional instance of the application.
>> Although, you could also argue that the behavior in KDE-3.5 is
>> strange and, therefore, a bug.
>>
>
> I though that the KDE 3 behaviour was logical: trying to open another
> instance would open a new tab (document) in Kate, so long as the user
> configured it for such.
>
Yes, that part makes sense.
Create two new test text files to test this.
Click the first one and open in KATE.
Click the second one and open in KATE.
Now you have two instances of KATE, but the instance you opened second
does not list the test file you opened first. This would appear to be a
bug or it is simply an undesired side effect of the fact that sessions
are not automatically updated.
>> Actually, I would argue that remote opening should either be the default
>> behavior and the command line option be changed to "+u" to disable this,
>> or there should be 'desktop' files (menu entries) for both. I note that
>> The GIMP is installed as remote opening *only* by default although it
>> is possible to install it the other way if you want.
>>
>> That is, would you ever want more than one instance of the same session?
>
> Yes, when making multiple changes to the HTML code of a particular
> website, for instance.
>
Yes, then you can open an additional window from the running instance.
>> That is unless you opened additional windows from the application?
>>
>> However, if it doesn't work the same in KDE-4.2 or KDE-Trunk as it does
>> in KDE-3.5, that is a bug, not a wish-list item and we need a separate
>> bug report for that.
>>
>
> KDE devs consider deviation from KDE 3 to _not_ be a bug. Same for
> missing features. It is as if KDE 4 is a separate project entirely,
> which in essence it is. Requests for "KDE3-like" are feature requests,
> not bugs.
>
I don't know what is wrong with the developers. Apparently any excuse
not to fix a bug is acceptable.
Does this mean that anything that doesn't work correctly is a wish-list
item? I think not. This is not a reason not to file a bug, and it is
not a valid excuse to close a bug. It is only a valid reason to close a
bug if the change in behavior was intended.
Files in the Default Session are not saved. How are we to know if this
is a bug or a deliberate change? This is why software engineering
projects need specifications -- otherwise, how are you to know if
something is a bug or not.
So, if that excuse is being used, then you should not mention that the
behavior in KDE-4 is not the same as in KDE-3 when filing a bug.
IAC, the way that KATE deals with the Default Session in KDE-4 has
problems. I can analyze the inconsistent behavior, but I can't really
determine how it was intended to work. Actually, when something is
developed by hacking (writing the code without designing it first),
there is some question of whether or not anyone knows how it is actually
supposed to work.
Specifically, is the session "Default Session" supposed to act like any
other named session or is is supposed to be treated differently?
--
JRT
Linux (mostly) From Scratch
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
