User:Frederik/ghns todo
my private scratchpad for knewstuff3
attica
- add extendedattributes
- tag and release next version
Uploaddialog
updating of contentnach erfolgreichem upload link auf website anzeigen (hinweis: deleting of content -> link to website)- wenn edit: link bekannt
wenn add: content/get auf id
währungmittels user/balance
dateiauswahl, wenn keine datei vorgegebensupport 3 screenshotsimage frames super ugly
fetch previously uploaded images when updatingdisable 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
- going back also seems to add categories again and again
Downloaddialog
done
click on image should show detailschangelog and summary in details dialog, scrollbar if neededmake downloaddialog available as widgetbig 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 itbonus points for fixing the freaking scroll wheel buginstead 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 buttonsfixed, 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 screenshotsmake 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
link username in ghns dialog to profile page- in general list
- in details page
in details page: if no link, add email like in delegateFRANK: content/get has no <profilepage> tag
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)
mime types for parley seem to fail -> html
todo
upload button in download dialog- only enable if it has an attica provider
- show fans
number of fans in general listFRANK: 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?
- 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?????
- kanagram - deletion is broken ?
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
Plasma
community plasmoid: remove username/pass from config
other
add Entry::id() (the public one) for tomacheck 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 ...
- Did I break ktorrent? http://kde.pastebin.com/0DMWf108
Frank: account/add (register) status 105/106 vertauscht- Icons - upload especially!!! give them to me :(
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)