@stansage
Tried kdev-control-flow-graph?

In larger scientific organizations, home directories are likely to reside on networked filesystems like AFS. Not all of those filesystems allow creation of sockets. However, since KDE needs some sockets in ~/.kde (at least the last time I checked), this makes the entire desktop environment impractical to use and forces users to use different DEs. This seems to be a more fundamental hindrance to using KDE than individual applications (at least where I work, most scientific work happens exclusively in the terminal, anyway).

Interesting. Do you have any analysis of where KDE is creating sockets under the home directory in particular?
All sockets should be created in ~/.kde4/socket-<hostname>/ which is a symlink to a local directory under /tmp.

Sorry for the delay, I've been abroad for a while... If I do a

Code: Select all

find ~ -type s

on a KDE test installation, I see at least

Code: Select all

~/.kde/share/apps/nepomuk/socket

. Admittedly, we're not running the newest KDE 4 release here, so this may be fixed in newer ones.

On my KDE Trunk system, both Akonadi and Nepomuk no longer appear to create sockets under ~/

There are two (as far as I know) different tools in KDE that may be used as diary: Kjots (part of KDE PIM) and Calligra Braindump.

When there were no Braindump I used Kjots as a diary. Now I have some things in Kjots, and some ones in Braindump (in fact, in Braindump I have some scientific stuff).

I suppose it would good thing to integrate Braindump capabilities into KDE PIM. Or, something like that.

Best regards,
Aleksey.

I don't like the way the application launcher classifies pretty much all KDE software, especially the scientific software. The categories the developers & package maintainers use really has no relationship to how the software is actually used. For example, if I want a microscopy imaging menu and submenus based on different microscopy imaging tasks, that's so specialized, no package maintainer could keep up. So, every time I reload linux or switch distros or switch machines, I have to go through & manually edit the menu structure so that apps are classified by tasks I actually use them for. Sometimes, an application shows up in multiple places.

Anyway, I would like some simpler way to reclassify the applications & clone my menu structure for new machines. I was thinking it would be good to have a repository of classifications based on your vocation or by activity.

On a related topic, I've seen some discussions on how activities in KDE are powerfull but mainly un-used because people don't know they exist or how to use them or what they're good for. Having activity-dependent menuing would be a great selling tool. I have a significant number of programs that I have to organize, and, paring the number of menus that I have to navigate through based on activity would be great, so long as someone else sets it up (or I can clone my work). It just takes too long to tweak the menus so that you can find everything without some programs getting lost.

One other topic, sometimes getting Java apps to work from the menu is a fight. What about pre-set launch options so I don't have to learn everything about Java app launching. Also, getting some programs to launch a terminal window, run the program, and keep the window open so I can see the results is a pain. And you can forget strining CLI programs together. I never got all the CLI programs working on my last distro. So, because of the many scientific programs in this category, it's definitely a science issue.

I know that's not what you were expecting, but, I would like an easier menuing system.

With regards to keeping the terminal open when CLI commands finish, try checking "Run in terminal" on the advanced page of each application, and specifying "--noclose" as the "Terminal options". Assuming you use Konsole, this should work correctly.

bcooksley wrote:With regards to keeping the terminal open when CLI commands finish, try checking "Run in terminal" on the advanced page of each application, and specifying "--noclose" as the "Terminal options". Assuming you use Konsole, this should work correctly.

The latest program I configured will only run without the "run in terminal" option selected. This is odd, because I run this program from a terminal all the time. It's just the menuing system that chokes on it for some reason.

I seem to be spending a lot of time fighting the menuing system. Does anyone here know the people working on it? I'm running some unusual science apps that may break things a little. So, I might be a good person to have working on the menuing.

The menu system is quite old, yet very well proven code from what I understand.
As the standards it implements are not changing, I don't believe there are any active changes going on at the moment.

For the terminal application issue, you may want to check the settings at System Settings > Default Applications. Konsole should be selected.

I use R from RKward front-end. Recently I tried Rstudio to work with R in a remote server. Rstudio have many interesting features (LaTex editor for Sweave and knittr files, projects, version control system, package creator mode...) which lacks on RKward but I miss the Kate editor features and KDE integration (open file dialogs, aesthetics, ...).

I suppose it should be possible to get most of the features using parts from Kdevelop (git integration, edit and compile c files for R packages, projects), Kile (for LaTex integration) and RKward (for R integration). Kbibtex could also join the party

to give some usefull tips ...and good suggestion ...

http://duilegalhelp.org

While not a scientist, I did have the opportunity to spend a month at a biodiversity research station in the Ecuadorian Amazon. ( https://www.facebook.com/pages/Tiputini/27400169892 ) They have a camera trap project which has captured more then 50 thousand images of rarely seen fauna. While discussing with the researchers on how to manage all those photos, I hit on the idea of keeping important details in the image metadata.

It turns out that there is a metadata standard for biodiversity research (called Darwin Core) and that an XMP implementation has been available in exiftool for a couple of years now. http://www.sno.phy.queensu.ca/~phil/exi ... nCore.html

So I set about making sure that open source imaging tools could work with this data, or at least not mess with it! And trying to make ALL metadata paramount in systems. Right now most computers and apps only care about the meta data deemed important back in the 60's, things like file dates, permissions, file names. 50 years later we have a much wider range of metadata available, but many apps and system ignore it.

Many KDE imaging apps use the exiv2 library rather then exiftool, so first task was to get DwC (Darwin Core) into exiv2. I have it working on my system, but it needs more testing. http://dev.exiv2.org/issues/937

Other tasks may be extending the Metadata Editor in kipi-plugins to support DwC, integrating DwC metadata into file managers and Baloo / Nepomuk, updating batch editors such as phatch, fixing bugs in other apps that remove DwC and other XMP metadata. ( https://bugs.kde.org/show_bug.cgi?id=328282 ), ( https://bugzilla.gnome.org/show_bug.cgi?id=719621 ), ( https://bugs.launchpad.net/pinta/+bug/1084236 ) ...

And I suspect a formal DwC XMP schema needs to written and submitted to the appropriate authorities. ( http://rs.tdwg.org/dwc/ ) The current XMP implementation is an unofficial implementation by Frank Bungartz of the Charles Darwin Station on the Galapagos Islands. ( http://u88.n24.queensu.ca/exiftool/foru ... pic=4442.0 )

Cheers!