headers
Martin Konold | 1 Sep 2005 02:01
Picon

RuDI was: Redefining kdelibs and kdebase

Am Mittwoch 31 August 2005 13:39 schrieb Jarosław Staniek:

Hi,

> 1. A bit harder case: a KDE app running under GNOME needs to perform a
> *dynamic* switch to non-KDE file (and print?) dialog. What about trying to
> dlopen a gnome library for this (it's in C, so it's pretty safe).

Today we had a RuDI BoF at aKademy.

http://www.kdedevelopers.org/node/1398

I will summarize the results of the BoF here briefly.

+ A service oriented approach gained support from people like Matthias Ettrich 
and Lubos Lunak.

+ Matthias can imagine to help with the QRuDI implementation

+ It is considered to be a big plus for non KDE application which want to 
integrate in the KDE Desktop

+ RuDI is also attractive for GNOME and has potential to become a fdo standard

+ Cornelius raised the point that maybe allowing access to the configuration 
system of the desktop is interesting but he also raises potential efficiency 
concerns

+ It would be nice to provide RuDI initially for 3rd party KDE apps, Qt apps 
and Java applications
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kurt Pfeifle | 1 Sep 2005 03:07
X-Face
Picon

kedulaunch --> KDE Application Launcher (or "Berlin Migration")

Hi,

you may have seen last night's commit of the nxfish:/ extension to
our beloved fish:// KIO slave:

   http://lists.kde.org/?l=kde-commits&m=112535566514080&w=2

Today we made a new discovery that will be extremely beneficial to
the future KDE and NX/FreeNX cooperation and integration: it is 
called 

   kedulauncher

If we insert this as the command into a "Unix --> Custom"-type of 
remote NX session configuration, it definitely will make a great 
remote NX application launcher (even though it was probably made 
by the author with only running local applications in mind).

The only gripe we have with kedulaunch currently, is that it so far
is limited to launching "KDE Edu applications only" in a hard-coded way.

Our wish would be to have this thingie extended, and made more 
flexible/configurable to launch *any* application, and also subject to 
"Kiosk-ization".

Such a nice-looking and well-designed application launcher (based on
the kedulaunch code, but more generic) would make a well-received and
perfect component to the current Linux and KDE desktop migration 
efforts of various Berlin local city administration bodies -- this we
were told today first-hand by one of the activists and key influencers
(Continue reading)

Permalink | Reply | 5 comments |
headers
James Richard Tyrer | 1 Sep 2005 02:44
Picon
Favicon

[kde-artists] The need for management

Yes, even though this is an Open Source Software project, we need 
management.  Especially with KDE (and any other similar projects) 
because it has become too large to be managed by constructive anarchy.

DA said:

> "Stepping on toes" is an inevitable consequence of doing work within KDE, in 
> my opinion.

WRONG, anyone that thinks that way needs to rethink their position.

Now, I don't mean that we won't have disagreement.  We should have 
disagreements.  Engineers argue (somewhat vehemently) about how do do 
things.  The problem I see with the WallPaper issue is that the argument 
is getting personal and that it is occurring after the action was taken.

True arguments should alway be about the issue.  I brought up an issue 
on another list a while ago and I thought I was the target of a tag-team 
rhetoric and insult gang.  This could be used as a textbook example of 
how NOT to argue.

So, arguments should stick to the issue.  Also, they should occur before 
an issue is decided.

But, getting back to management.  In business, people think that 
management means other people telling you what to do.  That isn't really 
the case.  Management determines the process of how decisions are made. 
  And, I note that in any organization, after decisions are made that 
everyone needs to abide by them.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Janet Theobroma | 1 Sep 2005 07:25
X-Face

Re: [kde-artists] default artwork for 3.5

On Wednesday 31 August 2005 10:31 am, you wrote:
...
> I am very sorry if I seemed rude, but when people spring things on me
> this way I tend to react to harshly I guess. I am sorry if I hurt your
> feelings in any way.

No, you did not hurt my feelings. 

> The facts of the matter are this: I have acted as maintainer for several
> years now, however, this being artwork I did not take over like many
> technical project maintainers. I do very much like the idea of getting
> feedback and information from websites, but I do not think that it is a
> good idea to let the people who vote on the artists site decide
> everything. How many of them are even using KDE? How many of them are
> developing for KDE? How many of them have any clue whatsoever about
> artwork? How many of them are in the eV?
>
> So, although it is a good source of information it is in no way a
> deciding factor for what is included in the release.

