Re: merging development branch into master

[Shaun Reich]

well, you've got until november 8th (4 days according to my clock) until
hard feature freeze which blocks even those on the planned feature list.

so, as my procrastinating self would say you've got "plenty of time" ;)


-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: merging development branch into master

[Shaun Reich]

>* I guess once the branch is merged it should be closed for business:
fixes go >into master and new features go into new branch, right?

yup, well. assuming that we are at/past the feature freeze at that point.

thing is...was this added to the feature page? (if not it cannot be merged
this cycle)

http://techbase.kde.org/Schedules/KDE4/4.10_Release_Schedule#Thursday.2C_October_25.2C_2012:_KDE_SC_4.10_Soft_Feature_Freeze


additionally, shouldn't we do this on reviewboard so everyone can check it
out? i realize it's a bit a pain with big old branches, but would be the
best.

-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: How Can I change wallpaper from CLI?

[Shaun Reich]

On Wed, Sep 5, 2012 at 10:53 AM, Tomaz Canabrava  wrote:
> 2012/9/5 Weng Xuetian :
>> On Wed, Sep 5, 2012 at 9:48 AM, kevinzhow  wrote:
>>> hello~
>>>
>>> Sorry to brother,I don not know which channel should i send this mail 
>>> exactly , so i send this mail to kde, kde-devel and ode-core-devel, but i 
>>> really need this help,  please
>
> This looks like the KDE Get Hot New Stuff for the desktop wallpaper,
> from your screenshoots.
> why don't you create a backend for the GetHotNewStuff for your wallpapers?
>

there's more to it than just "a source for wallpapers" afict, so i
don't think that's a valid solution.

Re: [RFC] Merging LightDM into KDE Workspaces (forwarded from plasma-devel)

[Shaun Reich]

On Mon, Aug 27, 2012 at 10:02 PM, Martin Sandsmark
 wrote:
> Now I'm really confused, isn't the wallpaper just set in /etc/kde4/kdm/kdmrc?

not if you're in themed mode. in which case the theme specifies it, afik


-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: Review Request: Use a qml based screen locker in place of the screensaver

[Shaun Reich]

> On Aug. 22, 2012, 8:38 p.m., Ben Cooksley wrote:
> > From what I recall a new screensaver framework was promised - please see 
> > http://forum.kde.org/viewtopic.php?f=66&t=97102
> > Where is the new Framework?

The "new framework" mentions Qt Quick being used to create future screensavers 
easily. In order for that to happen, it'd need QML 2, since only that allows 
arbitrary exposing of shaders.


- Shaun


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106124/#review17883
---


On Aug. 22, 2012, 6:07 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106124/
> ---
> 
> (Updated Aug. 22, 2012, 6:07 p.m.)
> 
> 
> Review request for KDE Runtime.
> 
> 
> Description
> ---
> 
> this is the finalization of the old "screenlocker" branch in workspace:
> the screen saver goes away (discussed at the time, about one year ago) and 
> the screen locker gets managed by ksmserver, with a greeter that has the ui 
> dine in qml.
> The same qml ui gets loaded by the plasma based greeter when the "allow 
> widgets on screen locker" is enabled.
> the screensaver kcm is now called "Screen locker" and is way simpler, the 
> screen saver chooser is gone from it.
> 
> 
> Diffs
> -
> 
>   kcontrol/screensaver/CMakeLists.txt e4dcc3a 
>   kcontrol/screensaver/Messages.sh 5c727f2 
>   kcontrol/screensaver/config-screensaver.h.cmake 9a789fc 
>   kcontrol/screensaver/kssmonitor.h 0cf5162 
>   kcontrol/screensaver/kswidget.h b4631bd 
>   kcontrol/screensaver/kswidget.cpp 29f78fd 
>   kcontrol/screensaver/saverconfig.h c422625 
>   kcontrol/screensaver/saverconfig.cpp 089068f 
>   kcontrol/screensaver/screenlocker.desktop PRE-CREATION 
>   kcontrol/screensaver/screenlocker.ui PRE-CREATION 
>   kcontrol/screensaver/screensaver.desktop aa1a861 
>   kcontrol/screensaver/screensaver.ui 0ad5cd8 
>   kcontrol/screensaver/scrnsave.h 7c8deba 
>   kcontrol/screensaver/scrnsave.cpp c0507d4 
>   kcontrol/screensaver/testwin.h 46b9aa7 
>   kcontrol/screensaver/testwin.cpp e8ea014 
>   krunner/CMakeLists.txt 21eac6f 
>   krunner/dbus/org.freedesktop.ScreenSaver.xml 5efd943 
>   krunner/dbus/org.kde.screensaver.xml e700b88 
>   krunner/kcfg/kscreensaversettings.kcfg c8f76f3 
>   krunner/kcfg/kscreensaversettings.kcfgc af9133d 
>   krunner/krunnerapp.h 040198d 
>   krunner/krunnerapp.cpp eea6220 
>   krunner/lock/CMakeLists.txt cf9a67e 
>   krunner/lock/autologout.h 0c444050 
>   krunner/lock/autologout.cc c86e29a 
>   krunner/lock/config-krunner-lock.h.cmake 7bfdfd6 
>   krunner/lock/kscreenlocker.notifyrc 14e37ec 
>   krunner/lock/lockdlg.h f25e55f 
>   krunner/lock/lockdlg.cc 14a9b34 
>   krunner/lock/lockprocess.h 8b6d9a8 
>   krunner/lock/lockprocess.cc 65c7f1d 
>   krunner/lock/main.h 8a60353 
>   krunner/lock/main.cc 7b41024 
>   krunner/main.cpp 84a547b 
>   krunner/screensaver/saverengine.h 3384d4a 
>   krunner/screensaver/saverengine.cpp 4d90faa 
>   krunner/screensaver/xautolock.h 3db3233 
>   krunner/screensaver/xautolock.cpp 7124215 
>   krunner/screensaver/xautolock_c.h 3b82f5c 
>   krunner/screensaver/xautolock_diy.c b9df2f8 
>   krunner/screensaver/xautolock_engine.c d6d0cf5 
>   ksmserver/CMakeLists.txt 5f0fd34 
>   ksmserver/config-ksmserver.h.cmake 933da35 
>   ksmserver/main.cpp 430a61a 
>   ksmserver/screenlocker/CMakeLists.txt PRE-CREATION 
>   ksmserver/screenlocker/Messages.sh PRE-CREATION 
>   ksmserver/screenlocker/autologout.h PRE-CREATION 
>   ksmserver/screenlocker/autologout.cpp PRE-CREATION 
>   ksmserver/screenlocker/data/CMakeLists.txt PRE-CREATION 
>   ksmserver/screenlocker/data/force_krunner_lock_shortcut_unreg.cpp 
> PRE-CREATION 
>   ksmserver/screenlocker/data/kscreenlocker_locksession-shortcut.upd 
> PRE-CREATION 
>   ksmserver/screenlocker/dbus/org.freedesktop.ScreenSaver.xml PRE-CREATION 
>   ksmserver/screenlocker/dbus/org.kde.screensaver.xml PRE-CREATION 
>   ksmserver/screenlocker/greeter/CMakeLists.txt PRE-CREATION 
>   ksmserver/screenlocker/greeter/Messages.sh PRE-CREATION 
>   ksmserver/screenlocker/greeter/greeter.h PRE-CREATION 
>   ksmserver/screenlocker/greeter/greeter.cpp PRE-CREATION 
>   ksmserver/screenlocker/greeter/greeterapp.h PRE-CREATION 
>   ksmserver/screenlocker/greeter/greeterapp.cpp PRE-CREATION 
>   ksmserver/screenlocker/greeter/main.cpp PRE-CREATION 
>   ksmserver/screenlocker/greeter/sessions.h PRE-CREATION 
>   ksmserver/screenlocker/greeter/sessions.cpp PRE-CREATION 
>   
> ksmserver/screenlocker/greeter/themes/org.kde.passworddialog/contents/ui/Greeter.qml
>  PRE-CREATION 
>   
> ksmserver/screenlocker/greeter/themes/org.kde.passworddialog/contents/ui/SessionSwitching.qml
>  PRE-CREATION 
>   
> ksmserver/screenlocke

