On Wednesday 13 August 2003 11.48, David Faure wrote: > On Thursday 24 July 2003 02:35, Roger Larsson wrote: > > > e) If I configure inode/directory to default to another application than > > konqueror it is ignored by konqueror... > > Would you really want konqueror to open another app every time you > click on a directory? This sounds really cumbersome... Yes it sounds cumbersome... > Associating another app to inode/directory should work, but only when > opening that dir from another app (minicli, krun, kdesktop, etc.) > But this inconsistency is even worse what was even worse was when I had specified quickshow to be the preferred one. And everyting seemed to work but not clicking on a device icon on the desktop - it, but nothing else, opened in quickview... (bug:46894) If konqueror were consistent I would never have run into this problem - I would have fixed the preferrence in a heart beat :-) > > Changing the global setting might result in really strange problems, many > > of the problems I see is related to me having changed default handling of > > a mimetype, then something seemingly unrelated breaks... > > Which global setting? "kcmshell filetypes"? yes > This is very very vague, what you're saying here. I have made a number of bug reports that have boiled down to me having a unusual mime type setting... > > > Gideon contains code that overrides the user settings to be able to open > > everything embedded, see kdevelop/src/partcontroller.cpp:249 > > * Forces all text/* to be treated as text/plain, but does some further > > special handling for text/html. Will I be able to use "quantapart" > > (whenever it becomes available) for editing html files in kdeveloper? > > BUT There is no guarantee that the user specified application for > > text/plain likes to open text/x-chdr (like in Bug 58912, kword/khtml > > does not like it) > > > > * Forces some other specific MIME types (application/x-perl, /x-desktop, > > ...) to be treated as text/plain. > > BUT it does not force others (application/x-python, /x-ruby...) > > This leads to inconsistency! > > Sounds all bad indeed (but those are gideon problems, not generic mime > problems). I think they are generic mime problems. They want to open a set of files in an embedded text editor. But the user might have specified almost anything - so they override it (hard) > > > * Allows the user to specify a preferred "EmbeddedKTextEditor". I don't > > like this option, why would I like to have another embedded text editor > > in gideon than in konqueror? > > Because one is for viewing and the other is for editing? Yes, that is one reason. I guess the other reason is to be consistent within kdeveloper. > This is why I'd suggest querying for a ReadWritePart - but then we need to > extend the component configuration (maybe not in "kcmshell filetypes", it > would get a bit too crowded, IIRC we have a component chooser module, but > that's different too)... > > > I can think of only one case - in konqueror it is read > > only and it could be a really simple and quick viewer. But then the > > override should be in konqueror instead, shouldn't it? Or should it be > > possible to specify differentiate between editor/viewer when konfiguring > > MIME types? > > Yes - see the genericServiceType argument in KTrader. > Currently it's usually Application or KParts/ReadOnlyPart. In your case it > would be KParts/ReadWritePart, and the profile could have entries for > this case (this should work already). What's missing is the user > configuration for this. Yes, Is the icon suggested below enough? > > > Suggestion: > > > > * Group selectable defaults (application and embedded) > > then Kwrite/kate could be the default for all text/* including future > > ones and only specific applications like kompare would need to be > > specified at a specific MIME type. > > selection order: text/x-diff, text/*, all/allfiles, all/all > > I think mimetype inheritance solves this better. text/x-c++hdr -> text/x-source [new!] -> text/plain -> all/allfiles -> all/all The user needs to be able to navigate in this hierarchy! And I guess we should clean things up... kate.desktop MimeType association MimeType=text/english;text/plain;text/x-makefile;text/x-c++hdr;text/x-c++src; text/x-chdr;text/x-csrc;text/x-java;text/x-moc;text/x-pascal;text/x-tcl; text/x-tex;application/x-shellscript;text/x-c;text/x-c++; Could be simplified as MimeType=text/english;text/plain;text/x-source [I guess x-makefile inherits x-source] kwrite.desktop could be simplified to MimeType=text/english;text/plain;text/x-source;text/x-tex; [Assuming application/x-shellscript and text/x-diff to inherit from text/x-source] BTW, Can the system handle kwrite having higher preference for text/plain than kate but lower than kate for text/x-source. And at the same time having lower preferrence for text/x-diff than kompare... > > > * Possible to specify embedded viewer (read only), editor (read / write). > > Like for image/jpeg > > khtmlimage is a KParts/ReadOnlyPart > > kviewviewer is a KParts/ReadWritePart > > The only thing missing is an indication/icon? of what kind of part it > > is. > > Yes. > Will this be enough - an icon? > > > * File Open dialogue > > Why isn't it possible to open a .kpr (kpresenter) file with kwords > > Open...? > > It is possible here - because there's a kpresenter->kword filter. I don't > see the relation with the discussion at hand though. Mine fails with "Could not open" even if the file is available... > > > Maybe there should be an "Open With" option? > > KWord isn't supposed to launch another app, I think there's a confusion > here. > But "Open with..." has its uses too - when working with a file you often want to edit another file in that directory (but sometimes it is of another type and not visible in the Open dialogue) > > * Quick change viewer/editor > > think khexedit for any file in gideon, I have it specified for > > "all/allfiles" > > > > Suppose all applications could easily change from the current one to > > another one that supports the mime type you are currently looking at? > > Again, not all apps are application launchers, I'm not sure this is really > necessary. If I launched KWord to edit text, I don't need an "open in kate" > menu item there, I already chose to do my editing in KWord. Maybe a "Reopen in ->" When Opening in a viewer I sometimes like to edit the file. Or do something else with it. Or maybe hexedit it... > > > Suppose that you in an application built with plug-ins easily could > > change between the plugins that support the current mime type? > > Makes sense (feel free to grab code from Konqueror :). Filing a wish! (bug:62604) -- Roger Larsson Skellefteċ Sweden