I think I need to clarify about the polls. The purpose of the polls on 
kde-artists.org was to decide which wallpaper to present to the kde-artists 
mailing list. It was _not_ to decide which one was to be included as default.  
I assumed that after I presented the wallpapers that there would be a 
discussion about whether or not we wanted to use one as the default or what 
changes were needed to make to them better, etc, etc. But instead of the 
typical discussion I was attacked. The artists on the website are in no way 
trying to take over. We just want to contribute. Ken did not take the time to 
ask me to clarify or find to the purpose behind the polls. He jumped to 
conclusions and based his harsh words on these vast assumptions. It is not
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Hausmann | 1 Sep 2005 11:26
Picon
Favicon
Gravatar

Re: Malaga Discussions III

On Wednesday 31 August 2005 15:37, Harri Porten wrote:
> > The other aspect was much more controversial as it related to kdelibs.
> > The idea presented was to split kdelibs into the parts that only rely on
> > Qt each (most widgets, some of our kdecore parts) and those parts that
> > are either grouped together to make up KDE's framework and the parts that
> > rely on that KDE framework.
>
> I don't see the point here. Philosphically. I don't see where to draw the
> logical boundary. "KDE libraries use Qt" is what describes our situation.
> That means that every KDE library is part of KDE and depends on "itself",
> ie. KDE. Whether library B (i.e. kdeui) also relies on library A (i.e.
> kdecore) doesn't really matter. A is just another lib that would have to
> be shipped with B as is Qt. The important part is just to make sure that
> core parts are designed and implemented in a portable part to allow for a
> portable base that high level libs can rely on.

The idea is to draw the line on class level, not on library level. And there I 
don't see it as a too difficult to to decide on whether a class is part of 
the framework or just a standalone tool class with no horizontal 
dependencies.

Simon
Permalink | Reply | 2 comments |
headers
Nicolas Goutte | 1 Sep 2005 14:25
Picon

Re: kedulaunch --> KDE Application Launcher (or "Berlin Migration")

On Thursday 01 September 2005 03:07, Kurt Pfeifle wrote:
> Hi,
>
> you may have seen last night's commit of the nxfish:/ extension to
> our beloved fish:// KIO slave:
>
>    http://lists.kde.org/?l=kde-commits&m=112535566514080&w=2

A little off-topic but does that mean that there will be somebody taking care 
about fish:// again or is it just an extension?

>
(...)

Have a nice day!
Permalink | Reply | 0 comments |
headers
Maks Orlovich | 1 Sep 2005 15:09
X-Face
Picon
Favicon

Re: Malaga Discussions III

> The idea is to draw the line on class level, not on library level. And
> there I don't see it as a too difficult to to decide on whether a class is
> part of the framework or just a standalone tool class with no horizontal
> dependencies.

Well, it's slightly trickier than that: you're also deciding that the class 
will -never- get any horizontal dependencies. It may or may not be an issue 
depending on what happens with things like KGuiItem, KAction, etc.
Permalink | Reply | 0 comments |
headers
Joseph Wenninger | 1 Sep 2005 16:10
Picon
Favicon

kdelibs/kde3support

Hi !

I plan to create kde3support and move kdockwidgets+dockmainwindow+kmdi there. 
Any objections ? Deadline for objections is today 1900 (Malaga time)

Kind regards
Joseph Wenninger
Permalink | Reply | 1 comment |
headers
Christoph Cullmann | 1 Sep 2005 16:19
Picon

KDE_DEPRECATED removal

Hi,
is removal of KDE_DEPRECATED stuff now allowed/approved?
As there is now plenty of time hacking and that's fairly easy in most case, 
should people be encouraged to do so in kdelibs-trunk or not?

cu
Christoph
Permalink | Reply | 3 comments |
headers
David Faure | 1 Sep 2005 16:59
Picon
Favicon
Gravatar

Re: kedulaunch --> KDE Application Launcher (or "Berlin Migration")

On Thursday 01 September 2005 03:07, Kurt Pfeifle wrote:
> Our wish would be to have this thingie extended, and made more 
> flexible/configurable to launch *any* application, and also subject to 
> "Kiosk-ization".
> 
> Such a nice-looking and well-designed application launcher (based on
> the kedulaunch code, but more generic) would make a well-received and
> perfect component to the current Linux and KDE desktop migration 
> efforts of various Berlin local city administration bodies -- this we
> were told today first-hand by one of the activists and key influencers 
> in the Berlin local government IT.

It's not clear to me what your ideal launcher should really do, can you explain it more precisely?
To ask this otherwise, what's the difference with e.g. minicli (if it's graphical) or kfmclient (if it's not)?

--

-- 
David Faure, faure <at> kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
Permalink | Reply | 0 comments |

Gmane