Re: Proposed adjustments to our release cycles

[Shaun Reich]

>  * The difficulty of coding for N releases. Since the releases an not aligned
> anymore, you have to maintain code and #ifdefs for new features that depend on
> new versions of parts X of the stack that may or might not be used by people
> compiling the application. We've have some bad experiences with "expected
> versions on the stack" so i hope you're understanding this is not a
> theoretical scenario.

i thought about that as well, but assuming kdelibs is the only issue,
i was assuming that the kdelibs releases would always be ahead of the
everything-else releases. in which case there should be no "i have a
feature that requires XYZ from kdelibs", or something. or were you
referring to other areas of the stack? i could see it becoming a
problem if we have some apps with dbus trying to talk with each other
when they're on totally different release schedules. but that's not
too difficult to solve.

-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: Proposed adjustments to our release cycles

[Shaun Reich]

On Sat, Jun 16, 2012 at 9:44 PM, Inge Wallin  wrote:
> As far as I could understand from the above the main ideas are:
>  - Splitting the SC into 3 parts
>  - Shortening the release cycles significantly.
>
> It seems to me that a current trend in larger free software projects is to go

which projects? you pointed out firefox, which is shortening, and so
is chrome these days ;)

> If we shorten the release cycles (an idea
> which I am actually not that fond of) then could we also consider to have an
> LTS release now and then?

i see your point..

while continuously backporting to say.. 2 prior versions does incur a
good amount of overhead, i don't think it'd be *too* much of an issue
as it's pretty damn easy with git. i mean, you'd just be backporting
to 1 additional branch each time, 1 more than usual...

i'm definitely liking the "shorter releases" plan though, despite some
hiccups we'll encounter in implementation. having a release early,
often, and always stable is something i've always thought we needed.
it'd make it easier to run master without having your machine break in
new ways every 2 days.

-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: Proposed adjustments to our release cycles

[Shaun Reich]

On Sat, Jun 16, 2012 at 7:21 AM, Marco Martin  wrote:
> a part of the plan (kindof a consequency in the long term of the thing
> described here) is that it would mean aiming to a state where there are nover
> freezes (or well, master is always frozen, depends how you look at ;)
>
> master should always be in a releasable state, while the feature branches are
> merged in an integration one before is well tested.
>
> now of course there are a lot of technical details how work out this, like how
> to manage translations

yeah, especially if someone introduces a set of strings in the 11th
hour which don't have translations associated with them yet.

a bit concerned at the bug fixes part as well. if somebody merges
something into the integration branch because (they) tested it well,
but we're actually releasing mainline tomorrow..what happens?

i think there needs to be some "rules" which can hopefully remove the
grey area with those kinds of situations.

-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: Proposed adjustments to our release cycles

[Shaun Reich]

i like where this is going..i've always wanted a bit more flexibility
in releases...

one thing to keep in mind (i realize it's a bit premature to say this,
but..) we'd definitely have to make sure we coordinate the various
freezes well, since there'd be a dedicated and specialized
freeze-timeline for each module set.

i'm assuming that there'd have to be an independent freezing process
for stuff like translations, and just the general "make sure we don't
screw anything up last minute".

e.g. one month is rapid and the freeze time would have to be really
rapid (though of course you just threw random numbers as examples).

and the freezes would have to be *very* well communicated, because
even now we run into issues with people not realizing that we're in
string freeze or feature freeze.

-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: Re: From kdelibs4 to KDE frameworks... how to make KDE more cross platform...

[Shaun Reich]

On Tue, Feb 14, 2012 at 1:36 PM, Martin Gräßlin  wrote:
> On Tuesday 14 February 2012 19:12:58 Alexander Neundorf wrote:
>> On Tuesday 14 February 2012, Aaron J. Seigo wrote:
>> > On Monday, February 13, 2012 17:51:23 Shaun Reich wrote:
>> > > hate to chime in as well, but i think replacing the Windows shell
>> > > should definitely be something that's looked at. imho it makes a lot
>> > > of sense. face it, the Windows shell sucks.
>> >
>> > how many windows users realistically change the shell, even though it's
>> > already possible now and such shells exist?

well, to be fair it tends to be quite difficult, most are for-paid,
and the ones that aren't require doing a bunch of dll helll stuff.

>> >
>> > this is even smaller than the # of people who really dislike the windows 7
>> > shell THAT much.
>> >
>> > compare with: how much effort is required to make this REALLY work well?
>>
>> Especially considering the man power we have under Windows. It's not much.

agreed, we need more devs working on windows, definitely.

