Matthew Woehlke | 1 May 2007 01:14
Picon
Gravatar

Re: kprocess, kpty & kdesu

Oswald Buddenhagen wrote:
> On Mon, Apr 30, 2007 at 11:27:33PM +0200, Andreas Pakulat wrote:
>> On 30.04.07 22:02:43, Oswald Buddenhagen wrote:
>>> - kpty is unix-only. as it stands now,
>> Thats too bad, you know having konsole on windows with an embedded bash
>> would really rock ;) But I do understand that nobody has the time or
>> interest to find a way to make this possible..
>>
> i'm not sure it would be possible to convince the windows console layer
> to use konsole. and it would be really weird to have a terminal that is
> unable to run windows applications ...
> emulating ptys with some intercepted library calls on top of pipes (or
> whatever cygwin does) sure isn't rocket science, but its not even half
> the rent.

JFTR you *can* run Windows applications* from an rxvt (rxvt != CUI 
subsystem!) session, so it is definitely *possible* to make this work by 
cannibalizing Cygwin's pty code.

(* Tested with 'notepad'. There are probably exceptions, especially CUI 
programs don't work right, but for people with Cygwin it's still /so/ 
much better than nothing.)

Alternatively there is http://sourceforge.net/projects/console/ which 
uses a hidden CUI window (but isn't resizable, and the history is 
broken... this is probably because it doesn't have "it's own" history 
but uses what CUI provides, so hopefully Konsole wouldn't have this 
problem).

--

-- 
(Continue reading)

Andreas Pakulat | 1 May 2007 01:16
Picon
Picon
Gravatar

Re: kprocess, kpty & kdesu

On 01.05.07 00:35:24, Oswald Buddenhagen wrote:
> On Mon, Apr 30, 2007 at 11:27:33PM +0200, Andreas Pakulat wrote:
> > On 30.04.07 22:02:43, Oswald Buddenhagen wrote:
> > > some more or less chaotic facts & thoughts:
> > > 
> > >   - cover up qt's omissions, at least on unix. particularly, the
> > >     possibility to manage only stdout and leave stderr alone (that is,
> > >     in .xsession-errors for most times).
> > 
> > Does this mean that I'd have to capture stdout and stderr on windows,
> > even if I only need stdout?
> > 
> yes. none or both. you could find that yourself by looking into the
> apidoc. ;)

I think I misunderstood. Obviously I can still ignore the
readyReadStdErr signal if I want to.

> > > - kpty is unix-only. as it stands now,
> > 
> > Thats too bad, you know having konsole on windows with an embedded bash
> > would really rock ;) But I do understand that nobody has the time or
> > interest to find a way to make this possible..
> > 
> i'm not sure it would be possible to convince the windows console layer
> to use konsole. and it would be really weird to have a terminal that is
> unable to run windows applications ...

Yeap, that would be really weird. I'd rather have no konsole than such a
"crippled" one.
(Continue reading)

Alex Merry | 1 May 2007 01:51
Picon

KToggleAction in menus

I just noticed a minor thing with KWrite (trunk).  In the Settings menu, 
there are three Show options: Show Toolbar, Show Statusbar and Show 
Path.  Each has a checkbox next to it.

If you click Show Toolbar, it changes the checkbox value, but not the 
text.  However, clicking Show Statusbar will enable the checkbox _and_ 
change the text to Hide Statusbar (same for Show Path).  Show Statusbar 
is from KStandardAction, while Show Path is defined in KWrite itself.

I'm assuming the checkbox is unconditionally displayed for 
KToggleAction, in which case the text shouldn't change when toggled.

Should the alternative ("Hide") text be discarded?

Alex

--

-- 
KDE: http://www.kde.org
Ubuntu/Kubuntu: http://www.ubuntu.org http://www.kubuntu.org
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
Aaron J. Seigo | 1 May 2007 02:39
Picon
Favicon
Gravatar

Re: KToggleAction in menus

On Monday 30 April 2007, Alex Merry wrote:
> Should the alternative ("Hide") text be discarded?

if the checkbox is always shown, then yes.

--

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
James Richard Tyrer | 1 May 2007 03:38
Picon
Favicon

Re: [kde-artists] Icon naming issue

Matthias Clasen wrote:
> On Mon, 2007-04-30 at 11:57 -0700, James Richard Tyrer wrote:
> 
>> "It is recommended that the icons installed in the hicolor theme
>> look neutral, since it is a fallback theme that will be used in
>> combination with some very different looking themes."
>> 
>> My reading of this is that HiColor is a fallback theme that should
>>  contain neutral ('unthemed', generic, or whatever) icons and that
>> it should be a full set of icons -- if not a full set, what will
>> there be to fall back to?
> 
>> From my perspective, the whole "full theme" vs "fallback" is a
>> total red
> herring. A "full theme" is an impossibility anyway, until we get much
>  better buyin from various desktops for the the icon naming spec.

Obviously, there will always be some icons that are missing.  That is
not the way it is supposed to be, it is a bug that needs to be fixed.

> The spec simply states that hicolor will always be tried, and that it
>  will be the last.

Not to belabor the point, but it does say fallback and there is no point
in falling back to an empty directory.

M-W says:

	fallback. noun.

(Continue reading)

Michael Pyne | 1 May 2007 04:42
X-Face
Favicon

Weird build failure in kdelibs due to Phonon

Hi all,

It looks like phonon in kdelibs requires that Qt 4 be built with either 
QT_NO_MEMBER_TEMPLATES or QT_NO_QOBJECT_CHECK to be defined, due to the 
declaration of qobject_cast in qobject.h, line 411.

