Tag Archives: OCS

kdev-python: GHNS support for documentation data

Finally, after a few days of difficult work, it’s here: the prototype for kdev-python’s new GHNS support for documentation data!

kdev-python now has its own settings module providing GHNS support

Technology

I don’t want to go into detail here (I’m a bit sick of this stuff currently *grin*), but the OCS backend is written by me and running on my own server currently, for testing purposes. It’s python2 / django using MySQL as database backend, and nginx for a web server. You can register a new user acoount here (admire the awesomeness of stylesheet-free default template files!). The backend is extremely incomplete and doesn’t support most operations. Basically, you can upload an item with a title and a description, and download it again. No screenshots, no license types, no ratings, no download counter. Oh, but the search works. 😉
The upload dialog requires current kdelibs 4.10 (stable doesn’t work) because of a bug I fixed there which prevented changing the provider to something other than the default opendesktop.org one.
There’s also a patch of mine pending review for libattica to fix a bug causing annoying spoof-checker warnings to be displayed when connecting.
The feature is currently residing in the “ghns” branch of kdev-python, so if you want to try it, you’ll have to compile that branch.

Use cases and tools provided

In addition to GHNS integration, I also implemented a set of tools for “develpoing” documentation data. In the following, I will describe them and their purpose. This, once more, is the KCM (you can access it via KDevelop » Configure KDevelop » Python Documentation Files):

The new KCM, once again

The “Download new” tool

This one is pretty obvious: you can download documentation files created by other users. You are presented with a list of content and you can install and uninstall the individual packages with one click each.

The “Share selected” tool

The widget allows you to select any amount of files or directories to put into an entity you consider useful to share in the widget on the left, and upload them. A tar.gz archive will automatically be created from the selected files, all you have to do is enter your user name and a title for your package and click upload.
If you select no files, you can chose a tar archive you created yourself.
Packages should be for one Python module specifically. Please don’t make packages which are like “CoolNick47â„¢’s perfect collection of kdev-python docfiles”, but keep them very specific, e.g. “Documentation for numpy.fft” or “django 1.5 fixes”.

The “Generate” tool

This tool starts a little wizard which helps in bootstrapping docfiles for totally undocumented modules, such as those written in C.

The …read more
Source: FULL ARTICLE at Planet KDE

The new ownCloud 5 features!

Yesterday I blogged about the ownCloud 5 release in general and I promised to blog today about all the features that are new and improved in ownCloud 5

New design
In ownCloud 5, the main navigation was redesigned to clearly differentiate it from the in-app navigations. This also allows the app more room and thus a better focus on the content of your ownCloud directories. Settings and Log-out menus were combined into a user menu on the top right, which also shows the currently logged in user and makes it more intuitive to use. The settings are further simplified and app-specific settings are moved from personal settings into the relevant apps. To help people get their data synchronized, there is a new first run page linking the desktop & mobile apps as well as documentation how to sync contacts and calendars. This information is also displayed in the personal settings – and makes getting started with ownCloud much easier for a user.

Essentially, the new design helps to concentrate more on the content and makes it easier to navigate and setup the Desktop and Mobile syncing clients.

New Antivirus App
The new antivirus system scans uploaded files for viruses. The admin can choose if infected files should be deleted automatically and/or logged/reported in the log file.

New Files Undelete feature
Now users can undelete a file that was accidentally deleted through the web interface. Simply select the files in the files undelete section and they are returned to where they were deleted, with versions maintained.

New REST APIs
A new Open Collaboration Services (OCS)-based REST API is added to access and control ownCloud remotely. The newly released OCS 1.7 spec is supported. Main feature is a new capabilities API for closer communication with the Desktop and Mobile clients. It is now very easy for ownCloud apps to provide an REST API so more API features will be added in the future.

Display names
In the interface and share dialog, display names are shown instead of the login names. The display names are easier to understand for users and can be changed by the admin. The admin can configure the display names and they can be changed by the users themselves. The display names can also be fetched from an LDAP or AD server for bigger installations. This makes it much easier to work with ownCloud, as users are identified separately from their system-generated IDs

New search engine
A new Lucene-based full text search engine app is added. People can use the search to not only find files by name but also by content. Scanning is done in the background to ensure a responsive user experience for the users.

New photo gallery
ownCloud 5 contains an improved and rewritten photo gallery. It has an improved and streamlined user interface with a slideshow feature. Photo galleries can also be shared with others.

New documentation system
There is completely new user, admin and …read more
Source: FULL ARTICLE at Planet KDE

GetHotNewStuff (GHNS) support with a custom server and OCS rant

For up- and downloading documentation files in kdev-python, I wanted to implement support for the KDE GHNS dialog (you know,

XML, OCS style — sorry for using an image, but posting stuff containing tags in blogger is sort of impossible

You might say, okay, yeah, it’s not great but it was probably the easiest way to get stuff done. I agree, especially since I’m also that kind of person which at some point will say “alright, f** elegance, let’s just get stuff done”. But, there’s a list of other things which are somewhat off in this specification, which just fit this kind of XML rather well:

  • Every response contains a “status” field (which contains “ok” or “failed”) and a “statuscode” field. The status code is always 100 if the requests succeeds, and if it’s not 100 something went wrong. So, where’s the point of the status field?
  • The specification mainly works through providing examples. That’s not a bad thing by itself, but it would be good if at least the field names and their possible values were always fully listed and explained outside of an example. This is not the case (example; example2 — here, what is e.g. “latitude”? How am I supposed to format the data in that field? I mean you can guess from the values in the example for a similar call, but still… Also note how a person only has 6 homepages while a content has 10… and 12 downloads… and 3 previews). Generally, there’s lots of stuff which is just unspecified and you can only guess it from the examples. Bad.
  • Funny URL schemes: my favourite is “uploaddownload”
  • In uploadfile, there’s various error conditions, but none matches e.g. “the item to which the file should be added was not found”. In return, there’s “localfile not found” which means… um… whatever… maybe the server couldn’t find the file on the client’s computer?
  • It has typos. E.g. in edit, it has a field named “downloadtyp1”. This looks just weird, shouldn’t it be “downloadtype1″? What do I do now, implement the weird one and rely on everyone else following the spec closely too? Or guess that this is a typo and that everyone else probably corrected it? I’ll go for the former.
  • It has nonsensical field values, e.g. this: donation – do you want donation for this entry? possible values are “yes” or “” for no donation. Sure, why allow “no” if you can just leave the field empty… I mean, specifying to treat empty as “no” is ok but this is just weird.
  • In download, there’s this confusing thing: contentid – Id of a content; itemid – Id of a content — Hm. You can guess that the itemid probably means like “the 3rd download item in this content entry”, but what is it? Can I use my own IDs here? Probably not. Do they start at 0, or 1? Probably 1, but I don’t know.
  • It leaves quite a few other questions open, for example, …read more
    Source: FULL ARTICLE at Planet KDE