> what we also should keep in mind is that our KDE Plasma Workspaces consists of
> more than just plasma-desktop. Many components which are an important part of
> the Plasma Workspace's user experience are strongly tied to X11 without any
> chance of ever getting ported to Windows (port to Wayland will make that
> hardly better). While it is possible to get plasma-desktop running on Windows
> you will never be able to get the Plasma Workspaces running on Windows. It
> will always be just a very bad rip-off of what we have on X11/Wayland.
>
> Personally I would like to see strong investments on the application view to
> use it as a vehicle to get more users to the real system. "You love KDE
> Marble? Did you know that KDE offers more software? Check it out here
> $linktolivecdofrandomdistribution" :-)
>
>

true. yes, i would definitely agree that apps are more important. the
window manager being non-portable did not occur to me, that would
indeed cause lots of headaches.

-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: From kdelibs4 to KDE frameworks... how to make KDE more cross platform...

[Shaun Reich]

hate to chime in as well, but i think replacing the Windows shell
should definitely be something that's looked at. imho it makes a lot
of sense. face it, the Windows shell sucks.

why are we replacing their apps and adding our own (dolphin kicking
explorer's butt)?

because the default ones are terrible.

honestly i see that as the point of running kde. whether or not it's
optional is something else, but it lets people who love kde, hate
windows, but are forced to use it (me especially)..have that much more
bearability(pft, what do you mean it isn't a word?).

just like we run apps in wine so that we don't have to boot out of our
precious kernels and workspaces and apps, the same should be equally
sought after.

if a non-linux "port" is going to be done at all -- do it all the way,
the right way, imho.

just go ahead and ask me about all of the annoyances that it really
brings on me -- honestly, i could rant on for days about flaws from
little to small that really make me loathe having to be in windows for
another second. the way i see it, KDE helps alleviate that, and plasma
is awesome (explorer is just a sad thing imho). and i'm certain there
are tons of other users who are forced to use windows because of apps
x y and z which aren't possible in a VM or wine.

while i'm not necessarily for the "port to windows", just because i
see it as sort of taking away the uniqueness of linux and leaving the
"why bother switching?"...but i also see the other side as well, and
appreciate the port.

kuiserver shouldn't be difficult to cut out of the picture. it just
requires mapping of e.g. the plasma dataengine directly to kio when
kuiserver is not going to be "enabled"..

-- 
Shaun Reich,
KDE Software Developer (kde.org)

phonon javascript

[Shaun Reich]

anyone know how can i access phonon through javascript?

what lines do i import, what's the CMakeLists.txt need, and how do i
access the methods/classes in javascript?

looks like it's exported via Q_PROPERTY and what not, just need to
know how to actually use it.

-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: Review Request: Record job dbus id in dataengine to allow software to terminate a job through DBUS

[Shaun Reich]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103732/#review9952
---


hi, thanks for the patch.

however, i'm not sure i understand the issue it is addressing.

the applicationjobs plasma dataengine isn't meant to have an extensive dbus 
interface at all really. that's kuiserver's job, as it's the actual host of it.

additionally, since the applicationjobs::JobView implements the 
org.kde.JobViewV2 interface, and methods like ::terminate already exist, that 
gives us bidirectional communication automatically. (you can test this 
by...when some long job is running, go to qdbusviewer, org.kde.plasma-desktop, 
DataEngine/applicationjobs/JobView_%1/org.kde.JobViewV2...and you will see all 
the methods implemented anyways, and the calls of those methods are propagated 
upwards to kuiserver).

- Shaun Reich


On Jan. 19, 2012, 7:55 a.m., Bellegarde Cédric wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103732/
> ---
> 
> (Updated Jan. 19, 2012, 7:55 a.m.)
> 
> 
> Review request for KDE Base Apps and kdelibs.
> 
> 
> Description
> ---
> 
> Record job dbus id in Plasma::DataEngine object.
> 
> This will give a simple way to do things like this:
> 
> 
> QString path = "/JobViewServer/JobView_" + 
> QString(data["jobDbusId"]);
> QDBusMessage m = QDBusMessage::createMethodCall(
>"org.kde.JobViewServer",
>path,
>"org.kde.JobViewV2",
>"terminate");
> bus.call(m);
> 
> when you want to terminate a job.
> 
> 
> Diffs
> -
> 
>   plasma/generic/dataengines/applicationjobs/kuiserverengine.cpp 59a4de7 
> 
> Diff: http://git.reviewboard.kde.org/r/103732/diff/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Bellegarde Cédric
> 
>

Re: hard-dep for Qt 4.8

[Shaun Reich]

Some food for thought, as if this thread wasn't long enough...take a
look at how much discussion or rejection was given on the dependency
for Qt 4.7 back in 2010.

i.e. nobody responded with objections or otherwise...

http://lists.kde.org/?l=kde-core-devel&m=128500348631281&w=4

-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: Re: hard-dep for Qt 4.8

[Shaun Reich]

On Thu, Jan 12, 2012 at 9:09 AM, Martin Gräßlin  wrote:

> I don't think there is a feature which is a good reason, but a "bug". I am
> quite sure that there are still some issues around q_delete_all and the other
> changes in Qt 4.8 causing regressions.

> Our distributions will ship 4.8 together with 4.8 and this combination might
> just be untested by the maintainers. So I strongly suggest that we make Qt 4.8
> a dependency for master just to get the code tested and fixed before distros
> use it.

Precisely my thoughts. (actually, e.g. fedora already uses 4.8 with 4.7.4 iirc)

Any other voters? ;-)


> So unless there is a good reason why not to increase, I would like to see
> master depend on Qt 4.8.



-- 
Shaun Reich,
KDE Software Developer (kde.org)

hard-dep for Qt 4.8

[Shaun Reich]

Prompting motion for making Qt 4.8 a hard dependency for KDE
4.9/master. Currently kde-baseapps/plasma/folderview does not build
against 4.7 due to an (albeit minor) api usage.

Not sure how other areas in KDE fair against this, most notably the
Plasma area (with QML and what not).

If we depend on it, we need to set the CMake check obviously.

-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: Can we please have an updated and confirmed working "build KDE from source as separate user"?

[Shaun Reich]

On Mon, Jan 2, 2012 at 2:00 PM, Mark  wrote:
> What i meant is: how do you run that bash function?
> I have no clue for bash functions and how they work. So for example do i
> need to do: "runmaster() dolphin"?
> Yeah, i really have no clue!

You open a new shell, you type in 'runmaster'. Now your shell/konsole
tab will have the proper variables to run any application, especially
ones from master. Then you just type in the app, e.g. plasma-desktop.
That's all it does really, pretty simple. You just need to change
those env vars to something that your system can use (that is,
whereever kde master is installed).

> Also, this function is missing a ending "}" ... is there anything else
> missing?

No, I just didn't catch the } apparently.

-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: Can we please have an updated and confirmed working "build KDE from source as separate user"?

[Shaun Reich]

On Mon, Jan 2, 2012 at 12:38 PM, Mark  wrote:
> Do you also have a run example for any kde app?

Hm, for any kde app? The script snippet I gave you can run anything,
provided you point the vars to the right path. It even uses a
different KDEHOME, so that configuration files won't get touched from
the code from master.

-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: Can we please have an updated and confirmed working "build KDE from source as separate user"?

[Shaun Reich]

On Mon, Jan 2, 2012 at 11:59 AM, Mark  wrote:
> That is completely the opposite of what was suggested to me in the last few
> months of the kde svn days. Back then it was specifically suggested to use
> a separate user for kde developing stuff. Don't know who suggested it.

Yes, well...it's changed a bit ;-)

Mostly the reason why we had separate users, was for the KDE3->4 port.
That way it couldn't hose all of your files..techbase wasn't updated
since then :-D

> I personally like to have it all as a separate user since then everything is
> just at one place and i can test it as if i had the latest kde version.
> either way, having your script would probably help a lot. Can you put it on
> techbase?

You probably know the docs in question better than I, so I'll let you
(also, I'm exceptionally lazy this morning).

runmaster() {
#if [ -z "${KDE_ENV_SET}" ]; then
# (this script is from bcooksley)

export TRUNKINSTALLPATH="${HOME}/devel/kde/install"
# Change this to your kdedir setting in ~/.kdesvn-buildrc
export KDE_EXTRAS="${TRUNKINSTALLPATH}/extras"
export KDEDIR="${TRUNKINSTALLPATH}/kde"
export KDEDIRS="${KDEDIR}:${KDE_EXTRAS}:/usr/"

# Change this to your qtdir setting in ~/.kdesvn-buildrc
export QTDIR="${TRUNKINSTALLPATH}/qt"
export 
QT_PLUGIN_PATH="${KDE_EXTRAS}/lib64/kde4/plugins:${KDEDIR}/lib64/kde4/plugins:${KDEDIR}/lib/qt4/plugins"

export 
PATH="${HOME}/bin:${KDE_EXTRAS}/bin:${KDEDIR}/bin:${QTDIR}/bin:${PATH}"
export 
LD_LIBRARY_PATH="${KDE_EXTRAS}/lib64:${KDEDIR}/lib64:${QTDIR}/lib"
export CMAKE_PREFIX_PATH="${KDE_EXTRAS}:${KDEDIR}:${QTDIR}"
export CMAKE_MODULE_PATH="${CMAKE_PREFIX_PATH}"
export 
PKG_CONFIG_PATH="${KDE_EXTRAS}/share/pkgconfig:${KDE_EXTRAS}/lib64/pkgconfig:${KDEDIR}/lib64/pkgconfig:${KDEDIR}/share/pkgconfig:${QTDIR}/lib/pkgconfig"

export KDEHOME="${HOME}/.kde-master/"
unset XDG_DATA_DIRS

# Should be for kbuildsycoca
export KDEVARTMP="/var/tmp/kdecache-master-${USER}"

# Set the XDG data path, helps finding plugins, etc
export 
XDG_DATA_DIRS="${KDE_EXTRAS}/share:${KDEDIR}/share:${XDG_DATA_DIRS}"
export XDG_CONFIG_DIRS="${KDEDIR}/etc/xdg:${KDE_EXTRAS}/etc/xdg"

# Live Oxygen Gtk!
export GTK_PATH=$KDEDIR/lib/gtk-2.0/2.10.0
export 
GTK2_RC_FILES=/etc/gtk-2.0/gtkrc:$HOME/.gtkrc-2.0::$KDEHOME/share/config/gtkrc-2.0

# Don't accidentally get sourced again.
#export KDE_ENV_SET=1
#fi
}


-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: Can we please have an updated and confirmed working "build KDE from source as separate user"?

[Shaun Reich]

On Sun, Jan 1, 2012 at 7:19 PM, Thomas Lübking
 wrote:
> Since you can run applications from textshells this means your ~/.profile is
> not invoked by kdm or whatever sets up the session for you
> -> put the exports somewhere into ~/.kde/env

Right, good point. Another way that you may want to try is making your
own ~/.xsessionrc (believe that's the name), which sets up the
variables appropriately. Then you can go into kdm under your regular
user, select the session type, ("Custom" for your master session, or
"kde4"(for your distro one)).


The way I see it, the best methods are as follows:

They're technically mutually exclusive...

(0) Run KDE master as your main session. Obviously this has some
problems if this is a production machine. But I've used it for a while
(not currently though, because I'm trying not to ;)

(1) Run KDE from your distro as usual, when you want to run master
applications, open a shell and run the function "runmaster", which is
just a function on my system which exports the proper vars for that
one shell. It makes things quite convenient, you can even run
plasma-desktop from it, provided you kill your main one for a bit. In
fact, that's how I currently test plasma-desktop changes of mine. I'll
give you the shell snippet if you are interested.

These options are meant for one user. But of course you can use more
than one user...I just don't see the point, it ends up with some very
hairy issues. e.g. I had to set proper ACL's for it, so I could edit
source files and have the proper perms to go to and fro.

-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: Can we please have an updated and confirmed working "build KDE from source as separate user"?

[Shaun Reich]

Honestly, running a separate user for it just makes everything more a
pain than it should be.The better way is to just run it under your
user but use different environment variables when you want to run
master apps. Your crash is likely caused by the fact that you
attempted to run an application (Dolphin) from master, yet it was
still using the $QTDIR from /usr/.., in other words probably too old.

I just have a command, "runmaster" which switches the current shell to
one that has all the environment vars setup to run a compiled
application. This way I can have a stable desktop, and run and test
things from master manually and whenever I want to.


Actually, yes, I see that your QTDIR is pointing to /usr. That is
incorrect for building from source.

Truly, I recommend not going the separate user route, that's sort of
why it's not well documented. Mostly because it shouldn't be used..in
fact, I even added it somewhere a long time ago saying that other
methods are better than a separate user (no idea if it's there or not,
some people go too crazy on wiki edits and don't preserve enough past
info).

-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: KDE 5, Qt 5 and QML - What is advised for writing new (KDE) applications in the long term?

[Shaun Reich]

On Wed, Aug 17, 2011 at 1:49 PM, Mark  wrote:
> So for future KDE apps there is no "guideline" to use QML if possible
> (option #2).. It's all still (and remains) what the app developer want
> to do?

No of course not. In the same manner that you can write a Plasma
widget in anything you like. It's just that we're actually trying to
port as much as we can to QML, as it's a lot easier to maintain and
faster to develop. Things that should be simple, like lists with
proper theming and scroll support, etc. actually are, now, with QML.

> @nuno for kde components. I've experimented with the GIT components on
> windows and they look very native and good. They should look equally
> native on KDE and Mac. I'm just hoping they fix some bugs and make it
> part of Qt 4.8 or 5.0. Since this stuff is making the app distribution
> somewhat tricky as the components need to be installed manually.

Which afik makes it not a target as of now, unfortunately.

-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: smallish project needed

[Shaun Reich]

On Fri, Aug 12, 2011 at 9:58 AM, Mark  wrote:
> Well, in that direction.. it's not written in QML or anything.. :
> http://ppenz.blogspot.com/2011/08/introducing-dolphin-20.html

Just because Dolphin is being rewritten using itemviews-ng and
QGraphics* doesn't mean that it's heading towards the QML area. As
others have mentioned, full-blown applications like this do not make
sense, but lighter ones do (like the phonon thingy). Especially given
all that Dolphin has to manage (as mentioned, treeviews, column views,
preview display & generation, nepomuk data, tooltips filled with that
data)..etc. and dragging. Full dragging support doesn't exist nicely
out of the box with QML, which is a huge oversight imho.

QML is great for certain uses with applications that do not have
sophisticated requirements. For those that do, lets not try to cram
QML down everyone's throat just because it ends world hunger, just
apply it where it fits the niche nicely ;-p

-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: KDE 5, Qt 5 and QML - What is advised for writing new (KDE) applications in the long term?

[Shaun Reich]

On Fri, Aug 12, 2011 at 10:22 AM, Mark  wrote:
> 1. Write the application in Qt mostly and use kdelibs where needed?
> 2. Same as 1. but make the GUI in QML like i did in the example above?
> 3. Skip C++ altogether and make in in QML only?
> .. more options?
>
> I personally like option 2 the best since i get everything i want and
> i just dislike making an entire desktop application in JavaScript
> whatever the performance is.
>
> But what is the goal (or desire) for KDE with the plasma desktop and
> all KDE apps?

For Plasma, and plasma-desktop, the answer is "qml as much as is
possible" which in this case tends to be just about everything.

>Full QML all the way? or like option 2?
> I know Dragon is going to use the phonon QML and some more QML elements.

Dragon's use case is a bit simple if you think about it. You need to
display a video on the entire scene, and then just have a small popup
panel that is used for e.g. seeking, pausing the video. (you can see
that in the pko screenshot for instance).


Well for starters, #3 is out of the question. You need *some* C++ to
actually expose the data and perform actions and such. QML should just
be seen as the UI, that's all it is. Especially since data retrieval
and the corresponding actions in general, have a lot to do
performance-wise.

#2 is fine for this particular case, since it isn't really doing a
whole lot of complex actions.

I don't know how practical making "entire desktop application[s]" in
QML is. I'd say it's good for "light" things, but full-blown resource
intensive applications I would not use it for. Ones that require
complex layouts/UI features, and heavy model usage (I've found the
view classes to be sort of limited). Your example was rather simple,
and that tends to be the scope of Plasma Applets, which is why it
makes it easy for them.

Of course, qt quick desktop components isn't even out yet.

My .5 cents.

-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: Dolphin Right Click Menus

[Shaun Reich]

> I can see where they are stored in an QList and where they are placed
> into the menu, but not where the values in the QList get generated.
> I've only bee able to trace it as far as dolphinmainwindow.cpp

KNewFileMenu (kdelibs/kfile/knewfilemenu:960, for instance).

Just grep for a string that you see...e.g. 'grep -RinC 14 "link to
device" kdelibs".

-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: Problem with QWidget->mapToGlobal()

[Shaun Reich]

I have the same problem with master and Qt 4.7.

Clicking the windeco icon on a window which is on either screen
results in the menu displaying as far left on the left screen, and the
top of the screen + (heightOfTitlebar) it seems.
Simply right-clicking the titlebar itself results in an incorrect
offset (resulting in it being on the left-most screen at the top. The
difference is that the first one is statically always at left-top. The
second case (sort of) follows the x axis of the titlebar, but at the
top.

Anyways, ran it through gdb just for curiousity's sake and yeah
mapToGlobal isn't giving what one might expect. Does the widget need a
parent or something? Because other uses of it seem pretty similar to
this one, yet they work fine. or is this some qt/x bug?


-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: KDM plans and lightDM

[Shaun Reich]

On Wed, Jun 15, 2011 at 12:45 PM, Alexander Neundorf  wrote:
> Seriously, displaying unread emails ?
> From which user ?

All of them.

MSWIN interates through each user in the listview displaying unread
mails for each. (it's just a count of unread emails..obviously you
don't want other people sifting through some poor bloke's private
e-mails ;)

-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: KDM plans and lightDM

[Shaun Reich]

On Wed, Jun 15, 2011 at 2:20 AM, todd rme  wrote:
> I gather from the discussion that most, if not all, the features that
> KDM still needs are also lacking in LightDM, while KDM has lots of
> features LightDM does not.  So if we are talking about wasted
> resources,

>wouldn't it waste far fewer resources

Ex.act.ly. That's precisely what I've been trying to get across this
entire time. But instead of adding anything missing to KDM, it's
instead added to a different, far less developed project.

> to add those new
> features and add the Gnome-centric bits in KDM than to add the new
> features, old features, gnome-centric bits, and KDE-centric bits in
> LightDM?


-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: KDM plans and lightDM

[Shaun Reich]

On Tue, Jun 14, 2011 at 6:59 PM, David Edmundson
 wrote:
>Does KDM still run the greeters as root?

No. It's been not doing that for about a year or so.

-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: KDM plans and lightDM

[Shaun Reich]

On Tue, Jun 14, 2011 at 2:58 PM, Harald Sitter  wrote:
> Should that ever get finished. Shaun?

Good question ;-)
Yeah, it's in a pretty finished state, after my unintentional hiatus.
Mostly I've been cleaning stuff up(and yes, I've been actively
committing lately), so that the qml code can look the best. It already
runs plasma and qml and logs in, just have a few more things to do on
it. (kinda refactoring a bit so it doesn't come to bite me later on,
at the moment..)

> In particular it is my personal believe that a strong separation between DM
> logic and desktop binding/integration magic is beneficial from a structural
> POV. That way you can easily swap the integration bits (QWidgets -> Plasma QGV
> stuff -> Plasma QML stuff?) around without having to poke into the DM stuff at
> all.

Well, you see. You have to understand my frustration --> the thing is,
this *already* exists in KDM. And anything that is deemed
unsatisfactory(not everything's perfect, naturally) could easily be
changed of course.

Everybody talks about it like it's some magical unicorn that hasn't
been spotted before, but the truth is, it's staring everyone in the
face.

In fact, I have dealt directly with this separation when I've been
working on the Plasma frontend, and based some of it around the
original kfrontend (qwidget) code. So I don't see what the big deal
is, considering I've already worked with this myself...

(also note that the Plasma QGV and Plasma QML stuff are kind of one in
the same, in the case of my code. one can easily make a qgw as the
greeter...of course, I'm using qml. well, unless you're counting
things like the scene and the view. but I haven't found a case for
moving those to qml yet. not that it'd be that difficult, since it's
all modular)

-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: Re: KDM plans and lightDM

[Shaun Reich]

Slight shift of topic as well...but:

How does lightDM even handle different authentication types? KDM has a
plugin system which handles different auth types (fingerprint,
winbindd, etc.).

However, the fundamental flaw that I can see..is that at some level or
another, the UI/Greeter *has* to know what type of authentication type
it is. That is why KDM has plugins which wrap around PAM(sort of), so
that the interface can properly accommodate for the changes in auth
type. Note these plugins apply to the screensaver unlock dialog as
well.

I've been toying with the idea in my head, of using the same Plasma
plugin (actually an applet + dataengine which wraps around a main,
more generic dataengine) in tandem with the Plasma integration with
the screensaver, that is currently present. I think it'd be quite
trivial for me to do this, too -- since I specifically tried to not
make assumptions.

The plugins exist (both in the plasma frontend and regular kfrontend)
so that when it's in fingerprint mode..it won't show a textbox or any
useless stuff like that, and may additionally show a diagram of some
bloke wiping their finger across. (that's what the kdm plugin does
actually).

Anyone familiar with the structure in lightDM care to enlighten?

-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: KDM plans and lightDM

[Shaun Reich]

On Mon, Jun 13, 2011 at 2:55 PM, Alex Fiestas  wrote:
> On Monday, June 13, 2011 04:46:12 PM Shaun Reich wrote:
>> Duh. You've got to be joking. Okay, how about you read up on the
>> subject..like uhm...in my blog, before criticizing what you clearly
>> are clueless about?
>> Blink excessively? You're right, I'll get right on that.
> Dude moderate your tone, not everybody knows about everything, I'm asking
> about this clueless as you say, but know what? this is for what community is
> for, to help each other and share knowlege.
>
> So, relax.
>

Thanks.

I apologize for the tone I used. I just can't help myself from getting
upset when I see unneeded duplication. Especially since I've seen it
first-hand too many times.

-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: KDM plans and lightDM

[Shaun Reich]

On Mon, Jun 13, 2011 at 6:03 PM, Thomas Lübking
 wrote:
> Am Mon, 13 Jun 2011 16:46:12 -0400
> schrieb Shaun Reich :
>
> Sorry, I don't read your blog - just did a quick google and thought this
> was the best place to get a reliable answer.

No problem. Just don't try to critique something until at least
reading up on it (which someone else linked to previously in the
thread, even).

> OFF TOPIC 
--snip
> "From a clock, battery monitor, the kdm greeter (of course. you know,
> the login dialog), system monitors, disc usage, sticky notes,
> calculator, on-screen keyboard"
>

> You got a better link why else using plasma is great?
Huh? Other than the fact that it is capable of powering an entire
workspace on many form factors.

> Oh, and did you see "on-screen keyboard"?

Again..huh? I really don't know what you're trying to get at with
this. The point is we get all of that for free. Whereas if you do not
use the whole of Plasma, you have to do it all yourself (take a look
at kdm's kfrontend code which creates a clock and such. Just makes
things easier when there's zero duplication.

> You mean, like compared to the current indirect qwidget -> subclass ->
> plasma ->
> -> svg
> -> (incomplete) qstyle usage ..?
>

> which usually fails (used to?, actually not tried lately) if you deviate
> from oxygen's margins & paddings because it (implicitly) uses (used? no
> idea whether this has ever been fixed) the style to calculate the size
> but the theme paddings to render clipped strings?
> /OFF TOPIC 
>

Sorry, can't comment on this as I've no idea what you're referring to.

> This is not what i'm talking about. A "hostile" area is where many ppl.
> have (in doubt non physical) access to the same machine.
> So if user x can get user y to add a malicious plasmoid to the DM
> frontend, he can pot. scam his login data/password and use that later
> on.

The same can be done using kdm's authentication plugins. I could go
and make my own right now to do just that, and if the user has root
access and installs it, that's the (stupid) user's prerogative. Just
like installing any other application on a desktop could do the *very*
same.

This is of course, coming from the perspective that the user is a system admin.

You are aware that in order to add applets to the greeter (if that
option is enabled, per system admin), you need to authenticate as root
(which is presumably what the system admin only would have).

So please don't think this is "anyone who walks by can go and monkey
around with it". It sounds like that's what you're confusing it as.

> Ahhh... security by opt-out. Of course, because anything else
> would render the system pointless in the first place.

Once again, you're backwards. YOU NEED ROOT ACCESS TO ADD APPLETS. I
just want to emphasize that. The "the sysadmin can disable that" was
referring to a button, a la what the cashew has, to unlock widgets and
be able to add them. To do that..once again, *requires root access*. I
was simply referring to visually disabling it. It still wouldn't be
functional without root access either way, out of the box.

Sorry, but I don't think you read my blog entries thoroughly enough.
Just as using a utility without reading the man page can destroy your
system, so can replying to a mailing list without having at least read
up on existing docs ;-p

> Overlay the input fields?
> Scam logins & passwords?
> Maybe just hook on textChanged signals for that purpose?

See above. The same *exact* thing could be done if someone just
installed a custom PAM authentication. Seriously. What do you expect
if the user has root access, is able to install anything he wants, and
installs a malicious piece of software? Are you entirely unaware of
how malware works? Malware plays upon the users stupidity with
elevated privileges. If you never elevate the privileges, what's going
to happen? Well. The software wouldn't be installed, for one.

I really think you are thinking incorrectly. This situation can be
applied to ANYTHING. Give full access to someone and they had better
know what they are doing, because if they are stupid enough to install
compromising software on their system -- then their system just got
compromised. That's the fundamental flaw in any security model: the
user who has root access.

(think that covers everything in this thread..onto the next, hehe)

-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: KDM plans and lightDM

[Shaun Reich]

On Mon, Jun 13, 2011 at 4:24 PM, Thomas Lübking
 wrote:
> 
> Semi-OT:
>> knowledge there is some work going on to bring a Plasma interface to
>> KDM which would be a very unique feature.
>
> This?
> http://sreich.blogspot.com/2010/06/kdm-plasma-update.html
>
> Errr... hopefully *a* - and not *the* kdm frontend.

Of course *a*. I even went out of my way to specify it in other blog
entries, multiple times iirc.

I guess I should implement a big blinking marquee for the impaired as
well as for the ones who can't read.

> If it's just about the look:
> move the plasma frame rendering stuff to kdeui. done.
> I'd write you a plasmatic general UI style to prevent this ;-)

It isn't just about the look. But you have fun with implementing that.
I'd love to know how flexible and clean the code is 

> But allowing "random" scripts in a login manager is like asking
> people to shoot themself.

See "plasmoids" bit, further below...

> Sorry for being rough now, but that is really a braindead idea and
> at best acceptable for the single user desktop (ie. the ppl. who
> probably use autologin anyway), but certainly *not* in a hostile
> environment.

A "hostile" environment? If they have access to your PC you're screwed
anyways. Anything less than hostile is what any login manager would be
providing for. Nothing more. If you're trying to prevent total access
to your computer from non-average users, then you're fucked regardless
of what method you use.

> But plasmoids are really the opposite of "secure" - you'd have to tell
> everybody to carefully inspect the plasmoids tehy want to put into the
> DM, or provide a database of trustworthy ones and who's gonna do that?

Duh. You've got to be joking. Okay, how about you read up on the
subject..like uhm...in my blog, before criticizing what you clearly
are clueless about?

The sysadmin would easily be able to prevent any additional plasmoids
from being added. That's built into Plasma's kiosk abilities.

Oh but you knew that before responding, because you know all about
this subject, or have at least half-ass read up on it. I see.

Not only that, the applets only run as user. So if the sysadmin did
not disable that, and the user can add them...tell me..what are they
going to do?

Blink excessively? You're right, I'll get right on that.

-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: KDM plans and lightDM

[Shaun Reich]

> It seems quite fashionable to start a project on freedesktop.org without
> involving KDE and to build it using Gnome tech, then ask us to use it because
> "it's a cross-desktop project".

Oh yes. Apparently it's better than KDM because it's very
cross-desktopy. And better. And stuff.

Whatever the hell that means.

And it doesn't depend on any toolkit except glib!!

Which, KDM has had since the beginning with it's separation between
backend and frontends.

lightDM is also headed by my dear friend Canonical, as is clearly seen.

Of note is that ldm uses d-bus, whereas kdm uses sockets. So as for
the "lightweight" part, they just forced everyone to have a full dbus
session up.

Instead of working with existing code, *apparently* it is more
effective to make a new project altogether. I think we should adopt
this strategy. After all, isn't KDELibs and KIO getting really old and
crappy? Time to rm -Rf / and start from scratch...

Oh wait. The *same exact* situation was presented to us with GIO.
"create something new, disregard existing implementations, force
adoption after everything is finalized." Well, so I guess that base is
already covered..lets find another one.

Evidently age is indicative not of stability or refinement, but of a
dying animal, ready to be put down. mjg95's blog entry hits the nail
on the head.

I also laugh out loud at how the project brags about having "much,
much less code than $kdm/gdm". But what do you think the code was
there for? Did we have 50,000 lines of code accidentally copied
somewhere? I think not. I'm pretty sure it's self-evident that the
code actually *serves* a purpose. Purposes that LightDM still has
marked as "well...we don't *quite* have that juuusssttt yet". But hey,
my powers of observation must be astounding.



--
Shaun Reich,
KDE Software Developer (kde.org)

Re: Review Request: Fix possible memory and D-Bus connection leak in KStatusNotifierItem

[Shaun Reich]

> On June 6, 2011, 8:38 p.m., Aaron J. Seigo wrote:
> > i doubt this fix is correct. what looks more like is 
> > KStatusNotifierItemDBus::~KStatusNotifierItemDBus(). right now this is the 
> > implementation:
> > 
> > m_dbus.unregisterService(m_service);
> > 
> > and perhaps it should include:
> > 
> > m_dbus.unregisterObject("/StatusNotifierItem", this);
> > 
> > and perhaps even:
> > 
> > m_dbus.disconnectFromBus(m_service);
> > 
> > (though i expect the latter is done automatically when QDBusConnection is 
> > deleted? maybe not though...)

actually, looks like ~QDBusConnection() won't close the connection. apparently 
disconnectFromBus does indeed need to be called explicitly. /me suddenly 
wonders how much code doesn't do this, if need be.


- Shaun


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101527/#review3726
---


On June 6, 2011, 3:31 p.m., Christoph Feck wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/101527/
> ---
> 
> (Updated June 6, 2011, 3:31 p.m.)
> 
> 
> Review request for kdelibs, Plasma and Marco Martin.
> 
> 
> Summary
> ---
> 
> According to bug 261180 there is a D-Bus connection leak in 
> KStatusNotifierItem. This patch potentially fixes it, but I do not know how 
> to test it.
> 
> 
> This addresses bug 261180.
> http://bugs.kde.org/show_bug.cgi?id=261180
> 
> 
> Diffs
> -
> 
>   kdeui/notifications/kstatusnotifieritem.cpp c48ed50 
> 
> Diff: http://git.reviewboard.kde.org/r/101527/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Christoph
> 
>

Re: [kdelibs] kdeui/widgets: Get rid of the deprecated KMessageWidget::MessageType enum values

[Shaun Reich]

On Thu, May 19, 2011 at 2:01 AM, Kevin Krammer  wrote:
> If you had to do that it is a source incompatible change.
> Why do you need that?

Irrelevant. This API is new in master and the announcement for it's
modification was made long before. He simply gave it a grace period.

-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: Klipper

[Shaun Reich]

On Mon, May 16, 2011 at 1:16 PM, Andreas Pakulat  wrote:
so I have to wonder wether the standard
> copy/paste actions still work and selection via keyboard.

I don't think e.g. ctrl-c, v, works  globally between different
applications. Which is actually mostly why klipper is pretty much
necessary.

This is only "necessary" on X11. So yes, I suppose for modularization
efforts, klipper is sort of a dead weight and more of an extra app
kind of thing just trying to overcome X's brokenness. On Windows, Mac,
and toasters everywhere, it isn't necessary and doesn't make a whole
lot of sense imo.

That isn't to say that it isn't a useful app, naturally it is. Just
one that I feel is not core to non-X11 platforms.

-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: Review Request: Deprecate KLineEdit::clickMessage

[Shaun Reich]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101360/#review3308
---


Are you sure the behaviour for the Qt method 100% equivalent to the current? I 
ask this because now that the deprecated method forwards to it, naturally it's 
quite important to make sure nothing gets fscked up.


kdeui/widgets/klineedit.h


Whitespace :p

You people and your crappy editors ;-)


- Shaun


On May 14, 2011, 12:59 a.m., Davide Bettio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/101360/
> ---
> 
> (Updated May 14, 2011, 12:59 a.m.)
> 
> 
> Review request for kdelibs and Plasma.
> 
> 
> Summary
> ---
> 
> Since Qt 4.7 QLineEdit::setPlaceholderText is available so 
> KLineEdit::clickMessage should be deprecated.
> I kept clickMessage as not deprecated in plasma/widgets/lineedit but now is 
> using placeholderText.
> 
> 
> Diffs
> -
> 
>   kdeui/widgets/klineedit.h 909d1f7 
>   kdeui/widgets/klineedit.cpp 0dd3690 
>   plasma/widgets/lineedit.cpp 09c0c66 
> 
> Diff: http://git.reviewboard.kde.org/r/101360/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Davide
> 
>

Re: iceScrum (was Re: Qt5 -> KDE5?)

[Shaun Reich]

On Thu, May 12, 2011 at 8:38 AM, Torgny Nyblom  wrote:
> On Tuesday 10 May 2011 10.04.34 Aaron J. Seigo wrote:
>> we have already been putting together plans, including documenting them
>> feature by feature in iceScrum
>
> For those of us who this is the first time we hear about icsscrum where is it,
> who can use it and for what?

http://contour-scrum.basyskom.org/icescrum/

-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: USian vs. American (was: US Week Numbers)

[Shaun Reich]

On Thu, May 12, 2011 at 4:02 AM, Hans Meine  wrote:
> Anyhow, it looks as if mistakes should be tolerated in any case. :-)

Personally, I have no preference and place no care upon such frivolous
things. Call me careless, but it doesn't matter to me if I'm called
American, USian, "yankee", etc. Because it simply doesn't matter; it's
meaning can be discerned *shrug*. Besides -- there are more important
things to focus on.

Then again, I'm actively against Political Correctness in many of it's forms :)

Anyways, this is a bit OT for k-c-d, no? ;-p

-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: Review Request: Enable kdialog to set an icon for passivepopup as well

[Shaun Reich]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101282/#review3143
---



kdialog/kdialog.cpp


Whitespace ;-)


