New document switching mode (2)

Jens Zurheide jens.zurheide at gmx.de
Mon Feb 3 23:30:06 UTC 2003


>> Hi, folks!
>>
>> I have finished the implementation of the switching mode that allows
>> ordering the windows by the time they were last activated. It is either
>> possible to switch by opening order (the current default) or by last
>> viewed
>> sort order.
>
>last viewed should be default, shouldn't it?
As always it's a matter of taste, isn't it?  The default is set in 
parts/uimode/uichooser_widget.cpp. Search for SwitchByTime...

[...]
>Often hearing about Kate problems that can only be solved with an upgrade
> to the next KDE version, we should consider to set QEditor as default
> because we have control about it and we might declare it as stable and
> tested with a certain appropriate KDevelop release.
Then we are back to the days of the KDevelop kwrite branch. An editor that 
nobody except us develops and uses. Not really what code reusage means. On 
the other hand I can live with the current situation. We (more precisely 
you) are developing and encounter bugs in kate along the way. The new 
features in KDevelop that triggered the kate bug will be available with the 
next release of KDevelop and as it was agreed (or did I miss something) 
that KDevelop is tied to the KDE releases the fixed kate will be available 
as well. I think it might be interesting to look into possibilities to 
generate and ship only a kate part from the release branch instead of the 
whole kdelibs. This would give us a certain amount of control over kate

>> One QextMdi problem that drove me nuts but I could not fix it was that
>> after
>> opening the project with windows in maximized childframe mode the
>> children
>>
>> are not maximized.
>> However they get immediately maximized when clicking
>> into one ore selecting by switching to next/prev. window. It seems that
>> the
>> windows are created when no TopLevel is available. Falk, maybe you could
>> have a look for this. Otherwise I would rate it as cosmetic ;)
>
>This problem is a event race condition. I fixed this already in good old
>KDevelop-2 with a workaround. We just have to port it over...
(Who is "we"? Because "we" tends to become "somebody" or even "nobody" very 
easily.)
[...]
>
>What are the default accels now?
I am not sure but as far as I remember it is something with Alt-PageUp/Down 
or Alt-Left/Right. The usual accels that are assigned to "Next window" and 
"Previous Window".
>
>> Another thing that is not supported is the assignment of fixed
>> accelerators
>> to views like Alt-1, Alt-2.
>
>We await your next patch! ;)
Better don't hold you breath until it arrives. Your facial colour might look 
rather unhealthy at this point in time (probably not only blue). If I have 
time to look into it what would be the cleanest solution? Part or usual 
dialog?

Finally, what happens with this patch? I don't have a CVS account and 
probably don't need one with my current productivity rate.

Regards,
Jens






More information about the KDevelop-devel mailing list