You are not logged in.

Dear visitor, welcome to KDE-Forum.org. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

damianus

Beginner

  • "damianus" started this thread

Posts: 6

Location: Egham, Surrey

Occupation: Yet Another IT Sales Guy

  • Send private message

1

Monday, March 6th 2006, 9:10pm

KDE on the corporate Desktop ?!?!?

Hi all. I need some help. I think I'm in the right place though.


.........
I am:

Damo,
I am using Centos (RH4), KDE-3.5.1.

I can code Java, C/C++ modestly.
PHP referentially (with a book in my hand).
perl competently

.......

Having been a Linux KDE user for some 5 years now, I have a project I think will be interesting and will be a great way to learn KDE and to some degree Linux. Anyone who has worked on a distro before will be particularly useful to talk with because I want to create a slimmed down Office Desktop. The scope as I see it now is quite large for a first-time KDE project, but it contains lots of little separate parts ans so I can learn as I go along.

The project is an integrated application environment.

While working there I wondered as we all probably have about the viability of Linux desktops in the workplace.
Most of the tasks these employees perform there are using just the main office type packages, word processor, spreadsheet, email, calendar, presentation. Other than a few job-specific applications (all of which are easily compiled or available under linux )most of this can be done using KOffice/OpenOffice.

AT this stage. It would be impossible to push Linux telling the customer " My product is so good you can have it for free, oh yeah although it's a lot better than your last system I won't be able to show you why because your workers will actively resist it"

Hopeful and as blindly enthusiastic as I was, even I had to accept that getting computer-phobes to get used to our beautiful and configurable desktop was a challenge beyond the will of most IT managers. Although KDE is better than the static, single-workspace desktop offered by windows, it isn't worth the uncertainty to shift.

With KDE being in my view, the best and most functional desktop I know of, things don't look good for linux on the desktop ( at home or at work ) if users cannot be coerced into using KDE/Linux they're hardly going to be encouraged to move to Linux with Gnome or Enlightenment are they.

Most of the tasks these employees perform there are using just the main office type packages, word processor, spreadsheet, email, calendar, presentation. Other than a few job-specific applications (all of which are easily compiled or available under linux )most of this can be done using KOffice/OpenOffice.

SO what's the problem? Well, it's crap.

Frankly OpenOffice is a big bloaty behemoth and it seems to have little KDE integration. KOffice apps are a bit smaller on the footprint and appear to give me everything I need ( particular ability to read and write MS Office files)

I want to reduce the click count for every operation or task someone has to do. This can be done through adding functions is the KDE and application right-click menus. ( You know what I mean - things like being able to send files as an attachment just by right clicking, instead of opening a new email, selecting the file from the file manager and then filling in the email header text boxes before clicking send )

What interests me is using tools like DCOP and scripting languages to create more of these automation buttons ( around kde, on the desktop, in right-click menus etc ) with the aim of reducing the hassle and the clicks associated with each file.

How many of you working in Windows-based offices have a number of staff, who are nothing to do with IT, but are seen as 'experts' because they give advice on MS Office applications (Excel in particular ). Every one of those experts probably has a different way to do the job. Asking advice from two separate experts on two separate occasions can lead to spectularly inconsistent advice.

By radically simplifying the desktop itself, the incidence of foolishness can be avoided. Work out the simplest method ( and most intuitive too, before anyone mentions ubuntu ) and take away all the others ( apart from the other intuitive ones )

I have already proved a reduction of about 60% in click count for a web session where the user was cutting and pasting website links into a spreadsheet - from over 150 clicks in the session to 40!

There are a number of infrastructure and licensing advantages as well as productivity improvements that I can email you and tell you about.

First I'd love to know

-whether the path that opens a program from an icon/menu can be set to open it ALWAYS in on a specific Desktop and ALWAYS in FULL-SCREEN.
-how to add a small script to a K applications right-click menu, so that I can add apps like 'send by email', 'send as attachment',
-how about a 'send as attachment' that reveals a further menu which is a list of addressbooks and groups in Kmail.
This way I could right-click a file in say the file manager, run down the list, select a contact and then sit back and watch as KMail opens a new email, with that contacts address in the subject line and the attachments already added and <Attachment Filename> in the subject title.

The Desktop will include:
KOffice
KDE PIM
I will be here again soon to have my assumptions corrected and my spirit broken ;-)
Please offer any advice you can.

Thanks in advance
There is only one path and one path only.
That is the path on relentless struggle.

anda_skoa

Professional

Posts: 1,273

Location: Graz, Austria

Occupation: Software Developer

  • Send private message

2

Monday, March 6th 2006, 11:19pm

RE: KDE on the corporate Desktop ?!?!?

Quoted

Originally posted by damianus
I want to reduce the click count for every operation or task someone has to do. This can be done through adding functions is the KDE and application right-click menus. ( You know what I mean - things like being able to send files as an attachment just by right clicking, instead of opening a new email, selecting the file from the file manager and then filling in the email header text boxes before clicking send )


The City of Munich, Germany, which is working on a transition to free desktops is using (according to a presentation by one of their project leaders) a custom developed Java based workflow application which uses the OpenOffice.org UNO object model API to create their documents while handling other functionality (like sending emails) itself.

Quoted


-whether the path that opens a program from an icon/menu can be set to open it ALWAYS in on a specific Desktop and ALWAYS in FULL-SCREEN.