- Shaun


On May 5, 2011, 3:57 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/101282/
> ---
> 
> (Updated May 5, 2011, 3:57 p.m.)
> 
> 
> Review request for KDE Base Apps.
> 
> 
> Summary
> ---
> 
> Since I use kdialog a lot, I wanted it to be able to set an icon for passive 
> Plasma notifications as well.
> I saw that the icon was hardcoded to dialog-information and tried to enable 
> it to parse the --icon command line argument and pass it to the dbus call 
> that triggers the notification.
> I could not test the patch however, since I do not (yet) have a full 
> development environment or its dependencies, and I do not even know if this 
> is the right approach, but I hope you can have a look at it.
> 
> 
> Diffs
> -
> 
>   kdialog/kdialog.cpp b80ad9a 
> 
> Diff: http://git.reviewboard.kde.org/r/101282/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kai Uwe
> 
>

Re: Help in modularization

[Shaun Reich]

I can donate regular builds from my brother's server -- it's a Dell
PowerEdge with dual Xeon processors at 2.27 GHz, with 16 GiB of RAM w/
RAID 5 with a UPS backup. Not sure how to do it though, just let me
know if you're interested. If so, you'd have to walk me through
getting it setup and what not.

-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: Git Feature Branch Naming Policy

[Shaun Reich]

