User:Frederik/ghns todo

my private scratchpad for knewstuff3

attica

• add extendedattributes
  • tag and release next version

Uploaddialog

• updating of content
• nach erfolgreichem upload link auf website anzeigen (hinweis: deleting of content -> link to website)
  • wenn edit: link bekannt
  • wenn add: content/get auf id
• währung
  • mittels user/balance
• dateiauswahl, wenn keine datei vorgegeben
• support 3 screenshots
• image frames super ugly

• fetch previously uploaded images when updating
• disable update radio as long as no old item has been found
• going back: fills in the update information again when going to details page 1

Downloaddialog

done

• click on image should show details
• changelog and summary in details dialog, scrollbar if needed
• make downloaddialog available as widget
  • big refactoring of dialog class use Q_PRIVATE_SLOT in the widget, dialog is an empty shell around the widget now
• when loading dialog: show progress bar with 0% instead of not showing it
• bonus points for fixing the freaking scroll wheel bug
  • instead use kpixmapsequence
• add status label to details dialog (to show error messages etc)
• if the download is a html page, ask the user if it should be opened in a browser instead (maybe also delete it then?)
  • have an option in .knsrc file to not do this? if html is valid?
  • document this behavior on techbase
• bug: translated text too long for buttons
  • fixed, but buttons still look uglyish - using qtoolbutton all around now