It appears that the ObjectDescriptionModel template in phonon tries to 
simulate a QObject class for each instantiated template definition by 
implementing various internal QObject methods and data members, including a 
meta object.  Unfortunately, it doesn't seem to implement the 
qt_check_for_QOBJECT_macro() method, which breaks compilation in phonon/kcm 
(where a qobject_cast is used on a template definition of 
ObjectDescriptionModel, called AudioOutputDeviceModel in a qobject_cast<> 
call in outputdevicechoice.cpp:207.

I'd fix it but I'm not exactly sure how. :) I would imagine that we're 
duplicating internal Qt stuff since the Q_OBJECT stuff doesn't work with 
template classes but unfortunately that leads us to problems like this.

I could be completely screwed up, but here's the error message I'm getting:
[ 97%] Building CXX object 
phonon/kcm/CMakeFiles/kcm_phonon.dir/outputdevicechoice.o
/home/kde-svn/qt4/include/QtCore/qabstractitemmodel.h: In member 
function ‘void QAbstractListModel::qt_check_for_QOBJECT_macro(const T&) const 
[with T = Phonon::ObjectDescriptionModel<AudioOutputDeviceType>]’:
/home/kde-svn/qt4/include/QtCore/qobject.h:411:   instantiated from ‘T 
qobject_cast(QObject*) [with T = Phonon::AudioOutputDeviceModel*]’
/home/kde-svn/kde4/kdelibs/phonon/kcm/outputdevicechoice.cpp:207:   
instantiated from here
/home/kde-svn/qt4/include/QtCore/qabstractitemmodel.h:311: error: void value 
(Continue reading)

Oswald Buddenhagen | 1 May 2007 09:22
Picon
Favicon
Gravatar

Re: kprocess, kpty & kdesu

On Mon, Apr 30, 2007 at 06:14:49PM -0500, Matthew Woehlke wrote:
> Oswald Buddenhagen wrote:
>> i'm not sure it would be possible to convince the windows console layer
>> to use konsole. and it would be really weird to have a terminal that is
>> unable to run windows applications ...
>
> JFTR you *can* run Windows applications* from an rxvt (rxvt != CUI 
> subsystem!) session, so it is definitely *possible* to make this work by 
> cannibalizing Cygwin's pty code.
>
> (* Tested with 'notepad'. There are probably exceptions, especially CUI 
> programs don't work right,
>
you must be kidding ... *of course* i meant windows console programs -
why should it be not possible to *start* windows gui programs? pty code
is for *talking* to programs, which is not exactly an issue for the
typical gui-only app.
the effect of running a console app (try cmd) will be most probably that
it pops up an own windows console (or runs on the one rxvt was started
from).

> but for people with Cygwin it's still /so/ much better than nothing.)
>
cygwin is completely irrelevant here. it pretends to be unix, so
compiling a cygwin konsole that can host other cygwin programs should
be absolutely no problem (both kde and rxvt work, so why not konsole).

--

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
(Continue reading)

Ingo Klöcker | 1 May 2007 10:47
Picon
Favicon

Re: One more question to kstaticdelter

On Monday 30 April 2007 23:15, Thiago Macieira wrote:
> Christian Ehrlicher wrote:
> >Hi,
> >
> >kconfig_compiler creates code like this:
> >
> >Settings *Settings::mSelf = 0;
> >static KStaticDeleter<Settings> staticSettingsDeleter;
> >
> >Settings *Settings::self()
> >{
> >   if ( !mSelf ) {
> >     staticSettingsDeleter.setObject( mSelf, new Settings() );
> >     mSelf->readConfig();
> >   }
> >
> >   return mSelf;
> >}
> >
> >Settings::Settings(  )
> >
> >   : KConfigSkeleton( QLatin1String( "kgetrc" ) )
> >
> >{
> >   mSelf = this;
> >   ..
> >
> >}
> >
> >Settings::~Settings()
(Continue reading)

Oswald Buddenhagen | 1 May 2007 10:51
Picon
Favicon
Gravatar

Re: kprocess, kpty & kdesu

On Tue, May 01, 2007 at 01:16:08AM +0200, Andreas Pakulat wrote:
> On 01.05.07 00:35:24, Oswald Buddenhagen wrote:
> > On Mon, Apr 30, 2007 at 11:27:33PM +0200, Andreas Pakulat wrote:
> > > Does this mean that I'd have to capture stdout and stderr on
> > > windows, even if I only need stdout?
> > > 
> > yes. none or both. you could find that yourself by looking into the
> > apidoc. ;)
> 
> I think I misunderstood. Obviously I can still ignore the
> readyReadStdErr signal if I want to.
> 
sure. it is simply gone then, which isn't exactly a debugging aid ...

--

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.

Christian Ehrlicher | 1 May 2007 11:04
Picon
Picon

Re: One more question to kstaticdelter

Ingo Klöcker schrieb:
> On Monday 30 April 2007 23:15, Thiago Macieira wrote:
>> Christian Ehrlicher wrote:
>>> Hi,
>>>
>>> kconfig_compiler creates code like this:
>>>
>>> Settings *Settings::mSelf = 0;
>>> static KStaticDeleter<Settings> staticSettingsDeleter;
>>>
>>> Settings *Settings::self()
>>> {
>>>   if ( !mSelf ) {
>>>     staticSettingsDeleter.setObject( mSelf, new Settings() );
>>>     mSelf->readConfig();
>>>   }
>>>
>>>   return mSelf;
>>> }
>>>
>>> Settings::Settings(  )
>>>
>>>   : KConfigSkeleton( QLatin1String( "kgetrc" ) )
>>>
>>> {
>>>   mSelf = this;
>>>   ..
>>>
>>> }
>>>
(Continue reading)


Gmane