156100 2008-01-18 14:04:25 +0000 plugins are disabled when opening a file from command line 2010-10-26 23:38:45 +0000 1 1 2 Applications kate sessions unspecified Compiled Sources Linux RESOLVED DUPLICATE 159767 NOR normal --- 1 brandon.ml kwrite-bugs-null blizzz bluedzins finex lucas 80 oldest_to_newest 572724 0 brandon.ml 2008-01-18 14:04:25 +0000 Version: (using Devel) Installed from: Compiled sources OS: Linux if you open a file from command line i.e. kate file.extension, kate doesn't load plugins(file system browser, terminal etc..) 572862 1 finex 2008-01-18 21:04:24 +0000 Confirmed on revision 762662 572867 2 anderslund 2008-01-18 21:25:41 +0000 The plugin configuration is session specific, so you need to configure the defaults. I don't know if there are ways we can improve this - by makeing it easier to save defaults, for example by asking, or making it more obvious that it is session configuration that is saved, or ... 572932 3 23127 ereslibre 2008-01-19 02:30:50 +0000 Created attachment 23127 Fix for this problem On 3 branch we had at kateapp.cpp::startupKate() method: // user specified session to open if (m_args->isSet ("start")) { sessionManager()->activateSession (sessionManager()->giveSession (QString::fromLocal8Bit(m_args->getOption("start"))), false, false); } else { // let the user choose session if possible if (!sessionManager()->chooseSession ()) { // we will exit kate now, notify the rest of the world we are done KStartupInfo::appStarted (startupId()); return false; } } now on the else part on the 4 version we also force: else if (!m_args->isSet( "stdin" ) && (m_args->count() == 0)) // only start session if no files specified This means that the tabs added by activateSession() are never added. The proposed patch relaxes the first part of the if(). On the KDE 3 version, if you do "kate foo.txt" you are still asked for a session. I think that was "wrong". This way this is fixed, the asked file is opened and the session is "activated". All the magic is at startupKate() method. OK to commit ? 572939 4 23128 ereslibre 2008-01-19 02:49:02 +0000 Created attachment 23128 Fix for this problem (take 2) This patch is very similar to the other proposed, but it is slightly more polite, doesn't mix things. Anyway has the same effect. Can be easier to understand. Can this patch be committed ? 572989 5 anderslund 2008-01-19 09:45:21 +0000 We need to always start the default session, which should be implicit if i remember correctly. Is that what happens with the last patch? 572998 6 dhaumann 2008-01-19 10:26:28 +0000 Using giveSession(i18n("Default Session")) should use use the default session. 573006 7 ereslibre 2008-01-19 11:23:59 +0000 I disagree. We shouldn't open the default session. The default session can be opened for instance if we do "kate" without parameters. If we add a file to the parameters list of the kate executable, then what we expect to see is that list of files opened. If your default session had 100 files and we do "kate foo1.txt foo2.txt foo3.txt" we will have with your proposal 103 files, when we wanted to modify foo1.txt foo2.txt and foo3.txt. Trying to make things easier we could try to close the rest, and only having what I expected on the files list. That could result on a overwrite of my default session with the 3 files instead of the 100 that I had before if I exit and the auto-save-session feature is enabled. I really think we should ask for giveSession(QString()). If you think i18n("Default Session") still should be used, just tell here and I will commit the same patch as the last one but instead QString(), i18n("Default Session"). 573012 8 anderslund 2008-01-19 11:54:27 +0000 The default session should *be* katerc in my opinion. That would load all the default settings, and settings would automatically be saved there when no other session is selected. I do see the problem with files, but maybe we should simply disable that in the defaults. But it is an area that needs consideration, as it is NOT well thought out as is. My take is * we should always have a session, because some data otherwise can't be saved (for example recent files) * If no session is specified the session file should default to katerc. * If files are given on the command line, the file list should only be loaded if a session is also explicitly given 573014 9 ereslibre 2008-01-19 12:09:52 +0000 > My take is > > * we should always have a session, because some data otherwise can't be > saved (for example recent files) The proposed patch activates a session with no name. It is *only* done so when we give parameters to kate executable. If you run "kate" only you will be asked for a session (or not) depending on your katerc preferences. The only thing that can break those preferences is to give files to be opened as parameters. > * If no session is specified the session file should default to katerc. > > * If files are given on the command line, the file list should only be > loaded if a session is also explicitly given From my point of view what Kate on KDE3 does here is in some way, wrong. If you have kate configured to ask you for a session when loading, it will still ask you for a session when you give files to be opened as parameters. From my point of view that is wrong. When you specify files as parameters to the executable you want to start editing them at the moment, and don't care about he session. In that case you should have opened "kate", opening the session for later opening those files inside kate. 573016 10 anderslund 2008-01-19 12:15:49 +0000 On Saturday 19 January 2008, Rafael Fern 573017 11 anderslund 2008-01-19 12:16:43 +0000 On Saturday 19 January 2008, Rafael Fern 573018 12 ereslibre 2008-01-19 12:27:05 +0000 Hehe, and that is what the last attached patch does. :) - Running "kate" will ask for your session or not, depending on your preferences there. That is not touched. - Running "kate file1 file2 ... fileN" will not ask for session. Never. It will just open those files in a session with no name, activating the session, and therefore using the defaults from katerc. 573022 13 anderslund 2008-01-19 12:38:48 +0000 I think the missing part is just making session data be saved to katerc as well. And I think we should loose the autocreated 'default session'. 573025 14 finex 2008-01-19 12:45:45 +0000 When a user launch kate with a list of files, kate should open that list, without extra parameters and esotheric sessions management :-) Just open that files. 573031 15 ereslibre 2008-01-19 13:07:20 +0000 I am afraid those preferences weren't saved before either. Just check it. Without the patch if you disable the "Terminal" complement for instance on a session, close kate and open the session the terminal complement will be loaded anyway. So the patch is unrelated to that problem. That problem is apart as far as I see. 573629 16 anderslund 2008-01-21 14:01:41 +0000 On Saturday 19 January 2008, FiNeX wrote: > When a user launch kate with a list of files, kate should open that list, > without extra parameters and esotheric sessions management :-) > > Just open that files. That is a stupid comment simply. Kate needs to load and save its configuration in a way that makes sense, which is obviously not the case currently. 660164 17 finex 2008-11-04 09:59:52 +0000 It is not stupid: it's what, imho, users needs (or at least I'd like). If internally kate needs to load settings, in this case it should simply use the default settings. Probably an user which starts kate from the shell, is a bit more skilled than one which starts it from the GUI, probably the default settings should be good enough for him :-) But this is only my opinion, maybe it due to a limited vision of the whole problem. Anyway, I've just tested the current trunk and the problem reported initially seems fixed now! :-) 759344 18 dhaumann 2009-05-17 23:25:42 +0000 related: bug #156330 921516 19 dhaumann 2010-02-21 00:53:57 +0000 *** Bug 126952 has been marked as a duplicate of this bug. *** 1037464 20 dhaumann 2010-10-26 23:38:45 +0000 Yes, it's fixed because Anders funnily enough fixed it 3 months later in another report with a very similar patch. So mark as duplicate! :) *** This bug has been marked as a duplicate of bug 159767 *** 23127 2008-01-19 02:30:50 +0000 2008-01-19 02:49:03 +0000 Fix for this problem kate.diff text/plain 512 ereslibre SW5kZXg6IGthdGUvYXBwL2thdGVhcHAuY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGthdGUvYXBwL2thdGVh cHAuY3BwCShyZXZpc2nDs246IDc2Mjg0MSkKKysrIGthdGUvYXBwL2thdGVhcHAuY3BwCShjb3Bp YSBkZSB0cmFiYWpvKQpAQCAtMTU2LDcgKzE1Niw3IEBAIHZvaWQgS2F0ZUFwcDo6cmVzdG9yZUth dGUgKCkKIGJvb2wgS2F0ZUFwcDo6c3RhcnR1cEthdGUgKCkKIHsKICAgLy8gdXNlciBzcGVjaWZp ZWQgc2Vzc2lvbiB0byBvcGVuCi0gIGlmIChtX2FyZ3MtPmlzU2V0ICgic3RhcnQiKSkKKyAgaWYg KG1fYXJncy0+aXNTZXQgKCJzdGFydCIpIHx8IG1fYXJncy0+Y291bnQoKSkKICAgewogICAgIHNl c3Npb25NYW5hZ2VyKCktPmFjdGl2YXRlU2Vzc2lvbiAoc2Vzc2lvbk1hbmFnZXIoKS0+Z2l2ZVNl c3Npb24gKG1fYXJncy0+Z2V0T3B0aW9uKCJzdGFydCIpKSwgZmFsc2UsIGZhbHNlKTsKICAgfQo= 23128 2008-01-19 02:49:02 +0000 2008-01-19 02:49:02 +0000 Fix for this problem (take 2) kate.diff text/plain 507 ereslibre SW5kZXg6IGthdGUvYXBwL2thdGVhcHAuY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGthdGUvYXBwL2thdGVh cHAuY3BwCShyZXZpc2nDs246IDc2Mjg0MSkKKysrIGthdGUvYXBwL2thdGVhcHAuY3BwCShjb3Bp YSBkZSB0cmFiYWpvKQpAQCAtMTczLDYgKzE3MywxMCBAQCBib29sIEthdGVBcHA6OnN0YXJ0dXBL YXRlICgpCiAgICAgICByZXR1cm4gZmFsc2U7CiAgICAgfQogICB9CisgIGVsc2UgaWYgKG1fYXJn cy0+Y291bnQoKSkKKyAgeworICAgIHNlc3Npb25NYW5hZ2VyKCktPmFjdGl2YXRlU2Vzc2lvbiAo c2Vzc2lvbk1hbmFnZXIoKS0+Z2l2ZVNlc3Npb24gKFFTdHJpbmcoKSksIGZhbHNlLCBmYWxzZSk7 CisgIH0KIAogICAvLyBvaCwgbm8gbWFpbndpbmRvdywgY3JlYXRlIG9uZSwgc2hvdWxkIG5vdCBo YXBwZW4sIGJ1dCBtYWtlIHN1cmUgOykKICAgaWYgKG1haW5XaW5kb3dzKCkgPT0gMCkK