>> I'd prefer to see the gsoc branches under a common prefix in the main
>> project repo rather than as personal branches or repos:

I think that's a good idea too, especially given (below).

>>
>>   origin/gsoc2011//

Probably don't need subproject, since the branch name will
probably/should tell you all you need to know.

>
> Why this long name with multiple namespaces, the branches should be deleted
> once merged so we won't have a collection of old soc branches around for long?

Ideally, yes. But as for the branches themselves being merged, or even
in a timely matter, that's a different story, as I'm sure there are
many situations...like the project only being half done and the
gsoc'er leaving (sadly), etc.. It even has other benefits, like "where
do I go to look at the code for ___ project?", and it's all right
there. As opposed to a personal clone under somebody's name. Note we
had a similar situation in svn, except it was less namespaced and more
ugly


-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: Automount security concerns?

[Shaun Reich]

> Yes physical access is always bad. But imagine you are at a place where many
> people are (and stealing the pc is no option). Just going to the toilet for a
> short moment -- with the screen locked -- could make your computer cracked.

>
> In general I think that nothing usb-stick/new hardware related should happen
> if the screen is locked.

I'm assuming said toilet-user has also disabled the (far more
important) firewire port? ;-)

>if the screen is locked. And if really a usb-stick is connected to the pc
>while locked, when a dialog should pop up -- which can only be accessed when
>unlocking -- asking for further actions.

No point in that. Simply don't allow mounting when new devices appear
and the screen is locked. When it is unlocked (it could probably just
check for d-bus changes, to determine that) and there was a stick
plugged in which still exists, mount it.

I see your thinking in "show a dialog after an unlock, to let him know
about it". But there is simply no point in that. If the (toilet-)user
has physical access to it after finishing his business, has the
passkey to unlock it, and does so without checking the computer for
suspicious looking satellite dishes protruding from the PC, then that
is his prerogative at that point.

-- 
Shaun Reich,
KDE Developer (www.kde.org)

Re: git clone kde:kde-workspace hangs

[Shaun Reich]

On Sun, Feb 6, 2011 at 4:30 PM, Martin Koller  wrote:

> Hi,
>
> I've tried already several times today to get a clone of kde-workspace and
> it always gets stuck at about 10-15%
>
> What can I do ?
>

You can try using the tarball form on project.kde.org, for now (no idea why
it hangs up). at least then you can resume it.

-- 
Shaun Reich,
KDE Developer (www.kde.org)