In KDE 4, you can open a new window for Kate via “View -> New Window”.
This won’t start a new application instance but just add an other Kate main window to the current instance (which shows the same documents & session & projects).
This is kind of complex to handle internally and we think about dropping that behavior and instead launching just an other Kate application instance if you trigger that menu action.
Pro: Easier code structure, less to maintain, less bugs. Each window is an own process, e.g. if one crashs, not the others die, too.
Contra: You will loose the have the same documents open in two windows with syncing (as the two windows would then be individual processes).
Any opinions about that out there in the lazy web? Feedback is welcome.
After the initial porting of KTextEditor interfaces and KatePart, now the Kate application itself runs on KF5, too.
It still has a LOT of issues (and I marked all commented out pieces with FIXME KF5), but at least, it launches and loads the essential file tree plugin and allows you to open files via the “Open” action. Any help in fixing the remaining issues is welcome (and removing deprecated cruft), but keep in mind, it might eat all the files you edit
That means now all stuff in the “frameworks” branch of kate.git beside the “addons” directory containing plugins/plasma stuff at least compiles and launches with KF5.
Now the question is how we handle further development. Shall we switch to “frameworks” for all major stuff in interfaces/part/application and only let feature work be done in the “master” branch for addons (which we then can port later on)?
Feedback is welcome 😉
After starting the “frameworks” branch in kate.git more than a week ago but doing not much beside an initial KTextEditor compile & link port I felt a big guilty 😉
Given a lot of people blog about the progress of programs X and Y for Qt 5.2 and KDE Frameworks 5 I guess it is time that KatePart joins this club.
Some hours later, a ‘working’ version of KatePart and KWrite have landed in the “frameworks” branch of kate.git. KWrite launches, loads the part and the open action even works (command line parsing is off-line btw. ATM).
From the let it run 😉 commit on, KWrite should at least launch and open files via file dialog and here is the mandatory screenshot (a KDE Frameworks 5 KWrite over an Kate 4.x window):
I marked all places where I commented stuff out or did a hack with “FIXME KF5″ in a comment or “#if 0″ region. Help welcome, Kate application still to be ported 😉 But please mark your “hacks” in the same fashion, otherwise, we will never find them again.
To remember the history, the initial KatePart KDE 4 port happened more than 8 years ago, here a screenshots of that time (2005-05-15):
I think the first KDE Frameworks 5 version looks a bit better. Thanks a lot for all the people getting both the kdelibs frameworks branch in such good shape and all the contributors to Qt 5.x!
The Kate team will do its best to make the KDE Frameworks 5 version of Kate as popular as the 4.x variant is.
After thinking some days about how to tackle the 4.x => 5.x transition in Kate (KTextEditor/Part/Application) and the nice “what we should do” blog by Dominik, I think the time for fun is there.
Therefore I started to port our stuff to KF5 in the “frameworks” branch.
The basic idea would be: get it compiling and running.
Then we can decide if the frameworks branch is a mere “hack to see if it works” experiment which can be later used to port master without a lot of work or if we say “ok, works kind of well” and we just switch development over for new features from master to frameworks and with that from 4.x to 5.x.
The KTextEditor interfaces compile now, KatePart should be the next thing to tackle. Then KWrite and Kate.
Happy hacking 😉
(To get a working KF5 development environment, just follow this howto.)