Re: kimtoy in kdereview
El Dissabte, 18 d'agost de 2012, a les 08:45:58, nihui va escriure: > the kimpanel dbus specification used is the same, while the implementation > in frontend is different kimpanel plasmoid use three level communication > with input method framework, fcitx/ibus/scim <-> im glue <-> plasma > dataengine <-> kimpanel and kimtoy, fcitx/ibus/scim <-> im glue <-> kimtoy > im glue is a small app for bridging between native input method framework > interface and kimpanel dbus interface, and it is the only piece of code > currently shared You may even find that these im glues in kimpanel plasmoid > are forked from kimtoy. > > sharing these im glues does make sense, but it also means to use the same > repo for hosting kimtoy and kimpanel plasmoid, and that is not possible > unfortunately. Well, you could also do a library, since that's what libraries are for, sharing code. Anyway I won't block kimtoy moving to extragear for this. Cheers, Albert > > > best wishes, > nihui > > At 2012-08-17 04:55:30,"Albert Astals Cid" wrote: > >El Dijous, 16 d'agost de 2012, a les 13:06:55, nihui va escriure: > >> hi > >> > >> Yes, we have kimpanel plasmoid in plasma-addons, and we have skim for > >> scim > >> in old kde3 days. kimtoy is technically the standalone version of > >> kimpanel > >> plasmoid with many additional features. Both kimtoy and kimpanel plasmoid > >> are strictly not input method framework like ibus, they act as > >> frontend(or > >> panel) for the underlying input method frameworks. Users can still > >> write/type using ibus built-in frontend without KDE ones, but some nice > >> intergrations between KDE and input method frameworks will be missing, > >> such > >> as storing ibus settings in kconfig instead of gconf/dconf and consistent > >> style in KDE environment, etc. > >> > >> the benefits of kimtoy over the current kimpanel plasmoid includes: > >> no dependence on a running plasma desktop, you can use it in other DE > >> like > >> xfce... kconfig intergration for ibus and scim > >> very powerful theming support and customization > >> more intergration, thumbnailers and strigi analyzers > > > >Is there any chance in sharing code between kimtoy and kimpanel plasmoid? > >Or it doesn't make sense? > > > >Cheers, > > > > Albert > > > >> best wishes, > >> nihui
Re: Review Request: Remember current desktop when changing activity
Am Dienstag, 13. März 2012, 18:53:29 schrieb makis marimpis: > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/104261/ > --- > > Review request for KDE Runtime. > > > Description > --- > > Patches kactivitymanagerd to store (and restore back) the working current > directory when switching activities. > > The activity-changing-behavior is as follows: > 1. Say you have two (or more activities) A and B. > 2. You are working on activity A on Desktop 4. > 3. You switch to activity B (and by default to Desktop 4). > 4. Change to Desktop 1. > 5. Go back to activity A and (by default) to Desktop 1, while it should > move you to Desktop 4 (this is where my patch kicks in). > > I hope it makes sense :-) Your description: yes. The change: no. I've tried to get used to it now for weeks. I find it utterly confusing the way it now is and it actually disturbs my working whenever I switch activities. Can we get a way to disable this? Doesn't even need a GUI in the first step. My usage is like this: I have a set of virtual desktops, every has a special meaning (e.g. 5 is konsole). It often happens that I want to just compare 2 similar things, so I e.g. got to desktop 5, look at the terminal, switch activity and am not where I like to be. In general I do not know on which desktop I have been in the activity 5 minutes before. What do I care? I don't even remember. I know where I want to go now. Going back to a place I don't remember has no meaning in that kind of workflow. I understand it may have for other people using different workflows, but for me it actually confuses me when I try to work. Thinking a bit more I just do "I want a terminal" so I go to desktop 5. If it's not the right one I switch to the other activity (I usually only have 2) and end up "somewhere" which may only accidentially be the right place, but usually isn't. Greetings, Eike signature.asc Description: This is a digitally signed message part.
Re: Review Request: Remember current desktop when changing activity
Yeah i read a bug report about this (new) behavior. It would be fair to support all perceptions of activities (because of their abstract meaning). Ivan mentioned that in @4.10 there will be a KCM for activities, i believe that we could add some kind of an option. Makis -- i am thatguy.gr
Re: Review Request: Remember current desktop when changing activity
Am Samstag, 18. August 2012, 20:19:55 schrieb makism: > Yeah i read a bug report about this (new) behavior. It would be fair to > support all perceptions of activities (because of their abstract meaning). > Ivan mentioned that in @4.10 there will be a KCM for activities, i believe > that we could add some kind of an option. As I said: adding it to just a config file first would be fine with me. Eike signature.asc Description: This is a digitally signed message part.
Re: Review Request: KWallet Password Prompt Dialog In Your Face
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105628/#review17676 --- This review has been submitted with commit 9c38b48fb37747de3708a75d73c1f428ece72100 by Allen Winter to branch master. - Commit Hook On Aug. 4, 2012, 12:35 p.m., Allen Winter wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/105628/ > --- > > (Updated Aug. 4, 2012, 12:35 p.m.) > > > Review request for KDE Runtime, David Faure and Fredrik Höglund. > > > Description > --- > > This is an attempt to make the KWallet password prompt much harder to ignore > or miss. > > Now the prompt should always be in front of the parent window. and it should > unminimize if needed, and demand attention. > > [UPDATE] I'm reopening as I still think this is needed, even in 4.9. > I changed the things that gave people heartburn in my first attempt, notably > removing the usertime=0 > > > Diffs > - > > kwalletd/kwalletd.cpp 309c45f > > Diff: http://git.reviewboard.kde.org/r/105628/diff/ > > > Testing > --- > > Just using it in various scenarios. > For example, if the akonadi maildispatcher needs to open kwallet now the > password prompt is always in front of kmail > > [UPDATE] Without the usertime=0, you can still move kmail in front of the > password prompt dialog. but at least you see the prompt first. > > > Thanks, > > Allen Winter > >
Re: Review Request: KWallet Password Prompt Dialog In Your Face
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105628/#review17677 --- This review has been submitted with commit 3cee7d5d8f185a7b11d64ba3b2094db78e3d855a by Allen Winter to branch KDE/4.9. - Commit Hook On Aug. 4, 2012, 12:35 p.m., Allen Winter wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/105628/ > --- > > (Updated Aug. 4, 2012, 12:35 p.m.) > > > Review request for KDE Runtime, David Faure and Fredrik Höglund. > > > Description > --- > > This is an attempt to make the KWallet password prompt much harder to ignore > or miss. > > Now the prompt should always be in front of the parent window. and it should > unminimize if needed, and demand attention. > > [UPDATE] I'm reopening as I still think this is needed, even in 4.9. > I changed the things that gave people heartburn in my first attempt, notably > removing the usertime=0 > > > Diffs > - > > kwalletd/kwalletd.cpp 309c45f > > Diff: http://git.reviewboard.kde.org/r/105628/diff/ > > > Testing > --- > > Just using it in various scenarios. > For example, if the akonadi maildispatcher needs to open kwallet now the > password prompt is always in front of kmail > > [UPDATE] Without the usertime=0, you can still move kmail in front of the > password prompt dialog. but at least you see the prompt first. > > > Thanks, > > Allen Winter > >
Re: Review Request: Focus goes to location bar when opening link in new tab in foreground
> On Aug. 17, 2012, 8:29 p.m., David Faure wrote:
> > Not a strong objection, but KonqViewManager::doSetActivePart is supposed to
> > do this already, so I'm surprised it doesn't work?
> >
> > If that method isn't called in your case, then OK.
Well I finally figured out why this was happening! Believe it or not it is due
to a fix for another bug in konqFrame::activateChild(). Below is the sequence
of actions that result in the aforementioned bug report and potentially also
bug# 304865.
When KonqMainWindow's slotCreateNewWindow function is called, it calls
KonqViewManager::showTab when it is configured to put the newly created tab on
top. This happens in either slotCreateNewWindow (line #1221) itself or in the
subsequent call to openUrl (line# 596).
KonqViewManager::showTab calls KonqFrameTabs::setCurrentIndex to change the
current active tab to the new tab. KonqFrameTabs::setCurrentIndex is actually
QTabWidget::setCurrentIndex which emits the signal QTabWidget::currentChanged.
KonqFrameTabs connects the QTabWidget::currentChanged signal to its slot
KonqFrameTabs::slotCurrentChanged. KonqFrameTabs::slotCurrentChanged then ends
up calling KonqFrameBase::activateChild (which is KonqFrame::activateChild).
And in KonqFrameBase::activateChild we have the offending code @ line # 226-228:
if (m_pView->url().isEmpty() || m_pView->url() == "about:blank") {
m_pView->mainWindow()->focusLocationBar(); // #84867 usability
improvement
}
>From your commit log, the above fix seem to have been applied elsewhere but
>was moved here by you so that it won't cause another regression. Commit
>revisiion de3e94e9 says:
Re-do the usability fix #84867 in a way that doesn't introduce #208821:
focus the location bar when actively (as a user) switching to an empty tab,
but not when loading a tab which will soon get content.
Fixed for: 4.5
BUG: 208821
So in short, a fix for a regression (208821) caused by a fix for a bug (84867)
is caused yet another regression (304933). Not sure what the appropriate fix
here just yet. We actually have to find a way to fix 84867 without causing the
other two regressions or any new ones for that matter.
- Dawit
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105984/#review17622
---
On Aug. 11, 2012, 3:58 p.m., Dawit Alemayehu wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105984/
> ---
>
> (Updated Aug. 11, 2012, 3:58 p.m.)
>
>
> Review request for KDE Base Apps and David Faure.
>
>
> Description
> ---
>
> The attached patch address the bug reported in #304933. Right now if
> Konqueror is configured to open new tabs in the foreground, i.e. the "Open
> tabs in the background" option is unchecked, then the keyboard focus is put
> on the location bar instead of the view.
>
>
> This addresses bug 304933.
> http://bugs.kde.org/show_bug.cgi?id=304933
>
>
> Diffs
> -
>
> konqueror/src/konqmainwindow.cpp 6faba58
>
> Diff: http://git.reviewboard.kde.org/r/105984/diff/
>
>
> Testing
> ---
>
>
> Thanks,
>
> Dawit Alemayehu
>
>
Re: Review Request: Remember current desktop when changing activity
Στις 18/08/2012 08:25 μμ, ο/η Rolf Eike Beer έγραψε: Am Samstag, 18. August 2012, 20:19:55 schrieb makism: Yeah i read a bug report about this (new) behavior. It would be fair to support all perceptions of activities (because of their abstract meaning). Ivan mentioned that in @4.10 there will be a KCM for activities, i believe that we could add some kind of an option. As I said: adding it to just a config file first would be fine with me. Eike Eike, I dont want to intrude, I just want to ask a question, is the following plasmoid corresponds to your spesific workflow? https://vimeo.com/45061682 it's going to be released in about a month... Regards, Michail.