• donation button (link to website? api - need to look into what's possible)
  • needs server side support for this (at least a link)
  • link is there: <donationpage>http://openDesktop.org/content/donate.php?content=116563</donationpage>
  • maybe like payment?
• support 3 screenshots
  • make details screenshot selection less ugly
• also show knowledgebase link in details?
• refactor engine class to not have a private class and clean up in provider selection in dialog (currently hidden combo box)

there

todo

• link username in ghns dialog to profile page
  • in general list
  • in details page
  • in details page: if no link, add email like in delegate
  • FRANK: content/get has no <profilepage> tag
• upload button in download dialog
  • only enable if it has an attica provider
• support for all downloads (multiple downloadlinks - eg Buildservice)
  • toolbutton for install button (drop down, the way it was waaay back then)
  • QtiPlot has multiple download links (good as example)
  • Still missing in details page
• payment for link > 1 is probably broken (when you buy item #2 out of the download link list)
• show fans
  • number of fans in general list
    • FRANK: needed from server in content/list
  • actually show fans on details page (ui?)
  • if all else fails, link to website
  • needs call to /v1/fan/data/"contentid" that will return a list of persons
• integrate details into regular dialog
  • make escape go back instead of closing the dialog

• Comments (needs server side api, attica extensions)
  • maybe add a tab to the details view?
• hint: use the plasma widget "news" to get notifications about updates (put into download dialog?)

• when user closes dialog - ask confirmation to cancel running downloads

• check if the installed files still exist when starting, otherwise offer to install again (?)
• redo layout again? combo boxes on top?

Different providers? Status

Right now the provider has to be set in the .knsrc file. As of March 27th 2010 any provider that supports the OCS api works, not only opendesktop.org.

• allow to not specify a provider in the knsrc file and use the defaults from attica kcm (systemsettings) instead

• make it possible to add/remove/disable providers in kcm

Create class to check for updates automagically

• enable update notification in apps
  • whohoo - downloadmanager is here :D
  • write tutorial about this on techbase
  • put example in kdeexamples

other

• add Entry::id() (the public one) for toma
• check kde-core-devel for attica patches
  • there are some binary incompatible patches that should be picked up if we decide to break bc at some point. the other parts of the patch were applied.
• setter for category (updater)
  • is it not enought to use the knsrc file?
• way to let updater also just fetch a category

• extended attributes (+parley as showcase)
• rename opendesktop plasmoids
  • personal news feed
  • community
• kcm provider configuration

• stand alone download app
  • book reader
  • audio store

• app installer?

• buildservice integration?
  • kde-obs-generator
  • osc

• Categories for Akonadi Config on openDesktop:
  • kde-files.org -> Akonadi Configurations -> Email Providers

(in theory it could also be addressbook or agenda's, maybe be prepared for that)

• look at bugs.kde.org ... and again and again ...

other 2

Long term: consider notifications from website/dialog/fan - what should go where etc ...

workflow document? how do you think apps should be created - from source to git to obs to opendesktop.org

other 3

reminder how to do colors in wiki: Set text color by using TEXT Set background color by using TEXT Set both by using TEXT

KNewStuff2 Internal Design and problems

KNewStuff2 currently (as of kde 4.3 and earlier) has a couple of problems that prevent it from easily moving forward to support more interesting features such as server-side searching, and make simple things like knowing what needs to be updated of the installed data tricky also. Here are some things wrong with the design that we will address for 4.4 below.

Entry ownership

Currently Entries are owned by Feeds, but in reality, Entries should be owned by the provider that provides them, feeds are just a way of getting a list from the provider (but there will soon be other ways in addition to feeds, search, find all wallpapers uploaded by foo, etc.)

In order to fix this problem Entries will be owned by the Provider they come from (which also means when the registry is loaded, the Entries in there need to be parented by the correct provider, what if the provider is no longer available? A LocalRegistry provider may need to be implemented also?)

Frederik:
Some of this is fixed - entries are managed by providers now.
So far, entries have no real parent, but are passed around as shared data objects. It might be a good idea to let entries have a pointer to their owning provider which would make some things easier.
Feeds are only used internally by the static xml provider (aka the old stuff), while the new OpenCollaborationService provider, nicknamed Attica, like the lib used to access it, has no such concept.

I'm currently starting to like the idea of the registry provider more and more.

Right now, all caching is disabled. I doubt, that it ever really worked though.

Engine cruft

Currently there are Three *Engine classes in KNewStuff2. This complicates things beyond necessity. What's more the inheritance relationship between the Engine classes is odd and not very intuitive. This makes maintaining KNewStuff2 tricky, and also makes it harder for new blood to get involved in bug fixing and adding features.

In order to fix this problem all Engine classes should be combined into one Engine class. It handles the Engine-type stuff (reading local registry? creating provider objects, parsing the knsrc file, etc.). The Engine class leaves most of the server interaction functionality to the Provider class(es) however, and only steps in to do actual work after data has been downloaded and needs to be Installed, or whatnot. This way the provider(s) can be customized to work with each server-side api specifically, and well.

Frederik: this is mostly done. Cache and registry need cleanup, the engine is still a huge clunky thing. Some of the stuff has been moved to a class Installation, which takes care of all the downloading and installing stuff.

Provider Support

Currently there are 3 types of providers for GHNS data. Each work fairly well with the current implementation, however HotStuff (what's on newstuff.kde.org) and Open Desktop (what's on kde-look.org, etc.) both have added collaboration functionality that's not currently exposed in the KNewStuff2 gui. This is partly because the two server-side implementations do things a bit differently, but also partly because of trickiness in implementing support for two server-side implementations in unclear engine class heirarchy.

In order to work with this situation well, the creation of a few new Provider classes is to be considered.

A base implementation will provide support for getting Static Website providers (stuff that's hosted in static xml files such as edu.kde.org/newstuff if anyone is still using that). This base implementation could be created by extending the existing KNewStuff2 Provider class.

A sub class DXSProvider class can be implemented that talks to dxs server-side providers. This class would have derived methods to get Comments for an entry, leave comments for an entry, upload, rate, and generally interact with HotStuff implementations.

Another sub class RESTProvider could be implemented also that does likewise for REST server-side implementations. Likewise having methods for getting comments, leaving comments, rating entries, but also for server-side searching (which the DXS Provider can implement once that works in HotStuff, maybe it already does?), paging (show me page 2 of my search, ok, now page 7... etc.), filtering (show me all entries uploaded by coolartist for example).

In order for RESTProvider to provide this added functionality, virtual methods will be added to the base Provider class to get and send this data, and they will do nothing and/or show a message box saying "this provider does not support rating" or somesuch.

User Interface

Providers combobox can go away

Users don't really care where the data is coming from, and it's much nicer to see all providers data in one view (no apps currently fetch from more than one provider either). So the provider combobox can and should be removed, and all similar data from different providers can be merged together into one view (i.e. all highest rated from kde-look.org and all highest rated from newstuff.kde.org can be in one "Highest Rated" tab)

Done. What needs to be done now is to implement sorting in the sortfilterproxy of the downloaddialog.

Go back to tabs?

One problem with the existing ui is that it doesn't give room for server-side search to open new views (it could and just put them in the sort combobox, but sort is not really what that combobox does anyway). It is suggested that we move to tabs like these were in kde 3.x days, and create new tabs for each server-side search (closable tabs of course).

Frederik: I'm totally against this. In the branch I currently have a version working where all searches are done by the providers (in case of staticxml it's just filtering). I find this working well and a lot less confusing than tabs.

== Preview too small == Another problem with the ui is that the previews are very small and hard to see detail when they are generated from a larger image anyway. Something that has been frequently asked for is the ability to click on the small preview and see a larger one temporarily. This would help users see much easier what visual data they are actually downloading. (done)