I think one can do that with kstart.
See kstart --help

Quoted


-how to add a small script to a K applications right-click menu, so that I can add apps like 'send by email', 'send as attachment',


Depends on the application, most apps will not be easily extensible unless they were constructed for it.

Quoted


-how about a 'send as attachment' that reveals a further menu which is a list of addressbooks and groups in Kmail.


Hmm, interesting idea. Might be possible to do a Konqueror/KFile plugin with that functionality.

Cheers,
_
Qt/KDE Developer
Debian User

damianus

Beginner

  • "damianus" started this thread

Posts: 6

Location: Egham, Surrey

Occupation: Yet Another IT Sales Guy

  • Send private message

3

Tuesday, March 7th 2006, 1:41am

RE: KDE on the corporate Desktop ?!?!?

I suspected some apps would be easier to customise than others, so was leaving those decisions till getting some advice. I hoped to get ideas from speaking to anyone who had tried similar. IF i could get someone saying " I did it in OO and it was hard" versus someone else saying " Oh, i did something similar in KOffice and it was easy" then the choice would be easy.

In fact that's what I was hoping to hear. I just figured KDE had integration in mind from the outset.

What you tell me about OO is interesting. I have a KOffice bias because of OO's huge footprint. One of the features of my desktop is that it expects that many tasks will be completed by chains of small applications piping results to each other and dribbling out the finished product at the end.

An example to explain, one of the pains I saw was to do with reading what a set of data indicates.. Excel is popular as a data visualisation tool in offices. Because it is so widely available, "Excel" is written as a qualification on peoples CV's. Unless using an expensive MIS application to display relationships, people like to revieve their data and analyse it in excel and in .xls format. They want the same menu's and keybindings too. The company I worked for used a web-based customer relationship mangement tool (asp), stored data on a database and then still converted the results into excel sheets when a manager wanted to make decisions with the data.

I wanted to give the user the ease of use of a gui ( maybe php/browser, maybe QT/KDE, maybe some SuperKaramba stuff ) by using an application to parse the .xls file, I also wanted to give the end-user, the manager the data in xls format :

eg. ( http://www-128.ibm.com/developerworks/li…brary/l-pexcel/ )

When making a mock-up of my system, I could only do this comfortably with OO. My KOffice (stable from the stable apt repos ) kept crashing under an admittedly suspect installation of Debian Sarge when I tried to save anything. I actually first hoped to use a chain of gnutools - can't remeber the name but I did find a console app that could convert xls to a databse file for sql.

Then I would read and copy data from the parsed file to mySQL where it can be easily be worked on with the gui - I am particularly excited by the idea of using superkaramba python scripts to access and fiddle witht he database tables, the opportunities for adding a really striking look to the system are endless. Anyway, once the population has been completed, the .db file can be used to write the changed data back to a copy of the original text file (csv?) that was parsed from the excel sheet.

Finally save the the csv text file to excel with a small gnu tool.
Viola, free and free decimation of a proprietary data format using free and free tools. The excel sheet can then be manipulated by the hapless manager within OO. The manager can afford to provide themselves and the rest of the team a copy of excel, so they can have all the usual comforts of knowing exactly 'how to do that thing where you...'.

This keeps the user away from an over-featured (as a crm application anyway ) and time-consuming excel application which and their employer from another costly license.

Two problems arose when I looked at Siag office and a few console apps - namely the applications themselves lacking in common features you would expect, or having layouts alien to most pc users. Also I couldn't find something that could deal with coloured cells. This meant I had to find some way of sorting the original spreadsheet by adding a column with 'colour' as the label and then marking all the coloured lines so that the state
( coloured / not coloured ) could be recorded. It also meant manually ggoing through and colouring the finished product after sorting bby this column. More evil clicks.

This would defeat the point of the exercise (reducing repetitive and non-cerebral tasks that piss off employees and hinder people thinking about what they are trying to achieve) and would anger racial equality groups too.

I did find and add the 'send as attachment in konqueror, I just had to create a new email.desktop file and add a few lines to it.

[Desktop Entry]
Actions=Email
Encoding=UTF-8
ServiceTypes=allfiles

[Desktop Action Email]
Name=Send file(s) with Kmail
Exec=kmail --attach %F
Icon=kmail

to:


pico /usr/share/apps/konqueror/servicemenus/email.desktop (KDE-3.4)

or

pico /opt/kde/share/apps/konqueror/servicemenus/email.desktop (KDE-3.5)

I used nano, not pico though.

Thanks a lot to barcodelinux, the little addition works fine.

I'll read the KDE3 architecture how-to so I can see which apps I can do the same for.
There is only one path and one path only.
That is the path on relentless struggle.

This post has been edited 1 times, last edit by "damianus" (Mar 7th 2006, 1:48am)


anda_skoa

Professional

Posts: 1,273

Location: Graz, Austria

Occupation: Software Developer

  • Send private message

4

Tuesday, March 7th 2006, 8:20pm

Thank you for that thorough explanation!

The best way to evaluate the viability of using KOffice for that kind of workflow automation is to ask the KOffice developers in their mailinglists (see "our" other thread :))

In principle it could be possible through the applications' DCOP interface in languages that have DCOP bindings, for example Python, Ruby or Perl.

However it might not be sufficient yet and the OOo component model might be better functionality wise, even if it means greater resource usage.

Cheers,
_
Qt/KDE Developer
Debian User